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.*
