Security principles for TrustZone for Armv8-M - slides and Q&A from webinar

TrustZone for Armv8-M adds efficient security features to the Cortex-M23 and Cortex-M33, so now it’s easier to develop applications and services to protect hardware and software assets from being misused, corrupted or accessed without permission. 

Last week Diya Soubra (Arm, senior product manager of Cortex-M33) and Pete Rielly (Arm, applications engineer) hosted a wonderful technical presentation explaining the variety of hardware and software issues that a developer needs to be aware of before starting to develop the next-generation, security-aware applications using TrustZone technology.

• Missed the webinar? You can watch it here.
• Looking to view the slides? Download them here.
• Looking for more technical information? Join the TrustZone for Armv8-M Community for free - interact with the leading developers of tools, silicon and solutions.

Don't want to miss out on future news and updates from Arm about embedded development? Sign-up here to receive monthly Arm embedded engineering news.

The Q&A from the live webinar

During the webinar there were many technical questions asked. We wanted to share them with you here:

Q: You said the peripherals are shared. How is access separated, and how can I protect a bus from being used in normal world, for instance?

A: Accesses from the Cortex-M are protected by the SAU/IDAU. If the address range that covers the peripherals control registers is made secure in the SAU/IDAU then only secure code can access it. 

If we are concerned about accesses from other masters than the latest version of the AHB bus architecture, AHB5, as used by Cortex-M23 and Corrtex-M33, has an extension that indicates the security state of every memory transaction. This allows system level security gates to be used to protect peripherals.

Q: Can a solution provider example use a different compiler and the OEM provided compile the code in a different compiler?

A: Yes. Assuming both toolchains support the same Arm ABI and ACLE.

Q: How would an OEM provide its secure code to an end user? Can a library be secure to prevent disassembly?

A: OEMs can place their libraries in secure flash and protect them using TrustZone. After secure boot execution branches to a non-secure entry point. This will be in non-secure flash which can be populated by the end user.  This non-secure code can still call into secure functions but cannot read the code or data used by that function.

Q: Can you describe the certificate/token provisioning process into TrustZone Armv8-M for debug protection? How do you separate non-secure memory with secure memory?

A: TrustZone itself does not provide a certificate/token provisioning process. The chip developer is responsible to create whatever scheme they choose to give access to secure debug. That is, the chip vendor will have some sort of activation scheme that will allow the person doing the debug to request access to full debug be it via a password or token or any other authentication scheme. TrustZone is the hardware isolation that the processor architecture uses to implement the various levels of debug.

As for Secure and Non-secure memory, usually, on power (on reset) a piece of trusted software will setup the various regions and their associated attributes. These attributes are used by the SAU to decide on the type of access to that memory.

Q: Is it possible to implement "Process Isolation" like Rich OSes (e.g. Linux) with TrustZone and Armv8? (Due to lack of that, we newly had to develop a new RTOS on Armv7)

A: In the Cortex-M processors it is usually the Memory Protection unit that is used to provide for protection between threads. This remains the case in Cortex-M23 and Cortex-M33. TrustZone provides the two states of execution then it is up to the software developer to add more software layers for managing which part of the code runs and with access to which data memory.

Q: When a non-secure function makes a secure service call, does the privilege mode remain same or the secure side remember the last privilege mode it was in before jumping to non-secure state?

A: The two execution states are totally independent. When a call is made to the secure side then the code on the secure side will run in the state that it was assigned to regardless of where the non secure code resides. It is the responsibility of the software developer of the secure side to check all parameters passed and, assuming the called address is a valid entry point (contains the "SG" instruction) to check whether the non secure side is allowed to call.

Q: Do you know if there are there any development boards available for Armv8-M that you would suggest for playing this technology?

A: Arm has an FPGA board (MPS2+) and we expect partners to start releasing development boards soon.

Q: Is it possible to have multiple functions/enclaves in the trusted space isolated each from the other?

A: Yes, it is possible.  This can be implemented using the MPU. In the secure space you still have the standard thread/handler, privileged/unprivileged split. Privileged software in the secure space controls the secure MPU which can be used to isolate secure threads from each other.

Q: When we use IDAU to implement Secure alias & Non-secure region for the entire memory map (using bit number 28 of Address), what happens to the region between 0xE0000000 to 0xFFFFFFF?

A: This is a special region. Some parts are always secure while others may be secure or not based on the configuration, irrespective of bit number 28 or any other bit. Keep in mind that what we showed on the slide in the webinar using bit 28 was just an example to demonstrate the IDAU. More details can be found in the documentation that will soon be posted to the web.

Q: Starting from which version of GCC is this feature supported (for Windows and Linux)? Is it also supported in LLVM?

A: The GNU Arm Embedded Toolchain support TrustZone for Armv8-M fully from the  6-2017-q1-update. The features are supported in Arm Compiler 6.

Q: Can I still use the MPU in Secure state and in the Non-secure state as well?

A: The MPU is an optional feature that the chip designer may choose to include for the Secure side as well as the Non-secure side. Assuming both MPUs exist they can be independently configured.

Q: Does the hardware-based TrustZone context switch support floating point?

