Chapter 8 Security of TrustZone technology for Armv8M against different attack scenarios
One of the common questions when talking about Secure system designs is: How Secure is it?
Many aspects of attack scenarios have been considered in the development of TrustZone technology for Armv8-M. For example:
- Software accesses
With extra system level components, memories can be partitioned between Secure and Non-secure spaces, and can disable Non-secure software from accessing Secure memories and resources.
- Branch to arbitrary Secure address locations
The SG instruction and NSC memory attribute ensures that a Non-secure to Secure branch can happen only at valid entry points.
- Inadvertent SG instruction in binary data
NSC memory attribute ensures that only Secure address spaces that are intended to be used as entry points can be used to switch the processor into the Secure state. Branching to an inadvertent SG instruction in an address location that is not marked as NSC results in a fault exception.
- Faking of a return address when calling a Secure API
When the SG instruction is executed, the return state of the function is stored in the LSB of the return address in the Link Register (LR). At the return of the function, this bit is checked against the return state to prevent the Secure API function (which was called from Non-secure side) from returning to a fake return address pointing to a Secure address.
- Attempting to switch to the Secure side using FNC_RETURN (function return code)
When switching from non-returnable Secure code (for example a Secure bootloader) to Non-secure, the BLXNS instruction must be used to ensure that there is a valid return stack. The return stack can then be used to enter an error handler.
This prevents Non-secure malicious code from trying to switch the processor to Secure code using the FNC_RETURN mechanism and crashing the Secure software if there is no valid return address in the Secure stack.
This recommendation does not apply when returning from a Secure API to Non-secure software, as this can use the BXNS instruction.
- Faking of EXC_RETURN (exception return code) to return to Secure state illegally
If a Non-secure interrupt takes place during Secure code execution, the processor automatically adds a signature value to the Secure stack frame.
If the Non-secure software attempts to use the interrupt return to switch to the Secure side illegally, the signature check at the exception return fails and hence the error is detected.
- Attempt to create stack overflow in Secure software
A stack limit feature is implemented for Secure stack pointers in both Armv8-M Mainline and Baseline sub-profiles. Therefore the fault exception handler detects and handles such stack overflows.
On the debug side, the architecture also handles the security requirements.
- Debug access management
Debug authentication signals are implemented on the processors so that designers can control if debug and trace operations are allowed for Secure and Non-secure states respectively.
AMBA bus interface protocols also support sideband signals in bus transactions, so the system can filter transfers to prevent debuggers from directly accessing Secure memories.
- Debug and trace management
The debug authentication signals can be set up to disable debug and trace operations when the processor is running in the Secure state.
Although the architecture is designed to handle many types of attack scenarios, Secure software must always be written with care and must utilize security features, for example, stack limit checks, to prevent vulnerabilities. The Arm C Language Extensions (ACLE) have been extended to include extra features to support the Armv8-M architecture, and software developers writing Secure software should utilize these features to enable their development tools to generate code images for Armv8-M devices.