1Advisory TFMV-2
2===============
3
4+----------------+-------------------------------------------------------------+
5| Title          | Invoking Secure functions from handler mode may cause TF-M  |
6|                | IPC model to behave unexpectedly.                           |
7+================+=============================================================+
8| CVE ID         | CVE-2021-27562                                              |
9+----------------+-------------------------------------------------------------+
10| Date           | Mar 5, 2021                                                 |
11+----------------+-------------------------------------------------------------+
12| Versions       | Affected All versions up to and including TF-M v1.2         |
13| Affected       |                                                             |
14+----------------+-------------------------------------------------------------+
15| Configurations | IPC Model on Armv8-M                                        |
16+----------------+-------------------------------------------------------------+
17| Impact         | Most likely a crash in secure world or reset whole system,  |
18|                | with a very low likelihood of overwriting some memory       |
19|                | contents.                                                   |
20+----------------+-------------------------------------------------------------+
21| Fix Version    | commit `e212ea1637a66255b44d0e7c19ebe9786ab56ccb`_          |
22+----------------+-------------------------------------------------------------+
23| Credit         | Øyvind Rønningstad,                                         |
24|                | Senior SW Engineer from Nordic Semiconductor                |
25+----------------+-------------------------------------------------------------+
26
27Background
28----------
29
30When a non-secure caller calls the secure function, the execution switches the
31security state via Secure Gateway (SG), then arrived at the TF-M secure entry
32if the SG is successful. After SG, TF-M invokes SVC to SPM at first because SPM
33handles requests from SPE and NSPE in a unified SVC handler. The TF-M SVC
34handler code relies on the 'SPSEL' bit in 'EXC_RETURN' to get the caller stack
35pointer:
36
37.. code-block:: asm
38
39  ; Armv8m mainline as the example
40  mrs        r2, msp              ; r2 = msp;
41  tst        lr, #4               ; EXC_RETURN.SPSEL == ?
42  ite        eq                   ; condition preparation
43  moveq      r0, r2               ; if (EXC_RETURN.SPSEL == 0) r0 = msp;
44  movne      r0, psp              ; if (EXC_RETURN.SPSEL == 1) r0 = psp;
45  mov        r1, lr               ; r1 = EXC_RETURN;
46  bl         tfm_core_svc_handler ; r0 = sp(context), r1 = EXC_RETURN, r2 = msp
47
48If NSPE calls the secure function in 'Handler mode', the TF-M secure entry runs
49in 'Handler mode' before invoking SVC because PE mode does not change during
50the transition from non-secure state to secure state via the successful SG.
51Main stack pointer (MSP) is always used in 'Handler mode', which is irrelevant
52to the value of SPSEL. However, the code above selects secure process stack
53pointer (PSP_S, S suffix here indicates the security state) for further SVC
54handling based on EXC_RETURN.SPSEL, hence the SVC handler accesses the wrong
55stack for handling the request in the NSPE caller in 'Handler mode' case.
56To prevent this vulnerability, TF-M secure SVC handler should fetch the right
57stack pointer register by checking both the PE mode and SPSEL bit. The handler
58should also prevent callers in non-secure `Handler mode` from calling TF-M
59SVC functionalities. The following section analysis impact of the IPC model.
60Library model is not vulnerable to this attack because it checks the PE mode
61in the TF-M secure entry.
62
63Impact
64------
65
66When the vulnerability is happening, PSP_S is the incorrect stack pointer
67fetched, the impact is decided by the content PSP_S is pointing to. The SVC
68handler gets the SVC number by referencing the memory at the 2 bytes subtracted
69position of member 'Return Address' in the PSP_S pointing context, and uses the
70caller saved registers in the context as parameters for the subsequent
71functions indicated by the SVC number. The PSP_S may point to the bottom
72(higher address) of secure thread stack if there is no ongoing secure function
73call, or it points to a preempted context caused by non-secure preempting
74secure execution.
75When PSP_S is pointing to the stack bottom when this issue happens, the caller
76context is pointing to the underflowed stack of which the top 2 words are stack
77seal, and the rest of the context is unpredictable. These underflowed content
78are ZERO initialized for most platforms, hence when fetching the SVC Number at
79memory address 'Return Address - 2', a 'MemFault' or 'HardFault' would happen.
80Even if a valid SVC number is returned, the stack seal values are part of the
81parameters for the subsequent functions that have parameters, which cannot pass
82the validation for the parameters.
83When PSP_S is pointing to a preempted context, the preempted place can be the
84TF-M secure entry area or internal thread space. If the preemption happens when
85the execution is in the TF-M secure entry area, the PSP_S will point to an NS
86preemption stack frame and hence will fail the context size validation through
87this entry into TF-M SVC Handler. In the other scenario that TF-M internal
88thread is preempted, there is a very remote chance that the exception stack
89frame will contain a context with a valid SVC Number with valid parameters.
90As a summary, the impacts of the vulnerability depend on whether an SVC number
91could be fetched from the incorrect stack and what operation the fetched SVC
92number corresponds to:
93
94- A memory access fault when fetching the SVC number from memory. This fault
95  halts the whole system. A reset can recover the system back to normal.
96- The SVC number corresponds to the initialization process in TF-M. SPM
97  initialization is called for the second time. This re-initialization process
98  will fail and halt the whole system. A reset can recover the system back to
99  normal.
100- The SVC number corresponds to the boot data fetching function. If the
101  unpredictable data in stack triggers boot data fetching and passes the
102  parameter validation under a very rare case, boot data is copied into an
103  unpredictable memory address. One note here, the TF-M default boot data has
104  no sensitive information.
105- The SVC number corresponds to the log output function. If the unpredictable
106  data in stack triggers log output under a very rare case, secure data at
107  unpredictable address might be printed out through the log interface.
108- The SVC number corresponds to other valid numbers other than above. The
109  system resets because of parameter validation fail.
110
111Conclusion
112----------
113
114Overall, from the analysis of upstream TF-M implementation, the severity of
115this vulnerability is Medium, given that a software crash or system reset
116happen most of the time. The probability for causing secure data leakage via
117log output or tampering of secure memory with boot data is extremely low as the
118TF-M internal thread exception stack frame contents have to pass all the
119validations performed by SPM.
120
121.. _e212ea1637a66255b44d0e7c19ebe9786ab56ccb: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=e212ea1637a66255b44d0e7c19ebe9786ab56ccb
122
123--------------
124
125*Copyright (c) 2021, Arm Limited. All rights reserved.*
126