From: Deepak Gupta <debug@rivosinc.com>
To: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Monk Chiang <monk.chiang@sifive.com>,
Kito Cheng <kito.cheng@sifive.com>,
Justin Stitt <justinstitt@google.com>
Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org, linux-mm@kvack.org,
llvm@lists.linux.dev, rick.p.edgecombe@intel.com,
broonie@kernel.org, cleger@rivosinc.com,
samitolvanen@google.com, apatel@ventanamicro.com,
ajones@ventanamicro.com, conor.dooley@microchip.com,
charlie@rivosinc.com, samuel.holland@sifive.com,
bjorn@rivosinc.com, fweimer@redhat.com, jeffreyalaw@gmail.com,
heinrich.schuchardt@canonical.com, andrew@sifive.com,
ved@rivosinc.com, Deepak Gupta <debug@rivosinc.com>
Subject: [PATCH 10/11] scs: generic scs code updated to leverage hw assisted shadow stack
Date: Thu, 24 Jul 2025 16:37:03 -0700 [thread overview]
Message-ID: <20250724-riscv_kcfi-v1-10-04b8fa44c98c@rivosinc.com> (raw)
In-Reply-To: <20250724-riscv_kcfi-v1-0-04b8fa44c98c@rivosinc.com>
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));
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));
+#endif
+
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++) {
+#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;
}
--
2.43.0
next prev parent reply other threads:[~2025-07-24 23:37 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 ` Deepak Gupta [this message]
2025-07-25 16:13 ` [PATCH 10/11] scs: generic scs code updated to leverage hw assisted shadow stack 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
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=20250724-riscv_kcfi-v1-10-04b8fa44c98c@rivosinc.com \
--to=debug@rivosinc.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=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=rick.p.edgecombe@intel.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