ARM ports Trustzone down to Cortex-M

By Chris Edwards |  No Comments  |  Posted: November 10, 2015
Topics/Categories: Blog - IP  |  Tags: , , , , ,  | Organizations:

ARM is bringing the Trustzone security architecture to future Cortex-M processor cores, combining that with a version of the ARM hardware bus (AHB) that will recognise the difference between secure and non-secure transactions.

Nandan Nayampally, vice president of marketing in ARM’s CPU group, said: “Security is already a key issue for the connected world. Trustzone is something we introduced a decade ago and is in all our Cortex-A processors today. This brings the Trustzone architecture to much smaller devices.”

Intended for v8M ARM cores, ARM’s offering will include Trustzone-enabled processors, a cryptoprocessor based on technology acquired with the purchase of Sansa in the summer and AHB5, which adds a security identifier to transactions across the on-chip bus.

“We need to propagate secure state information across the SoC. AHB5 allow you to pass information across the bus securely and tune it to the right amount of resource on these very constrained systems,” said Nayampally, pointing out that an AHB5 initiator can act as a proxy for multiple peripherals.

Hardware additions

Although the company will be offering its own cryptoprocessor, Nayampally stressed Trustzone-M will work with the hardware coprocessors and extensions used by ARM partners. A number have already introduced security features to their ARM-based SoCs.

The designers have made changes to the way Trustzone operates to make it more suitable for the deeply embedded environment where interrupt and task-switch latencies are more important than on applications processors. This saw some of functions normally handled by a software hypervisor on the Cortex-A processors move into hardware.

Changes for the v8 Cortex-M architecture that accompany the introduction of Trustzone-M include a revised memory protection unit that makes it easier to allocate arbitrary memory sizes to protected areas. Under v7, these regions had to be created from address ranges that conformed to sizes measured in powers of two. Now the regions can start and end on arbitrary addresses.

The v8M cores will add a shadow set of control registers and stack pointers to support the secure mode of Trustzone-M.

Security checks

Simon Craske, lead embedded architect and fellow in ARM’s architecture group, said: “Typically, the secure side has more privilege than the non-secure side. You can prioritize secure interrupts above non-secure but it is often desirable for a non-secure interrupt to pre-empt secure code. On an older architecture, that would expose the contents of the secure registers to the interrupt.

To prevent non-secure interrupt code from being able to see secure values, the hardware will automatically store and zero out secure register contents when taking a high-priority interrupt that does not have a secure interrupt handler. Once the interrupt handler has completed, the secure register contents are recovered and control passed back to the secure-code pipeline.

A security attribution unit determines which code segments in memory are deemed to be runnable as secure code. “The key concept behind Trustzone is that if the CPU issues a transaction while in the non-secure state and goes to a secure location the CPU will kill that instruction.”

To avoid the need to use a hypervisor to mediate transactions and requests that cross from the non-secure to the secure side, ARM has implemented instructions that act as gateways.

“When you traverse [from non-secure mode] we want to be sure that the secure code is happy to be the target of the branch. We achieve that through a secure-gateway instruction. This is the first instruction that you land on when traversing to the secure side,” said Craske.

Because the deeply embedded environment is likely to see rapid traversal from non-secure to secure functions, Craske said the company has added some additional support for non-secure code to identify itself to the secure side’s functions to prevent spoofing and escalation attacks once a secure service has been set up. “There are some additional instructions that are designed to enable the secure side to validate pointers and so on,” Craske said.

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors