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.
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.
A: Yes. Assuming both toolchains support the same Arm ABI and ACLE.
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.
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.
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.
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.
A: Arm has an FPGA board (MPS2+) and we expect partners to start releasing development boards soon.
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.
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.
A: The GNU Arm Embedded Toolchain support TrustZone for Armv8-M fully from the 6-2017-q1-update. See: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm. The features are supported in Arm compiler 6.
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.
A: If the floating point registers are in use they will be automatically stacked and cleared on taking an exception.
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.
A: Alignment rules for memory accesses are the same as for Armv7-M. MPU and SAU regions are aligned to 32 bytes but unlike v7-M they don’t need to be aligned to the region size.
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 found here:
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 8 coprocessors, it does not specify what the coprocessor 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.
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: https://github.com/Armmbed/uvisor
A: The entry points are supplied as a symbol file by the secure software developer
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.
A: That is not something that we are able to comment about. The partner product plans are their own.
A: The developer of the secure code will share a symbol file and the API specification.
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.
A: The software complexity required to support these standards will be reduced due to the hardware assist from TrustZone in the processor.
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.
A: The specification is found here
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.
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.
A: As much as the power on reset code that configures the regions chooses to assign.
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.
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 https://www.globalplatform.org.
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.
one written interpretation of the webinar is here