TFMV-2: Add SVC caller stack pointer fetching vulnerability.
Change-Id: Ib29b43c18a37efddef00cac3bb78bfb9825cfb54
Signed-off-by: Ken Liu <Ken.Liu@arm.com>
diff --git a/docs/reference/security.rst b/docs/reference/security.rst
index 6d2cfbf..67632a9 100644
--- a/docs/reference/security.rst
+++ b/docs/reference/security.rst
@@ -46,11 +46,15 @@
| |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 0000000..4a11724
--- /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.*