Q: What is the impact of a stack underflow attack? How easy it is to compromise a system using a stack underflow attack?
In most cases, an invalid function return would cause the processor to branch to an unpredictable address, depending on the content in the Secure stack space. The likely outcome is that the Secure software would crash or enter a fault exception. However, under certain situations Non-secure software may be able to influence the memory above the Secure stack pointer to control the target address of the function return.
If the stack underflow attack is carried out by an invalid exception return, it is very likely that a fault exception would be triggered due to mismatch of integrity signature in the stack frame. In the unlikely case where the bottom of the stack contains a value matching an integrity signature, the exception return could result in the processor branching to an unpredictable address, depending on the content in the Secure stack space.
In both cases the stack underflow does not directly result in the leakage of Secure information. Any further impact is entirely dependent on the software. That is, additional attack steps are needed to fullycompromise the system.
Q: What is the impact of this vulnerability on an Armv8-M-based processor without Security Extension?
An Armv8-M-based processor without the Security Extension called TrustZone will not have any impact from this vulnerability. This vulnerability affects only the software that is based on Armv8-M processors with the Security Extension.
The vulnerability is not applicable to software running on Armv7-M and Armv6-M processors.
Q: What is the impact to application software that runs on the Secure world and the Non-secure world is not used?
In systems where the Non-secure world is not used, effectively the system is not using the Security Extension. Hence it is not affected.
Q: My Secure software does not perform complex transitions across the Secure and Non-secure world. Will I still be affected by this vulnerability?
On an Armv8-M-based processor with a Security Extension, if the Secure software uses only the main stack pointer (MSP_S) and uses only BLXNS instruction to switch from the Secure to Non-secure state, or through interrupt sequences, the system is not affected by this vulnerability. However, to ensure that the system is protected against stack underflow attacks, Arm recommends sealing the Secure stacks that are used in the system.
Q: Will there be an errata notification for Cortex-M processors that implement the Security Extension, for example Cortex-M33, Cortex-M55?
No. This vulnerability does not affect the processor hardware.
Q: What is the impact on Arm Cycle Model and Arm Fixed Virtual Platform (FVP) products?
Arm Cycle Model and Arm Fast Model products are software models of Arm processor hardware. Because this is a software vulnerability, models of the hardware are not affected. Software running on the models might be affected.
Q: What is the guidance for software developers using Arm Compiler 6?
On an Armv8-M-based processor with Security Extension, a software developer should seal the Secure stacks used in the system to ensure that stack underflow attacks are detected and stopped. Although there are other possible ways to seal the stacks, the two main variations recommended in Arm Compiler 6 are:
- Place the seal value after the stack in memory using scatter-loading
- Wrap a function that executes before main
More details on how above variations work can be found in the Armv8-M Secure Stack Sealing advisory notice.
Even when the Secure world stacks are sealed before entering main, if new Secure stacks are created as part of the application then the Secure software must seal these stacks.
Q: What is the guidance for software developers using GCC compiler?
If you are using Armv8-M-based processors with a Security Extension, there is a potential impact of this vulnerability in your Secure software. To mitigate this vulnerability, software developer should seal Secure stacks. Refer to example code sequences in the Armv8-M Secure Stack Sealing advisory notice for more details.
Q: What is the guidance for software developers using IAR Embedded Workbench® for Arm?
IAR Systems® has released a technical note about sealing the Secure stack. Please note that Arm is not responsible for the content of non-Arm websites.
Q: What is the impact on CMSIS-packs?
Examples and libraries that are delivered as CMSIS packs that use Secure features may be affected by this vulnerability. Contact the provider of the CMSIS pack to check if affected and on the availability of updates.
Q: What is the impact when using Keil MDK, Arm DS-5, or Arm Development Studio products?
Keil MDK, Arm DS-5, and Arm Developer Studio products all contain Arm Compiler 6. Refer to What is the guidance for software developers using Arm Compiler 6? in this FAQ to understand the impact on Arm Compiler 6.
These IDEs also allow the use of CMSIS pack examples and libraries. Please refer to What is the impact on CMSIS-packs? in this FAQ to understand the impact when using CMSIS packs.
Q: What is the impact on Trusted Firmware-M?
Because Trusted Firmware-M is an open-source community project, patches required for this vulnerability will be published in the upstream Trusted Firmware-M repository at https://www.trustedfirmware.org/.
Q: What is the impact on Mbed OS?
Starting from Mbed OS version 5, the Secure world software is based on Trusted Firmware-M. Please update to the latest releases of Trusted Firmware-M. Mbed OS software that runs on the Non-secure world is not affected.
Q: What is the impact when using an RTOS?
An RTOS running in the Non-secure world is not affected. An RTOS running in the Secure world should ensure that all Secure stacks are sealed, including any Secure stacks created for RTOS processes or threads. Contact your RTOS vendor to check whether they are affected.