| Message ID | 20240912231650.3740732-30-debug@rivosinc.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | riscv control-flow integrity for usermode | expand |
On Thu, Sep 12, 2024 at 04:16:48PM -0700, Deepak Gupta wrote: > Adding documentation on shadow stack for user mode on riscv and kernel > interfaces exposed so that user tasks can enable it. > > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > --- > Documentation/arch/riscv/zicfiss.rst | 169 +++++++++++++++++++++++++++ > 1 file changed, 169 insertions(+) > create mode 100644 Documentation/arch/riscv/zicfiss.rst Add the toctree entry: ---- >8 ---- diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst index be7237b6968213..e240eb0ceb70c4 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 > +Following structure has been added to sigcontext for RISC-V. `rsvd` field has been kept > +in case we need some extra information in future for landing pads / indirect branch > +tracking. It has been kept today in order to allow backward compatibility in future. > + > +struct __sc_riscv_cfi_state { > + unsigned long ss_ptr; > + unsigned long rsvd; > +}; Sphinx reports indentation warning again: Documentation/arch/riscv/zicfiss.rst:163: WARNING: Definition list ends without a blank line; unexpected unindent. I have to wrap __sc_riscv_cfi_state struct definition as a literal code block: ---- >8 ---- diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/riscv/zicfiss.rst index f133b6af9c1525..96d85ed352b146 100644 --- a/Documentation/arch/riscv/zicfiss.rst +++ b/Documentation/arch/riscv/zicfiss.rst @@ -155,12 +155,12 @@ make sure that there is a `shadow stack token` in addition to invoking `sigretur ----------------------- Following structure has been added to sigcontext for RISC-V. `rsvd` field has been kept in case we need some extra information in future for landing pads / indirect branch -tracking. It has been kept today in order to allow backward compatibility in future. +tracking. It has been kept today in order to allow backward compatibility in future:: -struct __sc_riscv_cfi_state { + struct __sc_riscv_cfi_state { unsigned long ss_ptr; unsigned long rsvd; -}; + }; As part of signal delivery, shadow stack token is saved on current shadow stack itself and updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state` under `sigcontext` > + > +As part of signal delivery, shadow stack token is saved on current shadow stack itself and > +updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state` under `sigcontext` > +Existing shadow stack allocation is used for signal delivery. During `sigreturn`, kernel will > +obtain `ss_ptr` from `sigcontext` and verify the saved token on shadow stack itself and switch > +shadow stack. Also inline the code identifiers (keywords): ---- >8 ---- diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/riscv/zicfiss.rst index 96d85ed352b146..9f721fbcaa6f6a 100644 --- a/Documentation/arch/riscv/zicfiss.rst +++ b/Documentation/arch/riscv/zicfiss.rst @@ -23,30 +23,30 @@ of the program. Return addresses live on stack and thus in read-write memory and thus are susceptible to corruption and allows an adversary to reach any program counter -(PC) in address space. On RISC-V `zicfiss` extension provides an alternate stack -`shadow stack` on which return addresses can be safely placed in prolog of the -function and retrieved in epilog. `zicfiss` extension makes following changes +(PC) in address space. On RISC-V ``zicfiss`` extension provides an alternate stack +(`shadow stack`) on which return addresses can be safely placed in prolog of the +function and retrieved in epilog. ``zicfiss`` extension makes following changes: - PTE encodings for shadow stack virtual memory An earlier reserved encoding in first stage translation i.e. PTE.R=0, PTE.W=1, PTE.X=0 becomes PTE encoding for shadow stack pages. - - `sspush x1/x5` instruction pushes (stores) `x1/x5` to shadow stack. + - ``sspush x1/x5`` instruction pushes (stores) `x1/x5`` to shadow stack. - - `sspopchk x1/x5` instruction pops (loads) from shadow stack and compares - with `x1/x5` and if un-equal, CPU raises `software check exception` with - `*tval = 3` + - ``sspopchk x1/x5`` instruction pops (loads) from shadow stack and compares + with ``x1/x5`` and if not equal, CPU raises software check exception + with ``*tval = 3`` -Compiler toolchain makes sure that function prologs have `sspush x1/x5` to save return -address on shadow stack in addition to regular stack. Similarly function epilogs have -`ld x5, offset(x2)`; `sspopchk x5` to ensure that popped value from regular stack -matches with popped value from shadow stack. +Compiler toolchain makes sure that function prologs have ``sspush x1/x5`` to +save return address on shadow stack in addition to regular stack. Similarly +function epilogs have ``ld x5, offset(x2); sspopchk x5`` to ensure that popped +value from regular stack matches with popped value from shadow stack. 2. Shadow stack protections and linux memory manager ----------------------------------------------------- As mentioned earlier, shadow stack get new page table encodings and thus have some -special properties assigned to them and instructions that operate on them as below +special properties assigned to them and instructions that operate on them as below: - Regular stores to shadow stack memory raises access store faults. This way shadow stack memory is protected from stray inadvertant @@ -60,11 +60,11 @@ special properties assigned to them and instructions that operate on them as bel shadow stack store. - Shadow stack load / shadow stack store on read-only memory raises - AMO/store page fault. Thus both `sspush x1/x5` and `sspopchk x1/x5` + AMO/store page fault. Thus both ``sspush x1/x5`` and ``sspopchk x1/x5`` will raise AMO/store page fault. This simplies COW handling in kernel During fork, kernel can convert shadow stack pages into read-only memory (as it does for regular read-write memory) and as soon as - subsequent `sspush` or `sspopchk` in userspace is encountered, then + subsequent ``sspush`` or ``sspopchk`` in userspace is encountered, then kernel can perform COW. - Shadow stack load / shadow stack store on read-write, read-write- @@ -75,8 +75,8 @@ special properties assigned to them and instructions that operate on them as bel 3. ELF and psABI ----------------- -Toolchain sets up `GNU_PROPERTY_RISCV_FEATURE_1_BCFI` for property -`GNU_PROPERTY_RISCV_FEATURE_1_AND` in notes section of the object file. +Toolchain sets up ``GNU_PROPERTY_RISCV_FEATURE_1_BCFI`` for property +``GNU_PROPERTY_RISCV_FEATURE_1_AND`` in notes section of the object file. 4. Linux enabling ------------------ @@ -89,25 +89,25 @@ shadow stack for the program. 5. prctl() enabling -------------------- -`PR_SET_SHADOW_STACK_STATUS` / `PR_GET_SHADOW_STACK_STATUS` / -`PR_LOCK_SHADOW_STACK_STATUS` are three prctls added to manage shadow stack +``PR_SET_SHADOW_STACK_STATUS`` / ``PR_GET_SHADOW_STACK_STATUS`` / +``PR_LOCK_SHADOW_STACK_STATUS`` are three prctls added to manage shadow stack enabling for tasks. prctls are arch agnostic and returns -EINVAL on other arches. -`PR_SET_SHADOW_STACK_STATUS`: If arg1 `PR_SHADOW_STACK_ENABLE` and if CPU supports -`zicfiss` then kernel will enable shadow stack for the task. Dynamic loader can -issue this `prctl` once it has determined that all the objects loaded in address -space have support for shadow stack. Additionally if there is a `dlopen` to an -object which wasn't compiled with `zicfiss`, dynamic loader can issue this prctl -with arg1 set to 0 (i.e. `PR_SHADOW_STACK_ENABLE` being clear) +``PR_SET_SHADOW_STACK_STATUS``: If arg1 ``PR_SHADOW_STACK_ENABLE`` and if CPU supports +``zicfiss`` then kernel will enable shadow stack for the task. Dynamic loader can +issue this ``prctl`` once it has determined that all the objects loaded in address +space have support for shadow stack. Additionally if there is a ``dlopen`` to an +object which wasn't compiled with ``zicfiss``, dynamic loader can issue this prctl +with arg1 set to 0 (i.e. ``PR_SHADOW_STACK_ENABLE`` being clear) -`PR_GET_SHADOW_STACK_STATUS`: Returns current status of indirect branch tracking. -If enabled it'll return `PR_SHADOW_STACK_ENABLE` +``PR_GET_SHADOW_STACK_STATUS``: Returns current status of indirect branch tracking. +If enabled it'll return ``PR_SHADOW_STACK_ENABLE`` -`PR_LOCK_SHADOW_STACK_STATUS`: Locks current status of shadow stack enabling on the -task. User space may want to run with strict security posture and wouldn't want -loading of objects without `zicfiss` support in it and thus would want to disallow -disabling of shadow stack on current task. In that case user space can use this prctl -to lock current settings. +``PR_LOCK_SHADOW_STACK_STATUS``: Locks current status of shadow stack enabling +on the task. User space may want to run with strict security posture and +wouldn't want loading of objects without ``zicfiss`` support in it and thus +would want to disallow disabling of shadow stack on current task. In that case +user space can use this prctl to lock current settings. 5. violations related to returns with shadow stack enabled ----------------------------------------------------------- @@ -115,22 +115,22 @@ to lock current settings. 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 + - 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 `SIGSEV`` with code = `SEGV_CPERR` and follow +Linux kernel will treat this as ``SIGSEV`` with ``SEGV_CPERR`` code 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. 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. Shadow stack tokens can help mitigate this problem by -making sure that: +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. +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. +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` @@ -139,31 +139,34 @@ making sure that: 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. + - 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 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 `sigreturn`. Adversary will have to -make sure that there is a `shadow stack token` in addition to invoking `sigreturn` +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 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 ``sigreturn``. Adversary will have to make sure that there is +a `shadow stack token` in addition to invoking ``sigreturn`` 7. Signal shadow stack ----------------------- -Following structure has been added to sigcontext for RISC-V. `rsvd` field has been kept -in case we need some extra information in future for landing pads / indirect branch -tracking. It has been kept today in order to allow backward compatibility in future:: +Following structure has been added to sigcontext for RISC-V. ``rsvd`` field has +been kept in case we need some extra information in future for landing pads / +indirect branch tracking. It has been kept today in order to allow backward +compatibility in future:: struct __sc_riscv_cfi_state { unsigned long ss_ptr; unsigned long rsvd; }; -As part of signal delivery, shadow stack token is saved on current shadow stack itself and -updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state` under `sigcontext` -Existing shadow stack allocation is used for signal delivery. During `sigreturn`, kernel will -obtain `ss_ptr` from `sigcontext` and verify the saved token on shadow stack itself and switch -shadow stack. +As part of signal delivery, shadow stack token is saved on current shadow stack +itself and updated pointer is saved away in ``ss_ptr`` field in +``__sc_riscv_cfi_state`` under ``sigcontext`` Existing shadow stack allocation +is used for signal delivery. During ``sigreturn``, kernel will obtain +``ss_ptr`` from ``sigcontext`` and verify the saved token on shadow stack +itself and switch shadow stack. Thanks.
diff --git a/Documentation/arch/riscv/zicfiss.rst b/Documentation/arch/riscv/zicfiss.rst new file mode 100644 index 000000000000..f133b6af9c15 --- /dev/null +++ b/Documentation/arch/riscv/zicfiss.rst @@ -0,0 +1,169 @@ +.. 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 +========================================================= + +This document briefly describes the interface provided to userspace by Linux +to enable shadow stack for user mode applications on RISV-V + +1. Feature Overview +-------------------- + +Memory corruption issues usually result in to crashes, however when in hands of +an adversary and if used creatively can result into variety security issues. + +One of those security issues can be code re-use attacks on program where adversary +can use corrupt return addresses present on stack and chain them together to perform +return oriented programming (ROP) and thus compromising control flow integrity (CFI) +of the program. + +Return addresses live on stack and thus in read-write memory and thus are +susceptible to corruption and allows an adversary to reach any program counter +(PC) in address space. On RISC-V `zicfiss` extension provides an alternate stack +`shadow stack` on which return addresses can be safely placed in prolog of the +function and retrieved in epilog. `zicfiss` extension makes following changes + + - PTE encodings for shadow stack virtual memory + An earlier reserved encoding in first stage translation i.e. + PTE.R=0, PTE.W=1, PTE.X=0 becomes PTE encoding for shadow stack pages. + + - `sspush x1/x5` instruction pushes (stores) `x1/x5` to shadow stack. + + - `sspopchk x1/x5` instruction pops (loads) from shadow stack and compares + with `x1/x5` and if un-equal, CPU raises `software check exception` with + `*tval = 3` + +Compiler toolchain makes sure that function prologs have `sspush x1/x5` to save return +address on shadow stack in addition to regular stack. Similarly function epilogs have +`ld x5, offset(x2)`; `sspopchk x5` to ensure that popped value from regular stack +matches with popped value from shadow stack. + +2. Shadow stack protections and linux memory manager +----------------------------------------------------- + +As mentioned earlier, shadow stack get new page table encodings and thus have some +special properties assigned to them and instructions that operate on them as below + + - Regular stores to shadow stack memory raises access store faults. + This way shadow stack memory is protected from stray inadvertant + writes + + - Regular loads to shadow stack memory are allowed. + This allows stack trace utilities or backtrace functions to read + true callstack (not tampered) + + - Only shadow stack instructions can generate shadow stack load or + shadow stack store. + + - Shadow stack load / shadow stack store on read-only memory raises + AMO/store page fault. Thus both `sspush x1/x5` and `sspopchk x1/x5` + will raise AMO/store page fault. This simplies COW handling in kernel + During fork, kernel can convert shadow stack pages into read-only + memory (as it does for regular read-write memory) and as soon as + subsequent `sspush` or `sspopchk` in userspace is encountered, then + kernel can perform COW. + + - Shadow stack load / shadow stack store on read-write, read-write- + execute memory raises an access fault. This is a fatal condition + because shadow stack should never be operating on read-write, read- + write-execute memory. + +3. ELF and psABI +----------------- + +Toolchain sets up `GNU_PROPERTY_RISCV_FEATURE_1_BCFI` for property +`GNU_PROPERTY_RISCV_FEATURE_1_AND` in notes section of the object file. + +4. Linux enabling +------------------ + +User space programs can have multiple shared objects loaded in its address space +and it's a difficult task to make sure all the dependencies have been compiled +with support of shadow stack. Thus it's left to dynamic loader to enable +shadow stack for the program. + +5. prctl() enabling +-------------------- + +`PR_SET_SHADOW_STACK_STATUS` / `PR_GET_SHADOW_STACK_STATUS` / +`PR_LOCK_SHADOW_STACK_STATUS` are three prctls added to manage shadow stack +enabling for tasks. prctls are arch agnostic and returns -EINVAL on other arches. + +`PR_SET_SHADOW_STACK_STATUS`: If arg1 `PR_SHADOW_STACK_ENABLE` and if CPU supports +`zicfiss` then kernel will enable shadow stack for the task. Dynamic loader can +issue this `prctl` once it has determined that all the objects loaded in address +space have support for shadow stack. Additionally if there is a `dlopen` to an +object which wasn't compiled with `zicfiss`, dynamic loader can issue this prctl +with arg1 set to 0 (i.e. `PR_SHADOW_STACK_ENABLE` being clear) + +`PR_GET_SHADOW_STACK_STATUS`: Returns current status of indirect branch tracking. +If enabled it'll return `PR_SHADOW_STACK_ENABLE` + +`PR_LOCK_SHADOW_STACK_STATUS`: Locks current status of shadow stack enabling on the +task. User space may want to run with strict security posture and wouldn't want +loading of objects without `zicfiss` support in it and thus would want to disallow +disabling of shadow stack on current task. In that case user space can use this prctl +to lock current settings. + +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 `SIGSEV`` with code = `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. 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. 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 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 `sigreturn`. Adversary will have to +make sure that there is a `shadow stack token` in addition to invoking `sigreturn` + +7. Signal shadow stack +----------------------- +Following structure has been added to sigcontext for RISC-V. `rsvd` field has been kept +in case we need some extra information in future for landing pads / indirect branch +tracking. It has been kept today in order to allow backward compatibility in future. + +struct __sc_riscv_cfi_state { + unsigned long ss_ptr; + unsigned long rsvd; +}; + +As part of signal delivery, shadow stack token is saved on current shadow stack itself and +updated pointer is saved away in `ss_ptr` field in `__sc_riscv_cfi_state` under `sigcontext` +Existing shadow stack allocation is used for signal delivery. During `sigreturn`, kernel will +obtain `ss_ptr` from `sigcontext` and verify the saved token on shadow stack itself and switch +shadow stack.
Adding documentation on shadow stack for user mode on riscv and kernel interfaces exposed so that user tasks can enable it. Signed-off-by: Deepak Gupta <debug@rivosinc.com> --- Documentation/arch/riscv/zicfiss.rst | 169 +++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 Documentation/arch/riscv/zicfiss.rst