Re: [PATCH v12 27/28] riscv: Documentation for shadow stack on riscv

[Deepak Gupta]

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@xxxxxxxxxx>
> > Signed-off-by: Deepak Gupta <debug@xxxxxxxxxxxx>
> > ---
> >  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@xxxxxxxxxxxx>
> > +: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.