On Tue, Apr 08, 2025 at 10:48:08AM +0200, Alexandre Ghiti wrote:
On 14/03/2025 22:39, Deepak Gupta wrote:
Adding documentation on shadow stack for user mode on riscv and kernel interfaces exposed so that user tasks can enable it.
Reviewed-by: Zong Li zong.li@sifive.com Signed-off-by: Deepak Gupta debug@rivosinc.com
Documentation/arch/riscv/index.rst | 1 + Documentation/arch/riscv/zicfiss.rst | 176 +++++++++++++++++++++++++++++++++++ 2 files changed, 177 insertions(+)
diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst index be7237b69682..e240eb0ceb70 100644 --- a/Documentation/arch/riscv/index.rst +++ b/Documentation/arch/riscv/index.rst @@ -15,6 +15,7 @@ RISC-V architecture vector cmodx zicfilp
- zicfiss features
diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/riscv/zicfiss.rst new file mode 100644 index 000000000000..5ba389f15b3f --- /dev/null +++ b/Documentation/arch/riscv/zicfiss.rst @@ -0,0 +1,176 @@ +.. SPDX-License-Identifier: GPL-2.0
+:Author: Deepak Gupta debug@rivosinc.com +:Date: 12 January 2024
+========================================================= +Shadow stack to protect function returns on RISC-V Linux +=========================================================
<... snipped ..>
+5. violations related to returns with shadow stack enabled +-----------------------------------------------------------
+Pertaining to shadow stack, CPU raises software check exception in following +condition:
+- On execution of ``sspopchk x1/x5``, ``x1/x5`` didn't match top of shadow
- stack. If mismatch happens then cpu does ``*tval = 3`` and raise software
- check exception.
+Linux kernel will treat this as :c:macro:`SIGSEV`` with code = +:c:macro:`SEGV_CPERR` and follow normal course of signal delivery.
+6. Shadow stack tokens +----------------------- +Regular stores on shadow stacks are not allowed and thus can't be tampered +with via arbitrary stray writes due to bugs. Method of pivoting / switching to +shadow stack is simply writing to csr ``CSR_SSP`` changes active shadow stack.
I don't understand the end of this sentence.
I'll rephrase it to make it readable and understandable.
+This can be problematic because usually value to be written to ``CSR_SSP`` will +be loaded somewhere in writeable memory and thus allows an adversary to +corruption bug in software to pivot to an any address in shadow stack range.
Remove "an"
+Shadow stack tokens can help mitigate this problem by making sure that:
+- When software is switching away from a shadow stack, shadow stack pointer
- should be saved on shadow stack itself and call it ``shadow stack token``
+- When software is switching to a shadow stack, it should read the
- ``shadow stack token`` from shadow stack pointer and verify that
- ``shadow stack token`` itself is pointer to shadow stack itself.
+- Once the token verification is done, software can perform the write to
- ``CSR_SSP`` to switch shadow stack.
+Here software can be user mode task runtime itself which is managing various +contexts as part of single thread. Software can be kernel as well when kernel +has to deliver a signal to user task and must save shadow stack pointer. Kernel +can perform similar procedure by saving a token on user shadow stack itself. +This way whenever :c:macro:`sigreturn` happens, kernel can read the token and +verify the token and then switch to shadow stack. Using this mechanism, kernel +helps user task so that any corruption issue in user task is not exploited by +adversary by arbitrarily using :c:macro:`sigreturn`. Adversary will have to +make sure that there is a ``shadow stack token`` in addition to invoking +:c:macro:`sigreturn`
+7. Signal shadow stack +----------------------- +Following structure has been added to sigcontext for RISC-V::
- struct __sc_riscv_cfi_state {
unsigned long ss_ptr;
- };
+As part of signal delivery, shadow stack token is saved on current shadow stack +itself and updated pointer is saved away in :c:macro:`ss_ptr` field in +:c:macro:`__sc_riscv_cfi_state` under :c:macro:`sigcontext`. Existing shadow +stack allocation is used for signal delivery. During :c:macro:`sigreturn`, +kernel will obtain :c:macro:`ss_ptr` from :c:macro:`sigcontext` and verify the +saved token on shadow stack itself and switch shadow stack.