From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "masahiroy@kernel.org" <masahiroy@kernel.org>,
"rppt@kernel.org" <rppt@kernel.org>,
"lorenzo.stoakes@oracle.com" <lorenzo.stoakes@oracle.com>,
"justinstitt@google.com" <justinstitt@google.com>,
"nick.desaulniers+lkml@gmail.com"
<nick.desaulniers+lkml@gmail.com>,
"david@redhat.com" <david@redhat.com>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"morbo@google.com" <morbo@google.com>,
"palmer@dabbelt.com" <palmer@dabbelt.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"nicolas.schier@linux.dev" <nicolas.schier@linux.dev>,
"surenb@google.com" <surenb@google.com>,
"monk.chiang@sifive.com" <monk.chiang@sifive.com>,
"nathan@kernel.org" <nathan@kernel.org>,
"kito.cheng@sifive.com" <kito.cheng@sifive.com>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
"mhocko@suse.com" <mhocko@suse.com>,
"alex@ghiti.fr" <alex@ghiti.fr>
Cc: "andrew@sifive.com" <andrew@sifive.com>,
"samitolvanen@google.com" <samitolvanen@google.com>,
"cleger@rivosinc.com" <cleger@rivosinc.com>,
"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"bjorn@rivosinc.com" <bjorn@rivosinc.com>,
"fweimer@redhat.com" <fweimer@redhat.com>,
"heinrich.schuchardt@canonical.com"
<heinrich.schuchardt@canonical.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"conor.dooley@microchip.com" <conor.dooley@microchip.com>,
"ved@rivosinc.com" <ved@rivosinc.com>,
"samuel.holland@sifive.com" <samuel.holland@sifive.com>,
"charlie@rivosinc.com" <charlie@rivosinc.com>,
"jeffreyalaw@gmail.com" <jeffreyalaw@gmail.com>,
"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
"ajones@ventanamicro.com" <ajones@ventanamicro.com>,
"apatel@ventanamicro.com" <apatel@ventanamicro.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH 10/11] scs: generic scs code updated to leverage hw assisted shadow stack
Date: Fri, 25 Jul 2025 17:06:17 +0000 [thread overview]
Message-ID: <3d579a8c2558391ff6e33e7b45527a83aa67c7f5.camel@intel.com> (raw)
In-Reply-To: <20250724-riscv_kcfi-v1-10-04b8fa44c98c@rivosinc.com>
On Thu, 2025-07-24 at 16:37 -0700, Deepak Gupta wrote:
> If shadow stack have memory protections from underlying cpu, use those
> protections. arches can define PAGE_KERNEL_SHADOWSTACK to vmalloc such shadow
> stack pages. Hw assisted shadow stack pages grow downwards like regular
> stack. Clang based software shadow call stack grows low to high address.
> Thus this patch addresses some of those needs due to opposite direction
> of shadow stack. Furthermore, hw shadow stack can't be memset because memset
> uses normal stores. Lastly to store magic word at base of shadow stack, arch
> specific shadow stack store has to be performed.
>
> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> ---
> include/linux/scs.h | 26 +++++++++++++++++++++++++-
> kernel/scs.c | 38 +++++++++++++++++++++++++++++++++++---
> 2 files changed, 60 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/scs.h b/include/linux/scs.h
> index 4ab5bdc898cf..6ceee07c2d1a 100644
> --- a/include/linux/scs.h
> +++ b/include/linux/scs.h
> @@ -12,6 +12,7 @@
> #include <linux/poison.h>
> #include <linux/sched.h>
> #include <linux/sizes.h>
> +#include <asm/scs.h>
>
> #ifdef CONFIG_SHADOW_CALL_STACK
>
> @@ -37,22 +38,45 @@ static inline void scs_task_reset(struct task_struct *tsk)
> * Reset the shadow stack to the base address in case the task
> * is reused.
> */
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + task_scs_sp(tsk) = task_scs(tsk) + SCS_SIZE;
> +#else
> task_scs_sp(tsk) = task_scs(tsk);
> +#endif
> }
>
> static inline unsigned long *__scs_magic(void *s)
> {
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + return (unsigned long *)(s);
> +#else
> return (unsigned long *)(s + SCS_SIZE) - 1;
> +#endif
> }
>
> static inline bool task_scs_end_corrupted(struct task_struct *tsk)
> {
> unsigned long *magic = __scs_magic(task_scs(tsk));
> - unsigned long sz = task_scs_sp(tsk) - task_scs(tsk);
> + unsigned long sz;
> +
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + sz = (task_scs(tsk) + SCS_SIZE) - task_scs_sp(tsk);
> +#else
> + sz = task_scs_sp(tsk) - task_scs(tsk);
> +#endif
>
> return sz >= SCS_SIZE - 1 || READ_ONCE_NOCHECK(*magic) != SCS_END_MAGIC;
> }
>
> +static inline void __scs_store_magic(unsigned long *s, unsigned long magic_val)
> +{
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + arch_scs_store(s, magic_val);
> +#else
> + *__scs_magic(s) = magic_val;
> +#endif
> +}
> +
> DECLARE_STATIC_KEY_FALSE(dynamic_scs_enabled);
>
> static inline bool scs_is_dynamic(void)
> diff --git a/kernel/scs.c b/kernel/scs.c
> index d7809affe740..5910c0a8eabd 100644
> --- a/kernel/scs.c
> +++ b/kernel/scs.c
> @@ -11,6 +11,7 @@
> #include <linux/scs.h>
> #include <linux/vmalloc.h>
> #include <linux/vmstat.h>
> +#include <asm-generic/set_memory.h>
>
> #ifdef CONFIG_DYNAMIC_SCS
> DEFINE_STATIC_KEY_FALSE(dynamic_scs_enabled);
> @@ -32,19 +33,31 @@ static void *__scs_alloc(int node)
> {
> int i;
> void *s;
> + pgprot_t prot = PAGE_KERNEL;
> +
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + prot = PAGE_KERNEL_SHADOWSTACK;
> +#endif
>
> for (i = 0; i < NR_CACHED_SCS; i++) {
> s = this_cpu_xchg(scs_cache[i], NULL);
> if (s) {
> s = kasan_unpoison_vmalloc(s, SCS_SIZE,
> KASAN_VMALLOC_PROT_NORMAL);
> +/*
> + * If software shadow stack, its safe to memset. Else memset is not
> + * possible on hw protected shadow stack. memset constitutes stores and
> + * stores to shadow stack memory are disallowed and will fault.
> + */
> +#ifndef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> memset(s, 0, SCS_SIZE);
> +#endif
> goto out;
> }
> }
>
> s = __vmalloc_node_range(SCS_SIZE, 1, VMALLOC_START, VMALLOC_END,
> - GFP_SCS, PAGE_KERNEL, 0, node,
> + GFP_SCS, prot, 0, node,
> __builtin_return_address(0));
This doesn't update the direct map alias I think. Do you want to protect it?
>
> out:
> @@ -59,7 +72,7 @@ void *scs_alloc(int node)
> if (!s)
> return NULL;
>
> - *__scs_magic(s) = SCS_END_MAGIC;
> + __scs_store_magic(__scs_magic(s), SCS_END_MAGIC);
>
> /*
> * Poison the allocation to catch unintentional accesses to
> @@ -87,6 +100,16 @@ void scs_free(void *s)
> return;
>
> kasan_unpoison_vmalloc(s, SCS_SIZE, KASAN_VMALLOC_PROT_NORMAL);
> + /*
> + * Hardware protected shadow stack is not writeable by regular stores
> + * Thus adding this back to free list will raise faults by vmalloc
> + * It needs to be writeable again. It's good sanity as well because
> + * then it can't be inadvertently accesses and if done, it will fault.
> + */
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + set_memory_rw((unsigned long)s, (SCS_SIZE/PAGE_SIZE));
Above you don't update the direct map permissions. So I don't think you need
this. vmalloc should flush the permissioned mapping before re-using it with the
lazy cleanup scheme.
> +#endif
> +
I was thinking someday when we get to this for CET we would protect the direct
map, and so would need some pool of shadow stacks because flushing the TLB for
every thread alloc/free would likely be too impactful.
> vfree_atomic(s);
> }
>
> @@ -96,6 +119,9 @@ static int scs_cleanup(unsigned int cpu)
> void **cache = per_cpu_ptr(scs_cache, cpu);
>
> for (i = 0; i < NR_CACHED_SCS; i++) {
Oh! There is a cache, but the size is only 2.
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + set_memory_rw((unsigned long)cache[i], (SCS_SIZE/PAGE_SIZE));
> +#endif
> vfree(cache[i]);
> cache[i] = NULL;
> }
> @@ -122,7 +148,13 @@ int scs_prepare(struct task_struct *tsk, int node)
> if (!s)
> return -ENOMEM;
>
> - task_scs(tsk) = task_scs_sp(tsk) = s;
> + task_scs(tsk) = s;
> +#ifdef CONFIG_ARCH_HAS_KERNEL_SHADOW_STACK
> + task_scs_sp(tsk) = s + SCS_SIZE;
> +#else
> + task_scs_sp(tsk) = s;
> +#endif
> +
> return 0;
> }
>
>
next prev parent reply other threads:[~2025-07-25 17:07 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-24 23:36 [PATCH 00/11] riscv: fine grained hardware assisted kernel control-flow integrity Deepak Gupta
2025-07-24 23:36 ` [PATCH 01/11] riscv: add landing pad for asm routines Deepak Gupta
2025-07-25 6:13 ` Heinrich Schuchardt
2025-07-25 14:10 ` Deepak Gupta
2025-07-25 15:27 ` Sami Tolvanen
2025-07-25 17:01 ` Deepak Gupta
2025-07-24 23:36 ` [PATCH 02/11] riscv: update asm call site in `call_on_irq_stack` to setup correct label Deepak Gupta
2025-07-25 6:23 ` Heinrich Schuchardt
2025-07-25 14:16 ` Deepak Gupta
2025-07-25 15:33 ` Sami Tolvanen
2025-07-25 16:56 ` Deepak Gupta
2025-07-24 23:36 ` [PATCH 03/11] riscv: indirect jmp in asm that's static in nature to use sw guarded jump Deepak Gupta
2025-07-25 6:26 ` Heinrich Schuchardt
2025-07-24 23:36 ` [PATCH 04/11] riscv: exception handlers can be software guarded transfers Deepak Gupta
2025-07-24 23:36 ` [PATCH 05/11] riscv: enable landing pad enforcement Deepak Gupta
2025-07-25 6:33 ` Heinrich Schuchardt
2025-07-25 14:20 ` Deepak Gupta
2025-07-25 14:43 ` Heinrich Schuchardt
2025-07-24 23:36 ` [PATCH 06/11] mm: Introduce ARCH_HAS_KERNEL_SHADOW_STACK Deepak Gupta
2025-07-26 7:42 ` Mike Rapoport
2025-07-29 0:36 ` Deepak Gupta
2025-07-24 23:37 ` [PATCH 07/11] scs: place init shadow stack in .shadowstack section Deepak Gupta
2025-07-24 23:37 ` [PATCH 08/11] riscv/mm: prepare shadow stack for init task Deepak Gupta
2025-07-24 23:37 ` [PATCH 09/11] riscv: scs: add hardware shadow stack support to scs Deepak Gupta
2025-07-24 23:37 ` [PATCH 10/11] scs: generic scs code updated to leverage hw assisted shadow stack Deepak Gupta
2025-07-25 16:13 ` Sami Tolvanen
2025-07-25 16:42 ` Deepak Gupta
2025-07-25 16:47 ` Deepak Gupta
2025-07-25 16:46 ` Mark Brown
2025-07-28 12:47 ` Will Deacon
2025-07-28 16:37 ` Deepak Gupta
2025-07-25 17:06 ` Edgecombe, Rick P [this message]
2025-07-25 17:19 ` Deepak Gupta
2025-07-25 18:05 ` Edgecombe, Rick P
2025-07-28 19:23 ` Deepak Gupta
2025-07-28 21:19 ` Deepak Gupta
2025-07-24 23:37 ` [PATCH 11/11] riscv: Kconfig & Makefile for riscv kernel control flow integrity Deepak Gupta
2025-07-25 11:26 ` Heinrich Schuchardt
2025-07-25 14:23 ` Deepak Gupta
2025-07-25 14:39 ` Heinrich Schuchardt
2025-07-24 23:38 ` [PATCH 00/11] riscv: fine grained hardware assisted kernel control-flow integrity Deepak Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d579a8c2558391ff6e33e7b45527a83aa67c7f5.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=ajones@ventanamicro.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=andrew@sifive.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=bjorn@rivosinc.com \
--cc=broonie@kernel.org \
--cc=charlie@rivosinc.com \
--cc=cleger@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=david@redhat.com \
--cc=debug@rivosinc.com \
--cc=fweimer@redhat.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=jeffreyalaw@gmail.com \
--cc=justinstitt@google.com \
--cc=kito.cheng@sifive.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=lorenzo.stoakes@oracle.com \
--cc=masahiroy@kernel.org \
--cc=mhocko@suse.com \
--cc=monk.chiang@sifive.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nicolas.schier@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rppt@kernel.org \
--cc=samitolvanen@google.com \
--cc=samuel.holland@sifive.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=ved@rivosinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).