TFMV-1: Add Stack seal advisory
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Change-Id: Ifbadc2d59cfb91e3ae09910a270d2358e378b3e6
diff --git a/docs/reference/security_advisories/index.rst b/docs/reference/security_advisories/index.rst
new file mode 100644
index 0000000..8511908
--- /dev/null
+++ b/docs/reference/security_advisories/index.rst
@@ -0,0 +1,12 @@
+Security Advisories
+===================
+
+.. toctree::
+ :maxdepth: 1
+ :glob:
+
+ *
+
+--------------
+
+*Copyright (c) 2020, Arm Limited. All rights reserved.*
diff --git a/docs/reference/security_advisories/stack_seal_vulnerability.rst b/docs/reference/security_advisories/stack_seal_vulnerability.rst
new file mode 100644
index 0000000..2bf9d1a
--- /dev/null
+++ b/docs/reference/security_advisories/stack_seal_vulnerability.rst
@@ -0,0 +1,113 @@
+Advisory TFMV-1
+===============
+
++----------------+-------------------------------------------------------------+
+| Title | NS world may cause the CPU to perform an unexpected return |
+| | operation due to unsealed stacks. |
++================+=============================================================+
+| CVE ID | CVE-2020-16273 |
++----------------+-------------------------------------------------------------+
+| Date | 16 October 2020 |
++----------------+-------------------------------------------------------------+
+| Versions | All versions up to and including TF-M v1.1 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | All |
++----------------+-------------------------------------------------------------+
+| Impact | Most likely a crash in secure world with a very low |
+| | likelihood of hijacking secure world execution flow via a |
+| | separate vulnerability. |
++----------------+-------------------------------------------------------------+
+| Fix Version | commit `92e46a3abd0e328fac29ccd1cf161cd482397567`_ |
++----------------+-------------------------------------------------------------+
+| Credit | Matvey Mukha |
++----------------+-------------------------------------------------------------+
+
+Background
+----------
+
+When the Non-Secure world returns to Secure after a callback (FNC_RETURN) or
+Non-Secure interrupt handling (EXC_RETURN), the hardware pops the secure return
+address and RET_PSR from the respective secure stack. The hardware performs a
+set of integrity checks at this point and will raise a fault if the checks
+fail. There is a potential vulnerability if the NS attempts a wrong FNC_RETURN
+or EXC_RETURN and causes the PE to pop from the unexpected stack. Please
+refer to `ARMv8-M Secure stack sealing advisory notice`_ for more
+details on the vulnerability.
+
+To prevent such an attack, the architecture expects the secure software to
+`seal` the stacks. The `ARMv8-M ARM`_ states that the stack should be sealed
+with the special value, 0xFEF5EDA5 (informative IGJGL).
+
+Both the MSP_S and the PSP_S stacks need to be sealed to mitigate stack
+underflow attacks and this is not done currently in TF-M.
+
+Impact
+------
+
+This section analyses the impact of this vulnerability on the upstream
+TF-M implementation.
+
+All requests coming in from the Non-Secure world uses ARM_LIB_STACK as the
+PSP_S and then switches to MSP_S as part of SPM scheduling. The MSP_S is fully
+unwound when the scheduled partition is executing. All partitions run using
+the PSP_S and this stack can be separate for each partition or be a common
+stack depending on whether TF-M is in library mode or IPC mode. When the
+partition execution using PSP_S switches to non-secure world due to a
+non-secure interrupt or a non-secure callback invocation, the non-secure
+world on return back to secure can use a fake EXC_RETURN or FNC_RETURN
+operation to trigger an MSP_S stack underflow, and the CPU could fetch
+the return PC and PSR from the memory just above MSP_S stack (stack grows
+from higher to lower address).
+
+The memory above MSP_S is the ARM_LIB_STACK (as described by
+tfm_common_s.sct/ld), which because of overlaying or zero initialization
+is most likely to be initialized memory for most platforms. This is the stack
+used to run the initialization code of TF-M and usually there will some
+unused free space in the stack. Any underflow of MSP_S will be into this stack
+and hence is likely to be a deterministic crash given that this memory is
+initialized. In theory, a separate vulnerability that allows an attacker to
+control the memory above MSP_S in concert with this vulnerability could
+enable an attacker to hijack the secure world execution flow but the
+likelihood of that is very low.
+
+Through analysing TF-M specific initialization and execution flow, we have
+not found any scenario in TF-M in which Non-secure world can fake a return
+operation back to secure world and cause underflow of PSP_S.
+
+As described in the white paper, de-privileged interrupt handling is
+also vulnerable to this problem. The Library mode of TF-M uses de-privileged
+interrupt handling and does not allow non-secure interrupt to pre-empt the
+secure interrupt handling. But if the de-privileged handler makes a
+Non-Secure callback then there is a chance that Non-Secure world could
+return back to Secure world via a fake FNC_RETURN. Under certain
+conditions, this can force the CPU to use the 2 words on top of stack as
+return PC and PSR. Sealing the top of MSP_S before switching to PSP_S as
+part of de-privileged interrupt handling mitigates this vulnerability.
+
+The interrupt handling in IPC mode uses PSA signal to signal the partition
+and does not use de-privileged interrupt handling mechanism. The PSA signal
+gets handled by the partition when it is scheduled to run by the SPM. Hence
+during interrupt handling in IPC mode, there is no additional threat caused
+by this vulnerability, compared to regular partition execution.
+
+Conclusion
+----------
+
+Overall, from analysis of upstream TF-M implementation, the severity of this
+vulnerability is low, given that the values popped out from secure stack
+(either via underflow of MSP_S or from top of MSP_S stack in de-privileged
+interrupt handling) cannot be influenced by the Non Secure world. To mitigate
+the risk completely, the fix in TF-M is to follow the recommendation in
+`ARMv8-M ARM`_ which is to seal the base of both handler mode stack (MSP_S)
+and thread stacks (PSP_S) and, in case of library mode, also seal the top
+of MSP_S before handing control over to de-privileged interrupt handler.
+
+
+.. _ARMv8-M ARM: https://developer.arm.com/documentation/ddi0553/latest
+.. _ARMv8-M Secure stack sealing advisory notice: https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing
+.. _92e46a3abd0e328fac29ccd1cf161cd482397567: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=92e46a3abd0e328fac29ccd1cf161cd482397567
+
+--------------
+
+*Copyright (c) 2020, Arm Limited. All rights reserved.*