A: If the floating point registers are in use they will be automatically stacked and cleared on taking an exception.

Q: How big is the TLS stack in bytes?

A: The TLS code size depends on the cryptography algorithms selected in the build. Usually, people only select one or two algorithms so you end up with a good size for embedded applications. Best answer is really to download and compile with the algorithms of your choice.

Q: What are the constraints on addresses (alignment, etc.)?

A: Alignment rules for memory accesses are the same as for Armv7-M. MPU and SAU regions are aligned to 32 bytes but unlike Armv7-M they don’t need to be aligned to the region size.

Q: How do you make code secure when creating it? Is it necessary to set some compiler options?

A: There is a new compiler attribute that defines a function as being secure which will make the tool place it in secure memory. Full documentation is available.

Q: Is there any architectural whitepaper for the coprocessor interface? How does it provide authenticity? Is it also possible for the removable replaceable components?

A: The technical reference manual for the Cortex-M33 will soon be posted to the web so you will be able to see the full details. The document defines the interface to connect up to eight co-processors, it does not specify what the co-processor is or how it is authenticated by the system. Each processor can be assigned to secure or non secure state or it can have the security attribution on a per operation basis.

Q: Is there any open source code in the Trusted Execution Environment (TEE)?

A: We do expect that eventually ecosystem partners will build TEE that fit for an embedded solution. Currently we believe that most applications will not require a TEE and be totally based on a straight forward TrustZone application.

Please also take a look at this project on GitHub.

Q: How does the developer of unsecure software typically determine the entry points of secure firmware functions?

A: The entry points are supplied as a symbol file by the secure software developer

Q: What affect has TrustZone had on the interrupt latency for the Cortex-M23 and Cortex-M33?

A: The only impact is when you are executing in secure mode and you get a non-secure interrupt. Here you have the additional cycles of pushing ALL the registers.

Q: When do you think the major players (ST, NXP, SiLabs) will release Cortex-M23 and Cortex-M33 based products?

A: That is not something that we are able to comment about. The partner product plans are their own.

Q: How do you manage the list of secure API public function addresses that can be called from unsecure code?

A: The developer of the secure code will share a symbol file and the API specification.

Q: How do the interactions between the TrustZone for the Cortex-A series operate with the TrustZone for the Cortex-M series. Are they related to shared memory-based communication?

A: Both are the same concept but using a different implementation. For Cortex-A, we have the secure monitor in its own exception level where as in Cortex-M the processor itself does the policing.

Q: How will data resource management/’device management’ standards such as LWM2M benefit from TrustZone? (bootstrapping, device registration, remote firmware updates, device and application configurability)

A: The software complexity required to support these standards will be reduced due to the hardware assist from TrustZone in the processor.

Q: What is the positioning of the Cortex-M33 without a security extension (i.e. TrustZone) against the Cortex-M4?

A: The usual higher performance and better energy efficiency, but the intent is that both will exist going forward since there is not one solution that fits all applications.

Q: Where are ‘Secure Calls/SG’ calling conventions defined? Is there a document? I’m looking for something like PSCI definitions.

A: The specification is found here on the TrustZone for Armv8-M Community.

Q: Do you support execution of encrypted code, i.e. decryption on the fly or bulk decryption in memory and MD5 checking?

A: This is not a feature defined by the architecture, but nothing stops a silicon designer from implementing these features and relying on TrustZone to ensure secure storage for the encryption keys.

Q: Do you have guidance on the porting effort of an existing application from a non-TrustZone MCU to a TrustZone MCU? There will be questions on ROI.

A: All existing code will run. Need to modify for some changes in the register definitions and the programming of the MPU. We do not expect that there will be such a port since when doing a secure system, most likely the code structure needs to be revisited.

Q: How much program memory is available in TrustZone?

A: As much as the power on reset code that configures the regions chooses to assign.

Q: Would the MMU have to work with the SAU to assure security in external memories? If so, how does this work?

A: No. There is no MMU in Cortex-M, only MPU. The SAU defines the security attribute at the system level while the MPU is usually used by the system to control data access during thread execution.

Q: In Cortex-A, we have a secure monitor. Is it a sort of an API between the two worlds? Does this mechanism correspond to the SG instruction for Cortex-M series processors?

A: The entry to monitor can be triggered by software executing a dedicated instruction, the Secure Monitor Call (SMC) instruction, or by a subset of the hardware exception mechanisms. The API is an industry standard that comes from GlobalPlatform.

There is no SG instruction in the Cortex-A. For Cortex-M there is no need for a secure monitor due to directly calling.

We have a long list of documents in the TrustZone for Armv8-M Community to explain how the calling works.

Q: In Cortex-M, as far as I understood, the MPU does still exist in the 'Normal world' and the 'Secure world' respectively and can be used in each of both worlds respectively, is it correct?

A: Yes, each world has its own MPU block.

For more information and resources, please visit the TrustZone for Armv8-M Community where you’ll find a list of technical documents regarding TrustZone for Armv8-M. Free to join, open to all!

[CTAToken URL = "https://community.arm.com/processors/trustzone-for-armv8-m/" target="_blank" text="Visit TrustZone for Armv8-M Community" class ="green"]