diff options
author | Ken Liu <Ken.Liu@arm.com> | 2021-03-04 08:34:33 +0800 |
---|---|---|
committer | Ken Liu <ken.liu@arm.com> | 2021-03-05 16:22:03 +0100 |
commit | 975e0b33c01585e1fe70cafd6c00cdf6de948fcd (patch) | |
tree | 52a6ecc6188ade55e59d95376498e8f676176d1a /docs | |
parent | d85023feab29f750532aad5abb826d8ad77d9c86 (diff) | |
download | trusted-firmware-m-975e0b33c01585e1fe70cafd6c00cdf6de948fcd.tar.gz |
TFMV-2: Add SVC caller stack pointer fetching vulnerability.
Change-Id: Ib29b43c18a37efddef00cac3bb78bfb9825cfb54
Signed-off-by: Ken Liu <Ken.Liu@arm.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/reference/security.rst | 4 | ||||
-rw-r--r-- | docs/reference/security_advisories/svc_caller_sp_fetching_vulnerability.rst | 125 |
2 files changed, 129 insertions, 0 deletions
diff --git a/docs/reference/security.rst b/docs/reference/security.rst index 6d2cfbf56f..67632a9750 100644 --- a/docs/reference/security.rst +++ b/docs/reference/security.rst @@ -46,11 +46,15 @@ Security Advisories | |TFMV-1| | NS world may cause the CPU to perform an unexpected return | | | operation due to unsealed stacks. | +------------+-----------------------------------------------------------------+ +| |TFMV-2| | Invoking Secure functions from handler mode may cause TF-M IPC | +| | model to behave unexpectedly. | ++------------+-----------------------------------------------------------------+ .. _issue tracker: https://developer.trustedfirmware.org/project/view/2/ .. _mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-m .. |TFMV-1| replace:: :ref:`docs/reference/security_advisories/stack_seal_vulnerability:Advisory TFMV-1` +.. |TFMV-2| replace:: :ref:`docs/reference/security_advisories/svc_caller_sp_fetching_vulnerability:Advisory TFMV-2` .. _TrustedFirmware.org security incident process: https://developer.trustedfirmware.org/w/collaboration/security_center/ diff --git a/docs/reference/security_advisories/svc_caller_sp_fetching_vulnerability.rst b/docs/reference/security_advisories/svc_caller_sp_fetching_vulnerability.rst new file mode 100644 index 0000000000..4a117243fe --- /dev/null +++ b/docs/reference/security_advisories/svc_caller_sp_fetching_vulnerability.rst @@ -0,0 +1,125 @@ +Advisory TFMV-2 +=============== + ++----------------+-------------------------------------------------------------+ +| Title | Invoking Secure functions from handler mode may cause TF-M | +| | IPC model to behave unexpectedly. | ++================+=============================================================+ +| CVE ID | CVE-2021-27562 | ++----------------+-------------------------------------------------------------+ +| Date | Mar 5, 2021 | ++----------------+-------------------------------------------------------------+ +| Versions | Affected All versions up to and including TF-M v1.2 | +| Affected | | ++----------------+-------------------------------------------------------------+ +| Configurations | IPC Model (TFM_PSA_API=ON) on Armv8-M | ++----------------+-------------------------------------------------------------+ +| Impact | Most likely a crash in secure world or reset whole system, | +| | with a very low likelihood of overwriting some memory | +| | contents. | ++----------------+-------------------------------------------------------------+ +| Fix Version | commit `e212ea1637a66255b44d0e7c19ebe9786ab56ccb`_ | ++----------------+-------------------------------------------------------------+ +| Credit | Øyvind Rønningstad, | +| | Senior SW Engineer from Nordic Semiconductor | ++----------------+-------------------------------------------------------------+ + +Background +---------- + +When a non-secure caller calls the secure function, the execution switches the +security state via Secure Gateway (SG), then arrived at the TF-M secure entry +if the SG is successful. After SG, TF-M invokes SVC to SPM at first because SPM +handles requests from SPE and NSPE in a unified SVC handler. The TF-M SVC +handler code relies on the 'SPSEL' bit in 'EXC_RETURN' to get the caller stack +pointer: + +.. code-block:: asm + + ; Armv8m mainline as the example + mrs r2, msp ; r2 = msp; + tst lr, #4 ; EXC_RETURN.SPSEL == ? + ite eq ; condition preparation + moveq r0, r2 ; if (EXC_RETURN.SPSEL == 0) r0 = msp; + movne r0, psp ; if (EXC_RETURN.SPSEL == 1) r0 = psp; + mov r1, lr ; r1 = EXC_RETURN; + bl tfm_core_svc_handler ; r0 = sp(context), r1 = EXC_RETURN, r2 = msp + +If NSPE calls the secure function in 'Handler mode', the TF-M secure entry runs +in 'Handler mode' before invoking SVC because PE mode does not change during +the transition from non-secure state to secure state via the successful SG. +Main stack pointer (MSP) is always used in 'Handler mode', which is irrelevant +to the value of SPSEL. However, the code above selects secure process stack +pointer (PSP_S, S suffix here indicates the security state) for further SVC +handling based on EXC_RETURN.SPSEL, hence the SVC handler accesses the wrong +stack for handling the request in the NSPE caller in 'Handler mode' case. +To prevent this vulnerability, TF-M secure SVC handler should fetch the right +stack pointer register by checking both the PE mode and SPSEL bit. The handler +should also prevent callers in non-secure `Handler mode` from calling TF-M +SVC functionalities. The following section analysis impact of the IPC model. +Library model is not vulnerable to this attack because it checks the PE mode +in the TF-M secure entry. + +Impact +------ + +When the vulnerability is happening, PSP_S is the incorrect stack pointer +fetched, the impact is decided by the content PSP_S is pointing to. The SVC +handler gets the SVC number by referencing the memory at the 2 bytes subtracted +position of member 'Return Address' in the PSP_S pointing context, and uses the +caller saved registers in the context as parameters for the subsequent +functions indicated by the SVC number. The PSP_S may point to the bottom +(higher address) of secure thread stack if there is no ongoing secure function +call, or it points to a preempted context caused by non-secure preempting +secure execution. +When PSP_S is pointing to the stack bottom when this issue happens, the caller +context is pointing to the underflowed stack of which the top 2 words are stack +seal, and the rest of the context is unpredictable. These underflowed content +are ZERO initialized for most platforms, hence when fetching the SVC Number at +memory address 'Return Address - 2', a 'MemFault' or 'HardFault' would happen. +Even if a valid SVC number is returned, the stack seal values are part of the +parameters for the subsequent functions that have parameters, which cannot pass +the validation for the parameters. +When PSP_S is pointing to a preempted context, the preempted place can be the +TF-M secure entry area or internal thread space. If the preemption happens when +the execution is in the TF-M secure entry area, the PSP_S will point to an NS +preemption stack frame and hence will fail the context size validation through +this entry into TF-M SVC Handler. In the other scenario that TF-M internal +thread is preempted, there is a very remote chance that the exception stack +frame will contain a context with a valid SVC Number with valid parameters. +As a summary, the impacts of the vulnerability depend on whether an SVC number +could be fetched from the incorrect stack and what operation the fetched SVC +number corresponds to: + +- A memory access fault when fetching the SVC number from memory. This fault + halts the whole system. A reset can recover the system back to normal. +- The SVC number corresponds to the initialization process in TF-M. SPM + initialization is called for the second time. This re-initialization process + will fail and halt the whole system. A reset can recover the system back to + normal. +- The SVC number corresponds to the boot data fetching function. If the + unpredictable data in stack triggers boot data fetching and passes the + parameter validation under a very rare case, boot data is copied into an + unpredictable memory address. One note here, the TF-M default boot data has + no sensitive information. +- The SVC number corresponds to the log output function. If the unpredictable + data in stack triggers log output under a very rare case, secure data at + unpredictable address might be printed out through the log interface. +- The SVC number corresponds to other valid numbers other than above. The + system resets because of parameter validation fail. + +Conclusion +---------- + +Overall, from the analysis of upstream TF-M implementation, the severity of +this vulnerability is Medium, given that a software crash or system reset +happen most of the time. The probability for causing secure data leakage via +log output or tampering of secure memory with boot data is extremely low as the +TF-M internal thread exception stack frame contents have to pass all the +validations performed by SPM. + +.. _e212ea1637a66255b44d0e7c19ebe9786ab56ccb: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=e212ea1637a66255b44d0e7c19ebe9786ab56ccb + +-------------- + +*Copyright (c) 2021, Arm Limited. All rights reserved.* |