Message-ID: <ZuekDuJS66-YGg5L@archie.me>
Date: Mon, 16 Sep 2024 10:20:46 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Deepak Gupta <debug@...osinc.com>, paul.walmsley@...ive.com,
	palmer@...ive.com, conor@...nel.org, linux-doc@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, linux-arch@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Cc: corbet@....net, palmer@...belt.com, aou@...s.berkeley.edu,
	robh@...nel.org, krzk+dt@...nel.org, oleg@...hat.com,
	tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
	peterz@...radead.org, akpm@...ux-foundation.org, arnd@...db.de,
	ebiederm@...ssion.com, kees@...nel.org, Liam.Howlett@...cle.com,
	vbabka@...e.cz, lorenzo.stoakes@...cle.com, shuah@...nel.org,
	brauner@...nel.org, samuel.holland@...ive.com, andy.chiu@...ive.com,
	jerry.shih@...ive.com, greentime.hu@...ive.com,
	charlie@...osinc.com, evan@...osinc.com, cleger@...osinc.com,
	xiao.w.wang@...el.com, ajones@...tanamicro.com, anup@...infault.org,
	mchitale@...tanamicro.com, atishp@...osinc.com, sameo@...osinc.com,
	bjorn@...osinc.com, alexghiti@...osinc.com, david@...hat.com,
	libang.li@...group.com, jszhang@...nel.org, leobras@...hat.com,
	guoren@...nel.org, samitolvanen@...gle.com,
	songshuaishuai@...ylab.org, costa.shul@...hat.com, bhe@...hat.com,
	zong.li@...ive.com, puranjay@...nel.org, namcaov@...il.com,
	antonb@...storrent.com, sorear@...tmail.com,
	quic_bjorande@...cinc.com, ancientmodern4@...il.com,
	ben.dooks@...ethink.co.uk, quic_zhonhan@...cinc.com,
	cuiyunhui@...edance.com, yang.lee@...ux.alibaba.com,
	ke.zhao@...ngroup.cn, sunilvl@...tanamicro.com,
	tanzhasanwork@...il.com, schwab@...e.de, dawei.li@...ngroup.cn,
	rppt@...nel.org, willy@...radead.org, usama.anjum@...labora.com,
	osalvador@...e.de, ryan.roberts@....com, andrii@...nel.org,
	alx@...nel.org, catalin.marinas@....com, broonie@...nel.org,
	revest@...omium.org, bgray@...ux.ibm.com, deller@....de,
	zev@...ilderbeest.net
Subject: Re: [PATCH v4 29/30] riscv: Documentation for shadow stack on riscv

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@...osinc.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.

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists