[PATCH RFC RFT v2 0/5] fork: Support shadow stacks in clone3()

[PATCH RFC RFT v2 0/5] fork: Support shadow stacks in clone3()

[Mark Brown]

The kernel has recently added support for shadow stacks, currently
x86 only using their CET feature but both arm64 and RISC-V have
equivalent features (GCS and Zisslpcfi respectively), I am actively
working on GCS[1].  With shadow stacks the hardware maintains an
additional stack containing only the return addresses for branch
instructions which is not generally writeable by userspace and ensures
that any returns are to the recorded addresses.  This provides some
protection against ROP attacks and making it easier to collect call
stacks.  These shadow stacks are allocated in the address space of the
userspace process.

Our API for shadow stacks does not currently offer userspace any
flexiblity for managing the allocation of shadow stacks for newly
created threads, instead the kernel allocates a new shadow stack with
the same size as the normal stack whenever a thread is created with the
feature enabled.  The stacks allocated in this way are freed by the
kernel when the thread exits or shadow stacks are disabled for the
thread.  This lack of flexibility and control isn't ideal, in the vast
majority of cases the shadow stack will be over allocated and the
implicit allocation and deallocation is not consistent with other
interfaces.  As far as I can tell the interface is done in this manner
mainly because the shadow stack patches were in development since before
clone3() was implemented.

Since clone3() is readily extensible let's add support for specifying a
shadow stack when creating a new thread or process in a similar manner
to how the normal stack is specified, keeping the current implicit
allocation behaviour if one is not specified either with clone3() or
through the use of clone().  Unlike normal stacks only the shadow stack
size is specified, similar issues to those that lead to the creation of
map_shadow_stack() apply.

Please note that the x86 portions of this code are build tested only, I
don't appear to have a system that can run CET avaible to me, I have
done testing with an integration into my pending work for GCS.  There is
some possibility that the arm64 implementation may require the use of
clone3() and explicit userspace allocation of shadow stacks, this is
still under discussion.

A new architecture feature Kconfig option for shadow stacks is added as
here, this was suggested as part of the review comments for the arm64
GCS series and since we need to detect if shadow stacks are supported it
seemed sensible to roll it in here.

[1] https://lore.kernel.org/r/20231009-arm64-gcs-v6-0-78e55deaa4dd@kernel.org/

Signed-off-by: Mark Brown <broonie@kernel.org>
---
Changes in v2:
- Rebase onto v6.7-rc1.
- Remove ability to provide preallocated shadow stack, just specify the
  desired size.
- Link to v1: https://lore.kernel.org/r/20231023-clone3-shadow-stack-v1-0-d867d0b5d4d0@kernel.org

---
Mark Brown (5):
      mm: Introduce ARCH_HAS_USER_SHADOW_STACK
      fork: Add shadow stack support to clone3()
      selftests/clone3: Factor more of main loop into test_clone3()
      selftests/clone3: Allow tests to flag if -E2BIG is a valid error code
      kselftest/clone3: Test shadow stack support

 arch/x86/Kconfig                                  |   1 +
 arch/x86/include/asm/shstk.h                      |  11 +-
 arch/x86/kernel/process.c                         |   2 +-
 arch/x86/kernel/shstk.c                           |  30 ++++-
 fs/proc/task_mmu.c                                |   2 +-
 include/linux/mm.h                                |   2 +-
 include/linux/sched/task.h                        |   2 +
 include/uapi/linux/sched.h                        |   4 +
 kernel/fork.c                                     |  24 +++-
 mm/Kconfig                                        |   6 +
 tools/testing/selftests/clone3/clone3.c           | 151 ++++++++++++++++------
 tools/testing/selftests/clone3/clone3_selftests.h |   7 +
 12 files changed, 188 insertions(+), 54 deletions(-)
---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20231019-clone3-shadow-stack-15d40d2bf536

Best regards,
-- 
Mark Brown <broonie@kernel.org>

[PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK

[Mark Brown]

Since multiple architectures have support for shadow stacks and we need to
select support for this feature in several places in the generic code
provide a generic config option that the architectures can select.

Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/x86/Kconfig   | 1 +
 fs/proc/task_mmu.c | 2 +-
 include/linux/mm.h | 2 +-
 mm/Kconfig         | 6 ++++++
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3762f41bb092..14b7703a9a2b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1952,6 +1952,7 @@ config X86_USER_SHADOW_STACK
 	depends on AS_WRUSS
 	depends on X86_64
 	select ARCH_USES_HIGH_VMA_FLAGS
+	select ARCH_HAS_USER_SHADOW_STACK
 	select X86_CET
 	help
 	  Shadow stack protection is a hardware feature that detects function
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ef2eb12906da..f0a904aeee8e 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -699,7 +699,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
 #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
 		[ilog2(VM_UFFD_MINOR)]	= "ui",
 #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
-#ifdef CONFIG_X86_USER_SHADOW_STACK
+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
 		[ilog2(VM_SHADOW_STACK)] = "ss",
 #endif
 	};
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 418d26608ece..10462f354614 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -341,7 +341,7 @@ extern unsigned int kobjsize(const void *objp);
 #endif
 #endif /* CONFIG_ARCH_HAS_PKEYS */
 
-#ifdef CONFIG_X86_USER_SHADOW_STACK
+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
 /*
  * VM_SHADOW_STACK should not be set with VM_SHARED because of lack of
  * support core mm.
diff --git a/mm/Kconfig b/mm/Kconfig
index 89971a894b60..b8638da636e1 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1270,6 +1270,12 @@ config LOCK_MM_AND_FIND_VMA
 	bool
 	depends on !STACK_GROWSUP
 
+config ARCH_HAS_USER_SHADOW_STACK
+	bool
+	help
+	  The architecture has hardware support for userspace shadow call
+          stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi).
+
 source "mm/damon/Kconfig"
 
 endmenu

-- 
2.30.2

[PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

Unlike with the normal stack there is no API for configuring the the shadow
stack for a new thread, instead the kernel will dynamically allocate a new
shadow stack with the same size as the normal stack. This appears to be due
to the shadow stack series having been in development since before the more
extensible clone3() was added rather than anything more deliberate.

Add parameters to clone3() specifying the address and size of a shadow
stack for the newly created process, we validate that the range specified
is accessible to userspace but do not validate that it has been mapped
appropriately for use as a shadow stack (normally via map_shadow_stack()).
If the shadow stack is specified in this way then the caller is responsible
for freeing the memory as with the main stack. If no shadow stack is
specified then the existing implicit allocation and freeing behaviour is
maintained.

If the architecture does not support shadow stacks the shadow stack
parameters must be zero, architectures that do support the feature are
expected to have the same requirement on individual systems that lack
shadow stack support.

Update the existing x86 implementation to pay attention to the newly added
arguments, in order to maintain compatibility we use the existing behaviour
if no shadow stack is specified. Minimal validation is done of the supplied
parameters, detailed enforcement is left to when the thread is executed.
Since we are now using four fields from the kernel_clone_args we pass that
into the shadow stack code rather than individual fields.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/x86/include/asm/shstk.h | 11 +++++++----
 arch/x86/kernel/process.c    |  2 +-
 arch/x86/kernel/shstk.c      | 30 +++++++++++++++++++++++++-----
 include/linux/sched/task.h   |  2 ++
 include/uapi/linux/sched.h   |  4 ++++
 kernel/fork.c                | 24 ++++++++++++++++++++++--
 6 files changed, 61 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/shstk.h b/arch/x86/include/asm/shstk.h
index 42fee8959df7..8be7b0a909c3 100644
--- a/arch/x86/include/asm/shstk.h
+++ b/arch/x86/include/asm/shstk.h
@@ -6,6 +6,7 @@
 #include <linux/types.h>
 
 struct task_struct;
+struct kernel_clone_args;
 struct ksignal;
 
 #ifdef CONFIG_X86_USER_SHADOW_STACK
@@ -16,8 +17,8 @@ struct thread_shstk {
 
 long shstk_prctl(struct task_struct *task, int option, unsigned long arg2);
 void reset_thread_features(void);
-unsigned long shstk_alloc_thread_stack(struct task_struct *p, unsigned long clone_flags,
-				       unsigned long stack_size);
+unsigned long shstk_alloc_thread_stack(struct task_struct *p,
+				       const struct kernel_clone_args *args);
 void shstk_free(struct task_struct *p);
 int setup_signal_shadow_stack(struct ksignal *ksig);
 int restore_signal_shadow_stack(void);
@@ -26,8 +27,10 @@ static inline long shstk_prctl(struct task_struct *task, int option,
 			       unsigned long arg2) { return -EINVAL; }
 static inline void reset_thread_features(void) {}
 static inline unsigned long shstk_alloc_thread_stack(struct task_struct *p,
-						     unsigned long clone_flags,
-						     unsigned long stack_size) { return 0; }
+						     const struct kernel_clone_args *args)
+{
+	return 0;
+}
 static inline void shstk_free(struct task_struct *p) {}
 static inline int setup_signal_shadow_stack(struct ksignal *ksig) { return 0; }
 static inline int restore_signal_shadow_stack(void) { return 0; }
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index b6f4e8399fca..a9ca80ea5056 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -207,7 +207,7 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
 	 * is disabled, new_ssp will remain 0, and fpu_clone() will know not to
 	 * update it.
 	 */
-	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->stack_size);
+	new_ssp = shstk_alloc_thread_stack(p, args);
 	if (IS_ERR_VALUE(new_ssp))
 		return PTR_ERR((void *)new_ssp);
 
diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
index 59e15dd8d0f8..7ffe90010587 100644
--- a/arch/x86/kernel/shstk.c
+++ b/arch/x86/kernel/shstk.c
@@ -191,18 +191,38 @@ void reset_thread_features(void)
 	current->thread.features_locked = 0;
 }
 
-unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long clone_flags,
-				       unsigned long stack_size)
+unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
+				       const struct kernel_clone_args *args)
 {
 	struct thread_shstk *shstk = &tsk->thread.shstk;
+	unsigned long clone_flags = args->flags;
 	unsigned long addr, size;
 
 	/*
 	 * If shadow stack is not enabled on the new thread, skip any
-	 * switch to a new shadow stack.
+	 * implicit switch to a new shadow stack and reject attempts to
+	 * explciitly specify one.
 	 */
-	if (!features_enabled(ARCH_SHSTK_SHSTK))
+	if (!features_enabled(ARCH_SHSTK_SHSTK)) {
+		if (args->shadow_stack)
+			return (unsigned long)ERR_PTR(-EINVAL);
+
 		return 0;
+	}
+
+	/*
+	 * If the user specified a shadow stack then do some basic
+	 * validation and use it.  The caller is responsible for
+	 * freeing the shadow stack.
+	 */
+	if (args->shadow_stack_size) {
+		size = args->shadow_stack_size;
+
+		if (size < 8)
+			return (unsigned long)ERR_PTR(-EINVAL);
+	} else {
+		size = args->stack_size;
+	}
 
 	/*
 	 * For CLONE_VFORK the child will share the parents shadow stack.
@@ -222,7 +242,7 @@ unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long cl
 	if (!(clone_flags & CLONE_VM))
 		return 0;
 
-	size = adjust_shstk_size(stack_size);
+	size = adjust_shstk_size(size);
 	addr = alloc_shstk(0, size, 0, false);
 	if (IS_ERR_VALUE(addr))
 		return addr;
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index a23af225c898..94e7cf62be51 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -41,6 +41,8 @@ struct kernel_clone_args {
 	void *fn_arg;
 	struct cgroup *cgrp;
 	struct css_set *cset;
+	unsigned long shadow_stack;
+	unsigned long shadow_stack_size;
 };
 
 /*
diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
index 3bac0a8ceab2..a998b6d0c897 100644
--- a/include/uapi/linux/sched.h
+++ b/include/uapi/linux/sched.h
@@ -84,6 +84,8 @@
  *                kernel's limit of nested PID namespaces.
  * @cgroup:       If CLONE_INTO_CGROUP is specified set this to
  *                a file descriptor for the cgroup.
+ * @shadow_stack_size: Specify the size of the shadow stack to allocate
+ *                     for the child process.
  *
  * The structure is versioned by size and thus extensible.
  * New struct members must go at the end of the struct and
@@ -101,12 +103,14 @@ struct clone_args {
 	__aligned_u64 set_tid;
 	__aligned_u64 set_tid_size;
 	__aligned_u64 cgroup;
+	__aligned_u64 shadow_stack_size;
 };
 #endif
 
 #define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
 #define CLONE_ARGS_SIZE_VER1 80 /* sizeof second published struct */
 #define CLONE_ARGS_SIZE_VER2 88 /* sizeof third published struct */
+#define CLONE_ARGS_SIZE_VER3 96 /* sizeof fourth published struct */
 
 /*
  * Scheduling policies
diff --git a/kernel/fork.c b/kernel/fork.c
index 10917c3e1f03..b0df69c8185e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -3067,7 +3067,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
 		     CLONE_ARGS_SIZE_VER1);
 	BUILD_BUG_ON(offsetofend(struct clone_args, cgroup) !=
 		     CLONE_ARGS_SIZE_VER2);
-	BUILD_BUG_ON(sizeof(struct clone_args) != CLONE_ARGS_SIZE_VER2);
+	BUILD_BUG_ON(offsetofend(struct clone_args, shadow_stack_size) !=
+		     CLONE_ARGS_SIZE_VER3);
+	BUILD_BUG_ON(sizeof(struct clone_args) != CLONE_ARGS_SIZE_VER3);
 
 	if (unlikely(usize > PAGE_SIZE))
 		return -E2BIG;
@@ -3110,6 +3112,7 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
 		.tls		= args.tls,
 		.set_tid_size	= args.set_tid_size,
 		.cgroup		= args.cgroup,
+		.shadow_stack_size	= args.shadow_stack_size,
 	};
 
 	if (args.set_tid &&
@@ -3150,6 +3153,23 @@ static inline bool clone3_stack_valid(struct kernel_clone_args *kargs)
 	return true;
 }
 
+/**
+ * clone3_shadow_stack_valid - check and prepare shadow stack
+ * @kargs: kernel clone args
+ *
+ * Verify that shadow stacks are only enabled if supported.
+ */
+static inline bool clone3_shadow_stack_valid(struct kernel_clone_args *kargs)
+{
+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
+	/* The architecture must check support on the specific machine */
+	return true;
+#else
+	/* The architecture does not support shadow stacks */
+	return !kargs->shadow_stack_size;
+#endif
+}
+
 static bool clone3_args_valid(struct kernel_clone_args *kargs)
 {
 	/* Verify that no unknown flags are passed along. */
@@ -3172,7 +3192,7 @@ static bool clone3_args_valid(struct kernel_clone_args *kargs)
 	    kargs->exit_signal)
 		return false;
 
-	if (!clone3_stack_valid(kargs))
+	if (!clone3_stack_valid(kargs) || !clone3_shadow_stack_valid(kargs))
 		return false;
 
 	return true;

-- 
2.30.2

[PATCH RFC RFT v2 3/5] selftests/clone3: Factor more of main loop into test_clone3()

[Mark Brown]

In order to make it easier to add more configuration for the tests and
more support for runtime detection of when tests can be run pass the
structure describing the tests into test_clone3() rather than picking
the arguments out of it and have that function do all the per-test work.

No functional change.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 tools/testing/selftests/clone3/clone3.c | 77 ++++++++++++++++-----------------
 1 file changed, 37 insertions(+), 40 deletions(-)

diff --git a/tools/testing/selftests/clone3/clone3.c b/tools/testing/selftests/clone3/clone3.c
index 3c9bf0cd82a8..1108bd8e36d6 100644
--- a/tools/testing/selftests/clone3/clone3.c
+++ b/tools/testing/selftests/clone3/clone3.c
@@ -30,6 +30,19 @@ enum test_mode {
 	CLONE3_ARGS_INVAL_EXIT_SIGNAL_NSIG,
 };
 
+typedef bool (*filter_function)(void);
+typedef size_t (*size_function)(void);
+
+struct test {
+	const char *name;
+	uint64_t flags;
+	size_t size;
+	size_function size_function;
+	int expected;
+	enum test_mode test_mode;
+	filter_function filter;
+};
+
 static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
 {
 	struct __clone_args args = {
@@ -104,30 +117,40 @@ static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
 	return 0;
 }
 
-static bool test_clone3(uint64_t flags, size_t size, int expected,
-			enum test_mode test_mode)
+static void test_clone3(const struct test *test)
 {
+	size_t size;
 	int ret;
 
+	if (test->filter && test->filter()) {
+		ksft_test_result_skip("%s\n", test->name);
+		return;
+	}
+
+	if (test->size_function)
+		size = test->size_function();
+	else
+		size = test->size;
+
+	ksft_print_msg("Running test '%s'\n", test->name);
+
 	ksft_print_msg(
 		"[%d] Trying clone3() with flags %#" PRIx64 " (size %zu)\n",
-		getpid(), flags, size);
-	ret = call_clone3(flags, size, test_mode);
+		getpid(), test->flags, size);
+	ret = call_clone3(test->flags, size, test->test_mode);
 	ksft_print_msg("[%d] clone3() with flags says: %d expected %d\n",
-			getpid(), ret, expected);
-	if (ret != expected) {
+			getpid(), ret, test->expected);
+	if (ret != test->expected) {
 		ksft_print_msg(
 			"[%d] Result (%d) is different than expected (%d)\n",
-			getpid(), ret, expected);
-		return false;
+			getpid(), ret, test->expected);
+		ksft_test_result_fail("%s\n", test->name);
+		return;
 	}
 
-	return true;
+	ksft_test_result_pass("%s\n", test->name);
 }
 
-typedef bool (*filter_function)(void);
-typedef size_t (*size_function)(void);
-
 static bool not_root(void)
 {
 	if (getuid() != 0) {
@@ -155,16 +178,6 @@ static size_t page_size_plus_8(void)
 	return getpagesize() + 8;
 }
 
-struct test {
-	const char *name;
-	uint64_t flags;
-	size_t size;
-	size_function size_function;
-	int expected;
-	enum test_mode test_mode;
-	filter_function filter;
-};
-
 static const struct test tests[] = {
 	{
 		.name = "simple clone3()",
@@ -314,24 +327,8 @@ int main(int argc, char *argv[])
 	ksft_set_plan(ARRAY_SIZE(tests));
 	test_clone3_supported();
 
-	for (i = 0; i < ARRAY_SIZE(tests); i++) {
-		if (tests[i].filter && tests[i].filter()) {
-			ksft_test_result_skip("%s\n", tests[i].name);
-			continue;
-		}
-
-		if (tests[i].size_function)
-			size = tests[i].size_function();
-		else
-			size = tests[i].size;
-
-		ksft_print_msg("Running test '%s'\n", tests[i].name);
-
-		ksft_test_result(test_clone3(tests[i].flags, size,
-					     tests[i].expected,
-					     tests[i].test_mode),
-				 "%s\n", tests[i].name);
-	}
+	for (i = 0; i < ARRAY_SIZE(tests); i++)
+		test_clone3(&tests[i]);
 
 	ksft_finished();
 }

-- 
2.30.2

[PATCH RFC RFT v2 4/5] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code

[Mark Brown]

The clone_args structure is extensible, with the syscall passing in the
length of the structure. Inside the kernel we use copy_struct_from_user()
to read the struct but this has the unfortunate side effect of silently
accepting some overrun in the structure size providing the extra data is
all zeros. This means that we can't discover the clone3() features that
the running kernel supports by simply probing with various struct sizes.
We need to check this for the benefit of test systems which run newer
kselftests on old kernels.

Add a flag which can be set on a test to indicate that clone3() may return
-E2BIG due to the use of newer struct versions. Currently no tests need
this but it will become an issue for testing clone3() support for shadow
stacks, the support for shadow stacks is already present on x86.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 tools/testing/selftests/clone3/clone3.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/clone3/clone3.c b/tools/testing/selftests/clone3/clone3.c
index 1108bd8e36d6..6adbfd14c841 100644
--- a/tools/testing/selftests/clone3/clone3.c
+++ b/tools/testing/selftests/clone3/clone3.c
@@ -39,6 +39,7 @@ struct test {
 	size_t size;
 	size_function size_function;
 	int expected;
+	bool e2big_valid;
 	enum test_mode test_mode;
 	filter_function filter;
 };
@@ -141,6 +142,11 @@ static void test_clone3(const struct test *test)
 	ksft_print_msg("[%d] clone3() with flags says: %d expected %d\n",
 			getpid(), ret, test->expected);
 	if (ret != test->expected) {
+		if (test->e2big_valid && ret == -E2BIG) {
+			ksft_print_msg("Test reported -E2BIG\n");
+			ksft_test_result_skip("%s\n", test->name);
+			return;
+		}
 		ksft_print_msg(
 			"[%d] Result (%d) is different than expected (%d)\n",
 			getpid(), ret, test->expected);

-- 
2.30.2

[PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

[Mark Brown]

Add basic test coverage for specifying the shadow stack for a newly
created thread via clone3(), including coverage of the newly extended
argument structure. We detect support for shadow stacks on the running
system by attempting to allocate a shadow stack page during initialisation
using map_shadow_stack().

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 tools/testing/selftests/clone3/clone3.c           | 68 +++++++++++++++++++++++
 tools/testing/selftests/clone3/clone3_selftests.h |  7 +++
 2 files changed, 75 insertions(+)

diff --git a/tools/testing/selftests/clone3/clone3.c b/tools/testing/selftests/clone3/clone3.c
index 6adbfd14c841..10e0487c402a 100644
--- a/tools/testing/selftests/clone3/clone3.c
+++ b/tools/testing/selftests/clone3/clone3.c
@@ -11,6 +11,7 @@
 #include <stdint.h>
 #include <stdio.h>
 #include <stdlib.h>
+#include <sys/mman.h>
 #include <sys/syscall.h>
 #include <sys/types.h>
 #include <sys/un.h>
@@ -21,6 +22,9 @@
 #include "../kselftest.h"
 #include "clone3_selftests.h"
 
+static bool shadow_stack_supported;
+static size_t max_supported_args_size;
+
 enum test_mode {
 	CLONE3_ARGS_NO_TEST,
 	CLONE3_ARGS_ALL_0,
@@ -28,6 +32,7 @@ enum test_mode {
 	CLONE3_ARGS_INVAL_EXIT_SIGNAL_NEG,
 	CLONE3_ARGS_INVAL_EXIT_SIGNAL_CSIG,
 	CLONE3_ARGS_INVAL_EXIT_SIGNAL_NSIG,
+	CLONE3_ARGS_SHADOW_STACK,
 };
 
 typedef bool (*filter_function)(void);
@@ -44,6 +49,27 @@ struct test {
 	filter_function filter;
 };
 
+#ifndef __NR_map_shadow_stack
+#define __NR_map_shadow_stack 453
+#endif
+
+static void test_shadow_stack_supported(void)
+{
+        long shadow_stack;
+
+	shadow_stack = syscall(__NR_map_shadow_stack, 0, getpagesize(), 0);
+	if (shadow_stack == -1) {
+		ksft_print_msg("map_shadow_stack() not supported\n");
+	} else if ((void *)shadow_stack == MAP_FAILED) {
+		ksft_print_msg("Failed to map shadow stack\n");
+	} else {
+		ksft_print_msg("Shadow stack supportd\n");
+		shadow_stack_supported = true;
+
+		munmap((void *)shadow_stack, getpagesize());
+	}
+}
+
 static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
 {
 	struct __clone_args args = {
@@ -89,6 +115,9 @@ static int call_clone3(uint64_t flags, size_t size, enum test_mode test_mode)
 	case CLONE3_ARGS_INVAL_EXIT_SIGNAL_NSIG:
 		args.exit_signal = 0x00000000000000f0ULL;
 		break;
+	case CLONE3_ARGS_SHADOW_STACK:
+		args.shadow_stack_size = getpagesize();
+		break;
 	}
 
 	memcpy(&args_ext.args, &args, sizeof(struct __clone_args));
@@ -179,6 +208,26 @@ static bool no_timenamespace(void)
 	return true;
 }
 
+static bool have_shadow_stack(void)
+{
+	if (shadow_stack_supported) {
+		ksft_print_msg("Shadow stack supported\n");
+		return true;
+	}
+
+	return false;
+}
+
+static bool no_shadow_stack(void)
+{
+	if (!shadow_stack_supported) {
+		ksft_print_msg("Shadow stack not supported\n");
+		return true;
+	}
+
+	return false;
+}
+
 static size_t page_size_plus_8(void)
 {
 	return getpagesize() + 8;
@@ -322,6 +371,24 @@ static const struct test tests[] = {
 		.expected = -EINVAL,
 		.test_mode = CLONE3_ARGS_NO_TEST,
 	},
+	{
+		.name = "Shadow stack on system with shadow stack",
+		.flags = 0,
+		.size = 0,
+		.expected = 0,
+		.e2big_valid = true,
+		.test_mode = CLONE3_ARGS_SHADOW_STACK,
+		.filter = no_shadow_stack,
+	},
+	{
+		.name = "Shadow stack on system without shadow stack",
+		.flags = 0,
+		.size = 0,
+		.expected = -EINVAL,
+		.e2big_valid = true,
+		.test_mode = CLONE3_ARGS_SHADOW_STACK,
+		.filter = have_shadow_stack,
+	},
 };
 
 int main(int argc, char *argv[])
@@ -332,6 +399,7 @@ int main(int argc, char *argv[])
 	ksft_print_header();
 	ksft_set_plan(ARRAY_SIZE(tests));
 	test_clone3_supported();
+	test_shadow_stack_supported();
 
 	for (i = 0; i < ARRAY_SIZE(tests); i++)
 		test_clone3(&tests[i]);
diff --git a/tools/testing/selftests/clone3/clone3_selftests.h b/tools/testing/selftests/clone3/clone3_selftests.h
index 3d2663fe50ba..2e06127091f5 100644
--- a/tools/testing/selftests/clone3/clone3_selftests.h
+++ b/tools/testing/selftests/clone3/clone3_selftests.h
@@ -31,6 +31,13 @@ struct __clone_args {
 	__aligned_u64 set_tid;
 	__aligned_u64 set_tid_size;
 	__aligned_u64 cgroup;
+#ifndef CLONE_ARGS_SIZE_VER2
+#define CLONE_ARGS_SIZE_VER2 88	/* sizeof third published struct */
+#endif
+	__aligned_u64 shadow_stack_size;
+#ifndef CLONE_ARGS_SIZE_VER3
+#define CLONE_ARGS_SIZE_VER3 96 /* sizeof fourth published struct */
+#endif
 };
 
 static pid_t sys_clone3(struct __clone_args *args, size_t size)

-- 
2.30.2

Re: [PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

[Edgecombe, Rick P]

On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:
> +static void test_shadow_stack_supported(void)
> +{
> +        long shadow_stack;
> +
> +       shadow_stack = syscall(__NR_map_shadow_stack, 0,
> getpagesize(), 0);

Hmm, x86 fails this call if user shadow stack is not supported in the
HW or the kernel, but doesn't care if it is enabled on the thread or
not. If shadow stack is not enabled (or not yet enabled), shadow stacks
are allowed to be mapped. Should it fail if shadow stack is not yet
enabled?

Since shadow stack is per thread, map_shadow_stack could still be
called on another thread that has it enabled. Basically I don't think
blocking it will reduce the possible states the kernel has to handle.

The traditional way to check if shadow stack is enabled on x86 is the
check for a non zero return from the _get_ssp() intrinsic:
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/x86-control-flow-protection-intrinsics.html

It seems like there will be a need for some generic method of checking
if shadow stack is enabled. Maybe a more generic compiler
intrinsic/builtin or glibc API (something unrelated to SSP)?

> +       {
> +               .name = "Shadow stack on system with shadow stack",
> +               .flags = 0,
> +               .size = 0,
> +               .expected = 0,
> +               .e2big_valid = true,
> +               .test_mode = CLONE3_ARGS_SHADOW_STACK,
> +               .filter = no_shadow_stack,
> +       },
> +       {
> +               .name = "Shadow stack on system without shadow
> stack",
> +               .flags = 0,
> +               .size = 0,
> +               .expected = -EINVAL,
> +               .e2big_valid = true,
> +               .test_mode = CLONE3_ARGS_SHADOW_STACK,
> +               .filter = have_shadow_stack,
> +       },
>  };
>  
I changed x86's map_shadow_stack to return an error when shadow stack
was not enabled to make the detection logic in the test work. Also
changed the clone3 Makefile to generate the shadow stack bit in the
tests. When running the 'clone3' test with shadow stack it passed, but
there is a failure in the non-shadow stack case:
...
# Shadow stack not supported
ok 20 # SKIP Shadow stack on system with shadow stack
# Running test 'Shadow stack on system without shadow stack'
# [1333] Trying clone3() with flags 0 (size 0)
# I am the parent (1333). My child's pid is 1342
# I am the child, my PID is 1342
# [1333] clone3() with flags says: 0 expected -22
# [1333] Result (0) is different than expected (-22)
not ok 21 Shadow stack on system without shadow stack
# Totals: pass:19 fail:1 xfail:0 xpass:0 skip:1 error:0

The other tests passed in both cases. I'm going to dig into the other
parts now but can circle back if it's not obvious what's going on
there.

Re: [PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK

[Edgecombe, Rick P]

On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:
> +config ARCH_HAS_USER_SHADOW_STACK
> +       bool
> +       help
> +         The architecture has hardware support for userspace shadow
> call
> +          stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi).

I feel like normally a patch like this should come with the second
feature that gets enabled. (i.e. arm or riscv). Especially since the
comment lists currently unsupported features. I think something like
this got nixed by an x86 maintainer earlier, but that was before these
other features were getting pushed.

I don't have a strong objection to having it ahead of the other
features though and it is nice to remove X86 defines out of core code.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Edgecombe, Rick P]

On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:
> diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
> index 59e15dd8d0f8..7ffe90010587 100644
> --- a/arch/x86/kernel/shstk.c
> +++ b/arch/x86/kernel/shstk.c
> @@ -191,18 +191,38 @@ void reset_thread_features(void)
>         current->thread.features_locked = 0;
>  }
>  
> -unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
> unsigned long clone_flags,
> -                                      unsigned long stack_size)
> +unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
> +                                      const struct kernel_clone_args
> *args)
>  {
>         struct thread_shstk *shstk = &tsk->thread.shstk;
> +       unsigned long clone_flags = args->flags;
>         unsigned long addr, size;
>  
>         /*
>          * If shadow stack is not enabled on the new thread, skip any
> -        * switch to a new shadow stack.
> +        * implicit switch to a new shadow stack and reject attempts
> to
> +        * explciitly specify one.
>          */
> -       if (!features_enabled(ARCH_SHSTK_SHSTK))
> +       if (!features_enabled(ARCH_SHSTK_SHSTK)) {
> +               if (args->shadow_stack)
> +                       return (unsigned long)ERR_PTR(-EINVAL);
> +
>                 return 0;
> +       }
> +
> +       /*
> +        * If the user specified a shadow stack then do some basic
> +        * validation and use it.  The caller is responsible for
> +        * freeing the shadow stack.
> +        */
> +       if (args->shadow_stack_size) {
> +               size = args->shadow_stack_size;
> +
> +               if (size < 8)
> +                       return (unsigned long)ERR_PTR(-EINVAL);

What is the intention here? The check in map_shadow_stack is to leave
space for the token, but here there is no token.

I think for CLONE_VM we should not require a non-zero size. Speaking of
CLONE_VM we should probably be clear on what the expected behavior is
for situations when a new shadow stack is not usually allocated.
!CLONE_VM || CLONE_VFORK will use the existing shadow stack. Should we
require shadow_stack_size be zero in this case, or just ignore it? I'd
lean towards requiring it to be zero so userspace doesn't pass garbage
in that we have to accommodate later. What we could possibly need to do
around that though, I'm not sure. What do you think?

> +       } else {
> +               size = args->stack_size;
> +       }
>  
>         /*
>          * For CLONE_VFORK the child will share the parents shadow
> stack.
> @@ -222,7 +242,7 @@ unsigned long shstk_alloc_thread_stack(struct
> task_struct *tsk, unsigned long cl
>         if (!(clone_flags & CLONE_VM))
>                 return 0;
>  
> -       size = adjust_shstk_size(stack_size);
> +       size = adjust_shstk_size(size);
>         addr = alloc_shstk(0, size, 0, false);
>         if (IS_ERR_VALUE(addr))
>                 return addr;
> diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
> index a23af225c898..94e7cf62be51 100644
> --- a/include/linux/sched/task.h
> +++ b/include/linux/sched/task.h
> @@ -41,6 +41,8 @@ struct kernel_clone_args {
>         void *fn_arg;
>         struct cgroup *cgrp;
>         struct css_set *cset;
> +       unsigned long shadow_stack;

Was this ^ left in accidentally? Elsewhere in this patch it is getting
checked too.

> +       unsigned long shadow_stack_size;
>  };
>  
>  /*
> diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
> index 3bac0a8ceab2..a998b6d0c897 100644
> --- a/include/uapi/linux/sched.h
> +++ b/include/uapi/linux/sched.h
> @@ -84,6 +84,8 @@
>   *                kernel's limit of nested PID namespaces.
>   * @cgroup:       If CLONE_INTO_CGROUP is specified set this to
>   *                a file descriptor for the cgroup.
> + * @shadow_stack_size: Specify the size of the shadow stack to
> allocate
> + *                     for the child process.
>   *
>   * The structure is versioned by size and thus extensible.
>   * New struct members must go at the end of the struct and
> @@ -101,12 +103,14 @@ struct clone_args {
>         __aligned_u64 set_tid;
>         __aligned_u64 set_tid_size;
>         __aligned_u64 cgroup;
> +       __aligned_u64 shadow_stack_size;
>  };
>  #endif
>  
>  #define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
>  #define CLONE_ARGS_SIZE_VER1 80 /* sizeof second published struct */
>  #define CLONE_ARGS_SIZE_VER2 88 /* sizeof third published struct */
> +#define CLONE_ARGS_SIZE_VER3 96 /* sizeof fourth published struct */
>  
>  /*
>   * Scheduling policies
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 10917c3e1f03..b0df69c8185e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -3067,7 +3067,9 @@ noinline static int
> copy_clone_args_from_user(struct kernel_clone_args *kargs,
>                      CLONE_ARGS_SIZE_VER1);
>         BUILD_BUG_ON(offsetofend(struct clone_args, cgroup) !=
>                      CLONE_ARGS_SIZE_VER2);
> -       BUILD_BUG_ON(sizeof(struct clone_args) !=
> CLONE_ARGS_SIZE_VER2);
> +       BUILD_BUG_ON(offsetofend(struct clone_args,
> shadow_stack_size) !=
> +                    CLONE_ARGS_SIZE_VER3);
> +       BUILD_BUG_ON(sizeof(struct clone_args) !=
> CLONE_ARGS_SIZE_VER3);
>  
>         if (unlikely(usize > PAGE_SIZE))
>                 return -E2BIG;
> @@ -3110,6 +3112,7 @@ noinline static int
> copy_clone_args_from_user(struct kernel_clone_args *kargs,
>                 .tls            = args.tls,
>                 .set_tid_size   = args.set_tid_size,
>                 .cgroup         = args.cgroup,
> +               .shadow_stack_size      = args.shadow_stack_size,
>         };
>  
>         if (args.set_tid &&
> @@ -3150,6 +3153,23 @@ static inline bool clone3_stack_valid(struct
> kernel_clone_args *kargs)
>         return true;
>  }
>  
> +/**
> + * clone3_shadow_stack_valid - check and prepare shadow stack
> + * @kargs: kernel clone args
> + *
> + * Verify that shadow stacks are only enabled if supported.
> + */
> +static inline bool clone3_shadow_stack_valid(struct
> kernel_clone_args *kargs)
> +{
> +#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
> +       /* The architecture must check support on the specific
> machine */
> +       return true;
> +#else
> +       /* The architecture does not support shadow stacks */
> +       return !kargs->shadow_stack_size;
> +#endif

This might be simpler:
	return IS_ENABLED(CONFIG_ARCH_HAS_USER_SHADOW_STACK) ||
	       !kargs->shadow_stack_size;

> +}
> +
>  static bool clone3_args_valid(struct kernel_clone_args *kargs)
>  {
>         /* Verify that no unknown flags are passed along. */
> @@ -3172,7 +3192,7 @@ static bool clone3_args_valid(struct
> kernel_clone_args *kargs)
>             kargs->exit_signal)
>                 return false;
>  
> -       if (!clone3_stack_valid(kargs))
> +       if (!clone3_stack_valid(kargs) ||
> !clone3_shadow_stack_valid(kargs))
>                 return false;
>  
>         return true;
> 

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

On Wed, Nov 15, 2023 at 12:45:45AM +0000, Edgecombe, Rick P wrote:
> On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:

> > +               if (size < 8)
> > +                       return (unsigned long)ERR_PTR(-EINVAL);

> What is the intention here? The check in map_shadow_stack is to leave
> space for the token, but here there is no token.

It was to ensure that there is sufficient space for at least one entry
on the stack.

> I think for CLONE_VM we should not require a non-zero size. Speaking of
> CLONE_VM we should probably be clear on what the expected behavior is
> for situations when a new shadow stack is not usually allocated.
> !CLONE_VM || CLONE_VFORK will use the existing shadow stack. Should we
> require shadow_stack_size be zero in this case, or just ignore it? I'd
> lean towards requiring it to be zero so userspace doesn't pass garbage
> in that we have to accommodate later. What we could possibly need to do
> around that though, I'm not sure. What do you think?

Yes, requiring it to be zero in that case makes sense I think.

> > +++ b/include/linux/sched/task.h
> > @@ -41,6 +41,8 @@ struct kernel_clone_args {
> >         void *fn_arg;
> >         struct cgroup *cgrp;
> >         struct css_set *cset;
> > +       unsigned long shadow_stack;
> 
> Was this ^ left in accidentally? Elsewhere in this patch it is getting
> checked too.

Yes, it's just bitrot from removing the pointer.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

On Tue, Nov 14, 2023 at 11:11:58PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:

> > +       shadow_stack = syscall(__NR_map_shadow_stack, 0,
> > getpagesize(), 0);

> Hmm, x86 fails this call if user shadow stack is not supported in the
> HW or the kernel, but doesn't care if it is enabled on the thread or
> not. If shadow stack is not enabled (or not yet enabled), shadow stacks
> are allowed to be mapped. Should it fail if shadow stack is not yet
> enabled?

> Since shadow stack is per thread, map_shadow_stack could still be
> called on another thread that has it enabled. Basically I don't think
> blocking it will reduce the possible states the kernel has to handle.

Indeed - I would expect map_shadow_stack() to always succeed if the
system supports it since it could reasonably be called as part of the
preparation for enabling it and even if someone calls it and never
actually uses the resulting memory there's no more harm to that than
any other memory allocation.  The arm64 code wasn't explicitly caring if
we actually had GCS enabled when we clone and just alloacating the stack
if requested which on reflection is more just an opportunity for users
to mess up than something we usefully want to support.

> The traditional way to check if shadow stack is enabled on x86 is the
> check for a non zero return from the _get_ssp() intrinsic:
> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/x86-control-flow-protection-intrinsics.html

> It seems like there will be a need for some generic method of checking
> if shadow stack is enabled. Maybe a more generic compiler
> intrinsic/builtin or glibc API (something unrelated to SSP)?

Some sort of feature check in libc would be nice, yes.  That said since
we really want the tests to run on systems without libc support for the
feature (if only as a bootstrapping thing) we'll need to open code
anyway.  I'll add code to startup which ensures the feature is enabled,
we can't rely on it for detection without pain though since it's
possible that we might have features locked by the startup code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On Tue, Nov 14, 2023 at 11:22:16PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:
> > +config ARCH_HAS_USER_SHADOW_STACK
> > +       bool
> > +       help
> > +         The architecture has hardware support for userspace shadow
> > call
> > +          stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi).

> I feel like normally a patch like this should come with the second
> feature that gets enabled. (i.e. arm or riscv). Especially since the
> comment lists currently unsupported features. I think something like
> this got nixed by an x86 maintainer earlier, but that was before these
> other features were getting pushed.

> I don't have a strong objection to having it ahead of the other
> features though and it is nice to remove X86 defines out of core code.

Given that the GCS patches are on the list and relatively
uncontroversial it does seem reasonable to carry this - I'm only able to
test this in the context of having both serieses applied!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK

[David Hildenbrand]

On 14.11.23 21:05, Mark Brown wrote:
> Since multiple architectures have support for shadow stacks and we need to
> select support for this feature in several places in the generic code
> provide a generic config option that the architectures can select.
> 
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>   arch/x86/Kconfig   | 1 +
>   fs/proc/task_mmu.c | 2 +-
>   include/linux/mm.h | 2 +-
>   mm/Kconfig         | 6 ++++++
>   4 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 3762f41bb092..14b7703a9a2b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1952,6 +1952,7 @@ config X86_USER_SHADOW_STACK
>   	depends on AS_WRUSS
>   	depends on X86_64
>   	select ARCH_USES_HIGH_VMA_FLAGS
> +	select ARCH_HAS_USER_SHADOW_STACK
>   	select X86_CET
>   	help
>   	  Shadow stack protection is a hardware feature that detects function
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index ef2eb12906da..f0a904aeee8e 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -699,7 +699,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
>   #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
>   		[ilog2(VM_UFFD_MINOR)]	= "ui",
>   #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> -#ifdef CONFIG_X86_USER_SHADOW_STACK
> +#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
>   		[ilog2(VM_SHADOW_STACK)] = "ss",
>   #endif
>   	};
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 418d26608ece..10462f354614 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -341,7 +341,7 @@ extern unsigned int kobjsize(const void *objp);
>   #endif
>   #endif /* CONFIG_ARCH_HAS_PKEYS */
>   
> -#ifdef CONFIG_X86_USER_SHADOW_STACK
> +#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
>   /*
>    * VM_SHADOW_STACK should not be set with VM_SHARED because of lack of
>    * support core mm.
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 89971a894b60..b8638da636e1 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1270,6 +1270,12 @@ config LOCK_MM_AND_FIND_VMA
>   	bool
>   	depends on !STACK_GROWSUP
>   
> +config ARCH_HAS_USER_SHADOW_STACK
> +	bool
> +	help
> +	  The architecture has hardware support for userspace shadow call
> +          stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi).
> +

Probably less controversial if we start with one example we have in 
place: "e.g., x86 CET". That should be sufficient to understand what 
this is about :)

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb

Re: [PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK

[Deepak Gupta]

On Tue, Nov 14, 2023 at 08:05:54PM +0000, Mark Brown wrote:
>Since multiple architectures have support for shadow stacks and we need to
>select support for this feature in several places in the generic code
>provide a generic config option that the architectures can select.
>
>Suggested-by: David Hildenbrand <david@redhat.com>
>Signed-off-by: Mark Brown <broonie@kernel.org>
>---
> arch/x86/Kconfig   | 1 +
> fs/proc/task_mmu.c | 2 +-
> include/linux/mm.h | 2 +-
> mm/Kconfig         | 6 ++++++
> 4 files changed, 9 insertions(+), 2 deletions(-)
>
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index 3762f41bb092..14b7703a9a2b 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -1952,6 +1952,7 @@ config X86_USER_SHADOW_STACK
> 	depends on AS_WRUSS
> 	depends on X86_64
> 	select ARCH_USES_HIGH_VMA_FLAGS
>+	select ARCH_HAS_USER_SHADOW_STACK
> 	select X86_CET
> 	help
> 	  Shadow stack protection is a hardware feature that detects function
>diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>index ef2eb12906da..f0a904aeee8e 100644
>--- a/fs/proc/task_mmu.c
>+++ b/fs/proc/task_mmu.c
>@@ -699,7 +699,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
> 		[ilog2(VM_UFFD_MINOR)]	= "ui",
> #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
>-#ifdef CONFIG_X86_USER_SHADOW_STACK
>+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
> 		[ilog2(VM_SHADOW_STACK)] = "ss",
> #endif
> 	};
>diff --git a/include/linux/mm.h b/include/linux/mm.h
>index 418d26608ece..10462f354614 100644
>--- a/include/linux/mm.h
>+++ b/include/linux/mm.h
>@@ -341,7 +341,7 @@ extern unsigned int kobjsize(const void *objp);
> #endif
> #endif /* CONFIG_ARCH_HAS_PKEYS */
>
>-#ifdef CONFIG_X86_USER_SHADOW_STACK
>+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
> /*
>  * VM_SHADOW_STACK should not be set with VM_SHARED because of lack of
>  * support core mm.
>diff --git a/mm/Kconfig b/mm/Kconfig
>index 89971a894b60..b8638da636e1 100644
>--- a/mm/Kconfig
>+++ b/mm/Kconfig
>@@ -1270,6 +1270,12 @@ config LOCK_MM_AND_FIND_VMA
> 	bool
> 	depends on !STACK_GROWSUP
>
>+config ARCH_HAS_USER_SHADOW_STACK
>+	bool
>+	help
>+	  The architecture has hardware support for userspace shadow call
>+          stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi).

Minor correction for future version.RISC-V choose to split extension [1, 2].
It's now:

Zicfiss - CFI using shadow stack
Zicfilp - CFI using landing pad

So for shadow stack purposes, we can start saying "RISC-V Zicfiss"

[1] - https://lists.riscv.org/g/tech-ss-lp-cfi/message/55
[2] - https://github.com/riscv/riscv-cfi/pull/126

>+
> source "mm/damon/Kconfig"
>
> endmenu
>
>-- 
>2.30.2
>

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Szabolcs.Nagy]

The 11/15/2023 12:36, Mark Brown wrote:
> On Wed, Nov 15, 2023 at 12:45:45AM +0000, Edgecombe, Rick P wrote:
> > On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:
>
> > > +               if (size < 8)
> > > +                       return (unsigned long)ERR_PTR(-EINVAL);
>
> > What is the intention here? The check in map_shadow_stack is to leave
> > space for the token, but here there is no token.
>
> It was to ensure that there is sufficient space for at least one entry
> on the stack.

end marker token (0) needs it i guess.

otherwise 0 size would be fine: the child may not execute
a call instruction at all.

> > I think for CLONE_VM we should not require a non-zero size. Speaking of
> > CLONE_VM we should probably be clear on what the expected behavior is
> > for situations when a new shadow stack is not usually allocated.
> > !CLONE_VM || CLONE_VFORK will use the existing shadow stack. Should we
> > require shadow_stack_size be zero in this case, or just ignore it? I'd
> > lean towards requiring it to be zero so userspace doesn't pass garbage
> > in that we have to accommodate later. What we could possibly need to do
> > around that though, I'm not sure. What do you think?
>
> Yes, requiring it to be zero in that case makes sense I think.

i think the condition is "no specified separate stack for
the child (stack==0 || stack==sp)".

CLONE_VFORK does not imply that the existing stack will be
used (a stack for the child can be specified, i think both
glibc and musl do this in posix_spawn).

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

On Wed, Nov 15, 2023 at 04:20:12PM +0000, Szabolcs.Nagy@arm.com wrote:
> The 11/15/2023 12:36, Mark Brown wrote:
> > On Wed, Nov 15, 2023 at 12:45:45AM +0000, Edgecombe, Rick P wrote:
> > > On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:

> > > > +               if (size < 8)
> > > > +                       return (unsigned long)ERR_PTR(-EINVAL);

> > > What is the intention here? The check in map_shadow_stack is to leave
> > > space for the token, but here there is no token.

> > It was to ensure that there is sufficient space for at least one entry
> > on the stack.

> end marker token (0) needs it i guess.

x86 doesn't currently have end markers.  Actually, that's a point -
should we add a flag for specifying the use of end markers here?
There's code in my map_shadow_stack() implementation for arm64 which
does that.

> otherwise 0 size would be fine: the child may not execute
> a call instruction at all.

Well, a size of specifically zero will result in a fallback to implicit
allocation/sizing of the stack as things stand so this is specifically
the case where a size has been specified but is smaller than a single
entry.

> > > I think for CLONE_VM we should not require a non-zero size. Speaking of
> > > CLONE_VM we should probably be clear on what the expected behavior is
> > > for situations when a new shadow stack is not usually allocated.
> > > !CLONE_VM || CLONE_VFORK will use the existing shadow stack. Should we
> > > require shadow_stack_size be zero in this case, or just ignore it? I'd
> > > lean towards requiring it to be zero so userspace doesn't pass garbage
> > > in that we have to accommodate later. What we could possibly need to do
> > > around that though, I'm not sure. What do you think?

> > Yes, requiring it to be zero in that case makes sense I think.

> i think the condition is "no specified separate stack for
> the child (stack==0 || stack==sp)".

> CLONE_VFORK does not imply that the existing stack will be
> used (a stack for the child can be specified, i think both
> glibc and musl do this in posix_spawn).

That also works as a check I think, though it requires the arch to check
for the stack==sp case - I hadn't been aware of the posix_spawn() usage,
the above checks Rick suggested just follow the handling for implicit
allocation we have currently.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Edgecombe, Rick P]

On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> > end marker token (0) needs it i guess.
> 
> x86 doesn't currently have end markers.  Actually, that's a point -
> should we add a flag for specifying the use of end markers here?
> There's code in my map_shadow_stack() implementation for arm64 which
> does that.

Hmm, I guess there isn't a way to pass a flag for the initial exec
stack? So probably it should just mirror that behavior. Unless you
think a lot of people would like to skip the default behavior.

And of course we don't have a marker on x86 (TODO with alt shadow
stacks). We could still check for size < 8 if we want it to be a
universal thing.

> 
> > otherwise 0 size would be fine: the child may not execute
> > a call instruction at all.

It seems like a special case. Where should the SSP be for the new
thread?

> 
> Well, a size of specifically zero will result in a fallback to
> implicit
> allocation/sizing of the stack as things stand so this is
> specifically
> the case where a size has been specified but is smaller than a single
> entry.
> 
> > > > I think for CLONE_VM we should not require a non-zero size.
> > > > Speaking of
> > > > CLONE_VM we should probably be clear on what the expected
> > > > behavior is
> > > > for situations when a new shadow stack is not usually
> > > > allocated.
> > > > !CLONE_VM || CLONE_VFORK will use the existing shadow stack.
> > > > Should we
> > > > require shadow_stack_size be zero in this case, or just ignore
> > > > it? I'd
> > > > lean towards requiring it to be zero so userspace doesn't pass
> > > > garbage
> > > > in that we have to accommodate later. What we could possibly
> > > > need to do
> > > > around that though, I'm not sure. What do you think?
> 
> > > Yes, requiring it to be zero in that case makes sense I think.
> 
> > i think the condition is "no specified separate stack for
> > the child (stack==0 || stack==sp)".
> 
> > CLONE_VFORK does not imply that the existing stack will be
> > used (a stack for the child can be specified, i think both
> > glibc and musl do this in posix_spawn).
> 
> That also works as a check I think, though it requires the arch to
> check
> for the stack==sp case - I hadn't been aware of the posix_spawn()
> usage,
> the above checks Rick suggested just follow the handling for implicit
> allocation we have currently.

I didn't realize it was passing its own stack either. I guess the
reason is to avoid stack overflows. But none of the specific reasons
listed in the comments seem to applicable to shadow stacks.

What is the case for stack=sp bit of the logic?


I need to look into this more. My first thought is, passing in a stack
doesn't absolutely mean they want a new shadow stack allocated either.
We are changing one heuristic, for another.

The other thought is, the new behavior in the !CLONE_VM case doesn't
seem optimal. fork has ->stack==0. Then we would be allocating a stack
in only the child's MM and changing the SSP there, and for what reason?
So I don't think we should fully move away from taking hints from the
CLONE flags.

Maybe an alternate could just be to lose the CLONE_VFORK specific stack
sharing logic. CLONE_VM always gets a new shadow stack. I don't think
it would disturb userspace functionally, but just involves more
mapping/unmapping.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Szabolcs.Nagy]

The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> >
> > > otherwise 0 size would be fine: the child may not execute
> > > a call instruction at all.
>
> It seems like a special case. Where should the SSP be for the new
> thread?

yes it is likely not an interesting case in practice so < 8
can be an error i think.

> > > > > I think for CLONE_VM we should not require a non-zero size.
> > > > > Speaking of
> > > > > CLONE_VM we should probably be clear on what the expected
> > > > > behavior is
> > > > > for situations when a new shadow stack is not usually
> > > > > allocated.
> > > > > !CLONE_VM || CLONE_VFORK will use the existing shadow stack.
> > > > > Should we
> > > > > require shadow_stack_size be zero in this case, or just ignore
> > > > > it? I'd
> > > > > lean towards requiring it to be zero so userspace doesn't pass
> > > > > garbage
> > > > > in that we have to accommodate later. What we could possibly
> > > > > need to do
> > > > > around that though, I'm not sure. What do you think?
> >
> > > > Yes, requiring it to be zero in that case makes sense I think.
> >
> > > i think the condition is "no specified separate stack for
> > > the child (stack==0 || stack==sp)".
> >
> > > CLONE_VFORK does not imply that the existing stack will be
> > > used (a stack for the child can be specified, i think both
> > > glibc and musl do this in posix_spawn).
> >
> > That also works as a check I think, though it requires the arch to
> > check
> > for the stack==sp case - I hadn't been aware of the posix_spawn()
> > usage,
> > the above checks Rick suggested just follow the handling for implicit
> > allocation we have currently.
>
> I didn't realize it was passing its own stack either. I guess the
> reason is to avoid stack overflows. But none of the specific reasons
> listed in the comments seem to applicable to shadow stacks.

while CLONE_VFORK allows the child to use the parent shadow
stack (parent and child cannot execute at the same time and
the child wont return to frames created by the parent), we
want to enable precise size accounting of the shadow stack
so requesting a new shadow stack should work if new stack
is specified.

but stack==0 can force shadow_stack_size==0.

i guess the tricky case is stack!=0 && shadow_stack_size==0:
the user may want a new shadow stack with default size logic,
or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
shadow stack from the parent.

>
> What is the case for stack=sp bit of the logic?

iirc it is not documented in the clone man page what stack=0
means and of course you don't want sp==0 in the vfork child
so some targets sets stack to sp in vfork, others set it 0
and expect the kernel to do the right thing.

this likely does not apply to clone3 where the size has to be
specified so maybe stack==sp does not need special treatment.

> I need to look into this more. My first thought is, passing in a stack
> doesn't absolutely mean they want a new shadow stack allocated either.
> We are changing one heuristic, for another.

yes.

> The other thought is, the new behavior in the !CLONE_VM case doesn't
> seem optimal. fork has ->stack==0. Then we would be allocating a stack
> in only the child's MM and changing the SSP there, and for what reason?
> So I don't think we should fully move away from taking hints from the
> CLONE flags.

only stack!=0 case is tricky. stack==0 means existing shadow stack.

>
> Maybe an alternate could just be to lose the CLONE_VFORK specific stack
> sharing logic. CLONE_VM always gets a new shadow stack. I don't think
> it would disturb userspace functionally, but just involves more
> mapping/unmapping.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Thu, Nov 16, 2023 at 10:32:06AM +0000, Szabolcs.Nagy@arm.com wrote:
> The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:

> while CLONE_VFORK allows the child to use the parent shadow
> stack (parent and child cannot execute at the same time and
> the child wont return to frames created by the parent), we
> want to enable precise size accounting of the shadow stack
> so requesting a new shadow stack should work if new stack
> is specified.

> but stack==0 can force shadow_stack_size==0.

> i guess the tricky case is stack!=0 && shadow_stack_size==0:
> the user may want a new shadow stack with default size logic,
> or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> shadow stack from the parent.

If shadow_stack_size is 0 then we're into clone() behaviour and doing
the default/implicit handling which is to do exactly what the above
describes.

> > What is the case for stack=sp bit of the logic?

> iirc it is not documented in the clone man page what stack=0
> means and of course you don't want sp==0 in the vfork child
> so some targets sets stack to sp in vfork, others set it 0
> and expect the kernel to do the right thing.

The manual page explicitly says that not specifying a stack means to use
the same stack area as the parent.

> this likely does not apply to clone3 where the size has to be
> specified so maybe stack==sp does not need special treatment.

You'd have to be jumping through hoops to manage to get the same stack
pointer while explicitly specifying a stack with clone3() on
architectures where the stack grows down.  I'm not sure there's a
reasonable use case.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Szabolcs.Nagy]

The 11/16/2023 12:33, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 10:32:06AM +0000, Szabolcs.Nagy@arm.com wrote:
> > The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> > > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
>
> > while CLONE_VFORK allows the child to use the parent shadow
> > stack (parent and child cannot execute at the same time and
> > the child wont return to frames created by the parent), we
> > want to enable precise size accounting of the shadow stack
> > so requesting a new shadow stack should work if new stack
> > is specified.
>
> > but stack==0 can force shadow_stack_size==0.
>
> > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > the user may want a new shadow stack with default size logic,
> > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > shadow stack from the parent.
>
> If shadow_stack_size is 0 then we're into clone() behaviour and doing
> the default/implicit handling which is to do exactly what the above
> describes.

sounds good.

> > > What is the case for stack=sp bit of the logic?
>
> > iirc it is not documented in the clone man page what stack=0
> > means and of course you don't want sp==0 in the vfork child
> > so some targets sets stack to sp in vfork, others set it 0
> > and expect the kernel to do the right thing.
>
> The manual page explicitly says that not specifying a stack means to use
> the same stack area as the parent.

not for clone. clone3 yes.

> > this likely does not apply to clone3 where the size has to be
> > specified so maybe stack==sp does not need special treatment.
>
> You'd have to be jumping through hoops to manage to get the same stack
> pointer while explicitly specifying a stack with clone3() on
> architectures where the stack grows down.  I'm not sure there's a
> reasonable use case.

ok makes sense.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Szabolcs.Nagy]

The 11/16/2023 12:33, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 10:32:06AM +0000, Szabolcs.Nagy@arm.com wrote:
> > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > the user may want a new shadow stack with default size logic,
> > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > shadow stack from the parent.
>
> If shadow_stack_size is 0 then we're into clone() behaviour and doing
> the default/implicit handling which is to do exactly what the above
> describes.

to be clear does clone with flags==CLONE_VM|CLONE_VFORK always
use the parent shadow stack independently of the stack argument?
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

On Thu, Nov 16, 2023 at 01:55:07PM +0000, Szabolcs.Nagy@arm.com wrote:
> The 11/16/2023 12:33, Mark Brown wrote:
> > On Thu, Nov 16, 2023 at 10:32:06AM +0000, Szabolcs.Nagy@arm.com wrote:

> > > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > > the user may want a new shadow stack with default size logic,
> > > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > > shadow stack from the parent.

> > If shadow_stack_size is 0 then we're into clone() behaviour and doing
> > the default/implicit handling which is to do exactly what the above
> > describes.

> to be clear does clone with flags==CLONE_VM|CLONE_VFORK always
> use the parent shadow stack independently of the stack argument?

!CLONE_VM rather than CLONE_VM but yes, that's what the clone() and
hence current clone3() behaviour is here.

> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

There are mechanisms for disabling this...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Edgecombe, Rick P]

On Thu, 2023-11-16 at 15:35 +0000, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 01:55:07PM +0000,
> Szabolcs.Nagy@arm.com wrote:
> > The 11/16/2023 12:33, Mark Brown wrote:
> > > On Thu, Nov 16, 2023 at 10:32:06AM +0000,
> > > Szabolcs.Nagy@arm.com wrote:
> 
> > > > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > > > the user may want a new shadow stack with default size logic,
> > > > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > > > shadow stack from the parent.
> 
> > > If shadow_stack_size is 0 then we're into clone() behaviour and
> > > doing
> > > the default/implicit handling which is to do exactly what the
> > > above
> > > describes.
> 
> > to be clear does clone with flags==CLONE_VM|CLONE_VFORK always
> > use the parent shadow stack independently of the stack argument?
> 
> !CLONE_VM rather than CLONE_VM but yes, that's what the clone() and
> hence current clone3() behaviour is here.

"flags & CLONE_VM" gets a new shadow stack, unless also 
"flags & CLONE_VFORK". Other flags in there are not consulted for the
logic of whether to create a new shadow stack.

So CLONE_VM|CLONE_VFORK will use the parent shadow stack.

!CLONE_VM will also sort of use the same shadow stack, but it's a COW
one.


Now that I've thought about it more, removing the CLONE_VFORK part of
the logic has several downsides. It is a little extra work to create
and unmap a shadow stack for an operation that is supposed to be this
limited fast thing.

It also will change the SSP(let me know if anyone has a general term we
can use) for the child. So if you have like:
ssp = _get_ssp()
if (!vfork()) {
	foo = *ssp;
	...
}

...it's awkward edge. In the vfork man page it points to fork which has
the text: "The child process is an exact duplicate of the parent
process except for the following points", which obviously doesn't
include SSP.

Lastly, there are already cases where the x86 glibc implementation
stays on the shadow stack when it switches regular stacks (i.e.
sigaltstack()). vfork children are not supposed to return, so it should
normally work to be on the same shadow stack. So it's not a special
situation unless we can resolve those other situations, which are
limited by the stack lifetime issues.

What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow stack?
So keep the existing logic, but the new flag can override the logic for
!CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
shadow_stack_size is then simple. 0 means use default size, !0 means
use the passed size. No need to overload and tie up args->stack.

In the other direction though... CLONE_VFORK can be used to stay on the
existing shadow stack and possibly corrupt it. This connects with
earlier discussions around signals dropping a token before being
handled and the overflow use case, and trying to guarantee one thread
per shadow stack at a time, etc. So if there is any inclination towards
trying to get that, it might actually be useful for another reason. It
will close one method for getting two threads on the same shadow stack
at the same time (one is sleeping yes, but it's the same problem in
effect).

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On Thu, Nov 16, 2023 at 12:52:09AM +0000, Edgecombe, Rick P wrote:
> On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> > > end marker token (0) needs it i guess.

> > x86 doesn't currently have end markers.  Actually, that's a point -
> > should we add a flag for specifying the use of end markers here?
> > There's code in my map_shadow_stack() implementation for arm64 which
> > does that.

> Hmm, I guess there isn't a way to pass a flag for the initial exec
> stack? So probably it should just mirror that behavior. Unless you
> think a lot of people would like to skip the default behavior.

I don't really know that anyone would particularly want to use a flag on
arm64, I was more thinking for the benefit of x86 where any termination
record would be a change.  It's certainly easier to not have flags so
I'm more than happy to leave things as they are, there's nothing
stopping further extensions of the ABI if we decide we want them later.

> And of course we don't have a marker on x86 (TODO with alt shadow
> stacks). We could still check for size < 8 if we want it to be a
> universal thing.

It does seem simpler, size < 8 is all edge case.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Edgecombe, Rick P]

On Thu, 2023-11-16 at 18:14 +0000, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 12:52:09AM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> > > > end marker token (0) needs it i guess.
> 
> > > x86 doesn't currently have end markers.  Actually, that's a point
> > > -
> > > should we add a flag for specifying the use of end markers here?
> > > There's code in my map_shadow_stack() implementation for arm64
> > > which
> > > does that.
> 
> > Hmm, I guess there isn't a way to pass a flag for the initial exec
> > stack? So probably it should just mirror that behavior. Unless you
> > think a lot of people would like to skip the default behavior.
> 
> I don't really know that anyone would particularly want to use a flag
> on
> arm64, I was more thinking for the benefit of x86 where any
> termination
> record would be a change.  It's certainly easier to not have flags so
> I'm more than happy to leave things as they are, there's nothing
> stopping further extensions of the ABI if we decide we want them
> later.

I'm hoping that shifting the shadow stack start by one frame for thread
stacks (where there is no token to find) will not disturb anything. But
for x86, we will need a new elf bit to be fully safe in implementing
alt shadow stack. When we do that we will have a chance to add an end
of stack marker without compatibility issues on x86. So just doing
default behavior seems fine.

For map_shadow_stack, the end of stack marker will shift the token,
which userspace needs to find, so that is why I wanted a flag for that.
Appreciate the consideration.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

On Thu, Nov 16, 2023 at 06:11:17PM +0000, Edgecombe, Rick P wrote:

> Now that I've thought about it more, removing the CLONE_VFORK part of
> the logic has several downsides. It is a little extra work to create
> and unmap a shadow stack for an operation that is supposed to be this
> limited fast thing.

It does rather feel like it's defeating the point of the thing.

> It also will change the SSP(let me know if anyone has a general term we
> can use) for the child. So if you have like:

SSP seems fine, we're already using shadow stack here.

> What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow stack?
> So keep the existing logic, but the new flag can override the logic for
> !CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
> shadow_stack_size is then simple. 0 means use default size, !0 means
> use the passed size. No need to overload and tie up args->stack.

That does seem like it cuts through the ambiguous cases.  If we go for
that it feels like we should require the flag when specifying a size,
just to be sure that everything is clear.  Though having said that we
could just always allocate a shadow stack if a size is specified
regardless of the flags, requiring people who want non-default behaviour
to have some idea what stack size they want.  I don't think I have
strong opinons between having the new flag or always allocating a stack
if a size is specified.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Edgecombe, Rick P]

On Thu, 2023-11-16 at 18:41 +0000, Mark Brown wrote:
> > What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow
> > stack?
> > So keep the existing logic, but the new flag can override the logic
> > for
> > !CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
> > shadow_stack_size is then simple. 0 means use default size, !0
> > means
> > use the passed size. No need to overload and tie up args->stack.
> 
> That does seem like it cuts through the ambiguous cases.  If we go
> for
> that it feels like we should require the flag when specifying a size,
> just to be sure that everything is clear.  Though having said that we
> could just always allocate a shadow stack if a size is specified
> regardless of the flags, requiring people who want non-default
> behaviour
> to have some idea what stack size they want.  I don't think I have
> strong opinons between having the new flag or always allocating a
> stack
> if a size is specified.

Either of those seem fine to me, but it would be nice to get it vetted
by the libc folks before committing. I'd maybe lean towards the one you
suggested without the new flag.

Re: [PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

[Edgecombe, Rick P]

On Tue, 2023-11-14 at 15:11 -0800, Rick Edgecombe wrote:
> The other tests passed in both cases. I'm going to dig into the other
> parts now but can circle back if it's not obvious what's going on
> there.

Finally got back to this. I think it's just a problem with the shadow
stack detection logic in the test.

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Deepak Gupta]

On Tue, Nov 14, 2023 at 08:05:55PM +0000, Mark Brown wrote:
>Unlike with the normal stack there is no API for configuring the the shadow
>stack for a new thread, instead the kernel will dynamically allocate a new
>shadow stack with the same size as the normal stack. This appears to be due
>to the shadow stack series having been in development since before the more
>extensible clone3() was added rather than anything more deliberate.
>
>Add parameters to clone3() specifying the address and size of a shadow
>stack for the newly created process, 

Probably should update commit message in next version. Address is not specified
anymore.

>we validate that the range specified
>is accessible to userspace but do not validate that it has been mapped
>appropriately for use as a shadow stack (normally via map_shadow_stack()).
>If the shadow stack is specified in this way then the caller is responsible
>for freeing the memory as with the main stack. If no shadow stack is
>specified then the existing implicit allocation and freeing behaviour is
>maintained.
>
>If the architecture does not support shadow stacks the shadow stack
>parameters must be zero, architectures that do support the feature are
>expected to have the same requirement on individual systems that lack
>shadow stack support.
>
>Update the existing x86 implementation to pay attention to the newly added
>arguments, in order to maintain compatibility we use the existing behaviour
>if no shadow stack is specified. Minimal validation is done of the supplied
>parameters, detailed enforcement is left to when the thread is executed.
>Since we are now using four fields from the kernel_clone_args we pass that
>into the shadow stack code rather than individual fields.
>
>Signed-off-by: Mark Brown <broonie@kernel.org>
>---
> arch/x86/include/asm/shstk.h | 11 +++++++----
> arch/x86/kernel/process.c    |  2 +-
> arch/x86/kernel/shstk.c      | 30 +++++++++++++++++++++++++-----
> include/linux/sched/task.h   |  2 ++
> include/uapi/linux/sched.h   |  4 ++++
> kernel/fork.c                | 24 ++++++++++++++++++++++--
> 6 files changed, 61 insertions(+), 12 deletions(-)
>
>diff --git a/arch/x86/include/asm/shstk.h b/arch/x86/include/asm/shstk.h
>index 42fee8959df7..8be7b0a909c3 100644
>--- a/arch/x86/include/asm/shstk.h
>+++ b/arch/x86/include/asm/shstk.h
>@@ -6,6 +6,7 @@
> #include <linux/types.h>
>
> struct task_struct;
>+struct kernel_clone_args;
> struct ksignal;
>
> #ifdef CONFIG_X86_USER_SHADOW_STACK
>@@ -16,8 +17,8 @@ struct thread_shstk {
>
> long shstk_prctl(struct task_struct *task, int option, unsigned long arg2);
> void reset_thread_features(void);
>-unsigned long shstk_alloc_thread_stack(struct task_struct *p, unsigned long clone_flags,
>-				       unsigned long stack_size);
>+unsigned long shstk_alloc_thread_stack(struct task_struct *p,
>+				       const struct kernel_clone_args *args);
> void shstk_free(struct task_struct *p);
> int setup_signal_shadow_stack(struct ksignal *ksig);
> int restore_signal_shadow_stack(void);
>@@ -26,8 +27,10 @@ static inline long shstk_prctl(struct task_struct *task, int option,
> 			       unsigned long arg2) { return -EINVAL; }
> static inline void reset_thread_features(void) {}
> static inline unsigned long shstk_alloc_thread_stack(struct task_struct *p,
>-						     unsigned long clone_flags,
>-						     unsigned long stack_size) { return 0; }
>+						     const struct kernel_clone_args *args)
>+{
>+	return 0;
>+}
> static inline void shstk_free(struct task_struct *p) {}
> static inline int setup_signal_shadow_stack(struct ksignal *ksig) { return 0; }
> static inline int restore_signal_shadow_stack(void) { return 0; }
>diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
>index b6f4e8399fca..a9ca80ea5056 100644
>--- a/arch/x86/kernel/process.c
>+++ b/arch/x86/kernel/process.c
>@@ -207,7 +207,7 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
> 	 * is disabled, new_ssp will remain 0, and fpu_clone() will know not to
> 	 * update it.
> 	 */
>-	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->stack_size);
>+	new_ssp = shstk_alloc_thread_stack(p, args);
> 	if (IS_ERR_VALUE(new_ssp))
> 		return PTR_ERR((void *)new_ssp);
>
>diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
>index 59e15dd8d0f8..7ffe90010587 100644
>--- a/arch/x86/kernel/shstk.c
>+++ b/arch/x86/kernel/shstk.c
>@@ -191,18 +191,38 @@ void reset_thread_features(void)
> 	current->thread.features_locked = 0;
> }
>
>-unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long clone_flags,
>-				       unsigned long stack_size)
>+unsigned long shstk_alloc_thread_stack(struct task_struct *tsk,
>+				       const struct kernel_clone_args *args)
> {
> 	struct thread_shstk *shstk = &tsk->thread.shstk;
>+	unsigned long clone_flags = args->flags;
> 	unsigned long addr, size;
>
> 	/*
> 	 * If shadow stack is not enabled on the new thread, skip any
>-	 * switch to a new shadow stack.
>+	 * implicit switch to a new shadow stack and reject attempts to
>+	 * explciitly specify one.
> 	 */
>-	if (!features_enabled(ARCH_SHSTK_SHSTK))
>+	if (!features_enabled(ARCH_SHSTK_SHSTK)) {
>+		if (args->shadow_stack)
>+			return (unsigned long)ERR_PTR(-EINVAL);
>+
> 		return 0;
>+	}
>+
>+	/*
>+	 * If the user specified a shadow stack then do some basic
>+	 * validation and use it.  The caller is responsible for
>+	 * freeing the shadow stack.
>+	 */
>+	if (args->shadow_stack_size) {
>+		size = args->shadow_stack_size;
>+
>+		if (size < 8)
>+			return (unsigned long)ERR_PTR(-EINVAL);
>+	} else {
>+		size = args->stack_size;
>+	}
>
> 	/*
> 	 * For CLONE_VFORK the child will share the parents shadow stack.
>@@ -222,7 +242,7 @@ unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long cl
> 	if (!(clone_flags & CLONE_VM))
> 		return 0;
>
>-	size = adjust_shstk_size(stack_size);
>+	size = adjust_shstk_size(size);
> 	addr = alloc_shstk(0, size, 0, false);
> 	if (IS_ERR_VALUE(addr))
> 		return addr;
>diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
>index a23af225c898..94e7cf62be51 100644
>--- a/include/linux/sched/task.h
>+++ b/include/linux/sched/task.h
>@@ -41,6 +41,8 @@ struct kernel_clone_args {
> 	void *fn_arg;
> 	struct cgroup *cgrp;
> 	struct css_set *cset;
>+	unsigned long shadow_stack;
>+	unsigned long shadow_stack_size;
> };
>
> /*
>diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
>index 3bac0a8ceab2..a998b6d0c897 100644
>--- a/include/uapi/linux/sched.h
>+++ b/include/uapi/linux/sched.h
>@@ -84,6 +84,8 @@
>  *                kernel's limit of nested PID namespaces.
>  * @cgroup:       If CLONE_INTO_CGROUP is specified set this to
>  *                a file descriptor for the cgroup.
>+ * @shadow_stack_size: Specify the size of the shadow stack to allocate
>+ *                     for the child process.
>  *
>  * The structure is versioned by size and thus extensible.
>  * New struct members must go at the end of the struct and
>@@ -101,12 +103,14 @@ struct clone_args {
> 	__aligned_u64 set_tid;
> 	__aligned_u64 set_tid_size;
> 	__aligned_u64 cgroup;
>+	__aligned_u64 shadow_stack_size;
> };
> #endif
>
> #define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
> #define CLONE_ARGS_SIZE_VER1 80 /* sizeof second published struct */
> #define CLONE_ARGS_SIZE_VER2 88 /* sizeof third published struct */
>+#define CLONE_ARGS_SIZE_VER3 96 /* sizeof fourth published struct */
>
> /*
>  * Scheduling policies
>diff --git a/kernel/fork.c b/kernel/fork.c
>index 10917c3e1f03..b0df69c8185e 100644
>--- a/kernel/fork.c
>+++ b/kernel/fork.c
>@@ -3067,7 +3067,9 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> 		     CLONE_ARGS_SIZE_VER1);
> 	BUILD_BUG_ON(offsetofend(struct clone_args, cgroup) !=
> 		     CLONE_ARGS_SIZE_VER2);
>-	BUILD_BUG_ON(sizeof(struct clone_args) != CLONE_ARGS_SIZE_VER2);
>+	BUILD_BUG_ON(offsetofend(struct clone_args, shadow_stack_size) !=
>+		     CLONE_ARGS_SIZE_VER3);
>+	BUILD_BUG_ON(sizeof(struct clone_args) != CLONE_ARGS_SIZE_VER3);
>
> 	if (unlikely(usize > PAGE_SIZE))
> 		return -E2BIG;
>@@ -3110,6 +3112,7 @@ noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
> 		.tls		= args.tls,
> 		.set_tid_size	= args.set_tid_size,
> 		.cgroup		= args.cgroup,
>+		.shadow_stack_size	= args.shadow_stack_size,
> 	};
>
> 	if (args.set_tid &&
>@@ -3150,6 +3153,23 @@ static inline bool clone3_stack_valid(struct kernel_clone_args *kargs)
> 	return true;
> }
>
>+/**
>+ * clone3_shadow_stack_valid - check and prepare shadow stack
>+ * @kargs: kernel clone args
>+ *
>+ * Verify that shadow stacks are only enabled if supported.
>+ */
>+static inline bool clone3_shadow_stack_valid(struct kernel_clone_args *kargs)
>+{
>+#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
>+	/* The architecture must check support on the specific machine */
>+	return true;
>+#else
>+	/* The architecture does not support shadow stacks */
>+	return !kargs->shadow_stack_size;
>+#endif
>+}
>+
> static bool clone3_args_valid(struct kernel_clone_args *kargs)
> {
> 	/* Verify that no unknown flags are passed along. */
>@@ -3172,7 +3192,7 @@ static bool clone3_args_valid(struct kernel_clone_args *kargs)
> 	    kargs->exit_signal)
> 		return false;
>
>-	if (!clone3_stack_valid(kargs))
>+	if (!clone3_stack_valid(kargs) || !clone3_shadow_stack_valid(kargs))
> 		return false;
>
> 	return true;
>
>-- 
>2.30.2
>

Re: [PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

[Deepak Gupta]

On Tue, Nov 14, 2023 at 11:11:58PM +0000, Edgecombe, Rick P wrote:
>On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote:
>> +static void test_shadow_stack_supported(void)
>> +{
>> +        long shadow_stack;
>> +
>> +       shadow_stack = syscall(__NR_map_shadow_stack, 0,
>> getpagesize(), 0);
>
>Hmm, x86 fails this call if user shadow stack is not supported in the
>HW or the kernel, but doesn't care if it is enabled on the thread or
>not. If shadow stack is not enabled (or not yet enabled), shadow stacks
>are allowed to be mapped. Should it fail if shadow stack is not yet
>enabled?
>
>Since shadow stack is per thread, map_shadow_stack could still be
>called on another thread that has it enabled. Basically I don't think
>blocking it will reduce the possible states the kernel has to handle.
>
>The traditional way to check if shadow stack is enabled on x86 is the
>check for a non zero return from the _get_ssp() intrinsic:
>https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/x86-control-flow-protection-intrinsics.html
>
>It seems like there will be a need for some generic method of checking
>if shadow stack is enabled. Maybe a more generic compiler
>intrinsic/builtin or glibc API (something unrelated to SSP)?

Exposing a new file under procfs would be useful?
Something like "/proc/sys/vm/user_shadow_stack_supported"

`map_shadow_stack` can return MAP_FAILED for other reasons.
I think `kselftests` are fine but I don't want people to pick up this
as test code and run with it in production :-)

So kernel providing a way to indicate whether it supports shadow stack
mappings in user mode via procfs would be useful and arch agnostic.

>
>> +       {
>> +               .name = "Shadow stack on system with shadow stack",
>> +               .flags = 0,
>> +               .size = 0,
>> +               .expected = 0,
>> +               .e2big_valid = true,
>> +               .test_mode = CLONE3_ARGS_SHADOW_STACK,
>> +               .filter = no_shadow_stack,
>> +       },
>> +       {
>> +               .name = "Shadow stack on system without shadow
>> stack",
>> +               .flags = 0,
>> +               .size = 0,
>> +               .expected = -EINVAL,
>> +               .e2big_valid = true,
>> +               .test_mode = CLONE3_ARGS_SHADOW_STACK,
>> +               .filter = have_shadow_stack,
>> +       },
>>  };
>>  
>I changed x86's map_shadow_stack to return an error when shadow stack
>was not enabled to make the detection logic in the test work. Also
>changed the clone3 Makefile to generate the shadow stack bit in the
>tests. When running the 'clone3' test with shadow stack it passed, but
>there is a failure in the non-shadow stack case:
>...
># Shadow stack not supported
>ok 20 # SKIP Shadow stack on system with shadow stack
># Running test 'Shadow stack on system without shadow stack'
># [1333] Trying clone3() with flags 0 (size 0)
># I am the parent (1333). My child's pid is 1342
># I am the child, my PID is 1342
># [1333] clone3() with flags says: 0 expected -22
># [1333] Result (0) is different than expected (-22)
>not ok 21 Shadow stack on system without shadow stack
># Totals: pass:19 fail:1 xfail:0 xpass:0 skip:1 error:0
>
>The other tests passed in both cases. I'm going to dig into the other
>parts now but can circle back if it's not obvious what's going on
>there.

Re: [PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

On Fri, Nov 17, 2023 at 01:12:46PM -0800, Deepak Gupta wrote:
> On Tue, Nov 14, 2023 at 11:11:58PM +0000, Edgecombe, Rick P wrote:

> > It seems like there will be a need for some generic method of checking
> > if shadow stack is enabled. Maybe a more generic compiler
> > intrinsic/builtin or glibc API (something unrelated to SSP)?

> Exposing a new file under procfs would be useful?
> Something like "/proc/sys/vm/user_shadow_stack_supported"

> `map_shadow_stack` can return MAP_FAILED for other reasons.
> I think `kselftests` are fine but I don't want people to pick up this
> as test code and run with it in production :-)

> So kernel providing a way to indicate whether it supports shadow stack
> mappings in user mode via procfs would be useful and arch agnostic.

I can see that might be useful for some higher level code that wants to
tune the size and nothing else.  I'd be tempted to do it through adding
a tuneable for the maximum default shadow stack size (x86 currently uses
4G) just so it's *vaguely* useful rather than just a file.  I question
the utility of that but just a plain file doesn't feel quite idiomatic.

In any case it feels like it's off topic for this series and should be
done separately.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Fri, Nov 17, 2023 at 05:43:26PM +0000, Edgecombe, Rick P wrote:

> Either of those seem fine to me, but it would be nice to get it vetted
> by the libc folks before committing. I'd maybe lean towards the one you
> suggested without the new flag.

I'll go with just taking the stack size as a parameter then, less
validation, hopefully the userspace people will be OK with that - I
agree it'd be best to get their buy in.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]