From: Mark Brown <broonie@kernel.org>
To: "Rick P. Edgecombe" <rick.p.edgecombe@intel.com>,
Deepak Gupta <debug@rivosinc.com>,
Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Christian Brauner <brauner@kernel.org>,
Shuah Khan <shuah@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
jannh@google.com, bsegall@google.com,
Andrew Morton <akpm@linux-foundation.org>,
Yury Khrustalev <yury.khrustalev@arm.com>,
Wilco Dijkstra <wilco.dijkstra@arm.com>,
linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org,
Mark Brown <broonie@kernel.org>, Kees Cook <kees@kernel.org>,
Kees Cook <kees@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: [PATCH v20 2/8] Documentation: userspace-api: Add shadow stack API documentation
Date: Tue, 02 Sep 2025 11:21:46 +0100 [thread overview]
Message-ID: <20250902-clone3-shadow-stack-v20-2-4d9fff1c53e7@kernel.org> (raw)
In-Reply-To: <20250902-clone3-shadow-stack-v20-0-4d9fff1c53e7@kernel.org>
There are a number of architectures with shadow stack features which we are
presenting to userspace with as consistent an API as we can (though there
are some architecture specifics). Especially given that there are some
important considerations for userspace code interacting directly with the
feature let's provide some documentation covering the common aspects.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Kees Cook <kees@kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Yury Khrustalev <yury.khrustalev@arm.com>
Reviewed-by: Deepak Gupta <debug@rivosinc.com>
Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/shadow_stack.rst | 44 ++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst
index b8c73be4fb11..0167e59b541e 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -62,6 +62,7 @@ Everything else
ELF
netlink/index
+ shadow_stack
sysfs-platform_profile
vduse
futex2
diff --git a/Documentation/userspace-api/shadow_stack.rst b/Documentation/userspace-api/shadow_stack.rst
new file mode 100644
index 000000000000..42617d0470ba
--- /dev/null
+++ b/Documentation/userspace-api/shadow_stack.rst
@@ -0,0 +1,44 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+Shadow Stacks
+=============
+
+Introduction
+============
+
+Several architectures have features which provide backward edge
+control flow protection through a hardware maintained stack, only
+writable by userspace through very limited operations. This feature
+is referred to as shadow stacks on Linux, on x86 it is part of Intel
+Control Enforcement Technology (CET), on arm64 it is Guarded Control
+Stacks feature (FEAT_GCS) and for RISC-V it is the Zicfiss extension.
+It is expected that this feature will normally be managed by the
+system dynamic linker and libc in ways broadly transparent to
+application code, this document covers interfaces and considerations.
+
+
+Enabling
+========
+
+Shadow stacks default to disabled when a userspace process is
+executed, they can be enabled for the current thread with a syscall:
+
+ - For x86 the ARCH_SHSTK_ENABLE arch_prctl()
+ - For other architectures the PR_SET_SHADOW_STACK_ENABLE prctl()
+
+It is expected that this will normally be done by the dynamic linker.
+Any new threads created by a thread with shadow stacks enabled will
+themselves have shadow stacks enabled.
+
+
+Enablement considerations
+=========================
+
+- Returning from the function that enables shadow stacks without first
+ disabling them will cause a shadow stack exception. This includes
+ any syscall wrapper or other library functions, the syscall will need
+ to be inlined.
+- A lock feature allows userspace to prevent disabling of shadow stacks.
+- Those that change the stack context like longjmp() or use of ucontext
+ changes on signal return will need support from libc.
--
2.39.5
next prev parent reply other threads:[~2025-09-02 10:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 10:21 [PATCH v20 0/8] fork: Support shadow stacks in clone3() Mark Brown
2025-09-02 10:21 ` [PATCH v20 1/8] arm64/gcs: Return a success value from gcs_alloc_thread_stack() Mark Brown
2025-09-02 10:21 ` Mark Brown [this message]
2025-09-02 10:21 ` [PATCH v20 3/8] selftests: Provide helper header for shadow stack testing Mark Brown
2025-09-02 10:21 ` [PATCH v20 4/8] fork: Add shadow stack support to clone3() Mark Brown
2025-09-02 21:02 ` Catalin Marinas
2025-09-03 10:01 ` Mark Brown
2025-09-03 15:34 ` Catalin Marinas
2025-09-05 15:21 ` Christian Brauner
2025-09-05 15:43 ` Mark Brown
2025-09-05 15:53 ` Edgecombe, Rick P
2025-09-05 16:00 ` Kees Cook
2025-09-05 16:02 ` Mark Brown
2025-09-02 10:21 ` [PATCH v20 5/8] selftests/clone3: Remove redundant flushes of output streams Mark Brown
2025-09-02 10:21 ` [PATCH v20 6/8] selftests/clone3: Factor more of main loop into test_clone3() Mark Brown
2025-09-02 10:21 ` [PATCH v20 7/8] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code Mark Brown
2025-09-02 10:21 ` [PATCH v20 8/8] selftests/clone3: Test shadow stack support Mark Brown
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=20250902-clone3-shadow-stack-v20-2-4d9fff1c53e7@kernel.org \
--to=broonie@kernel.org \
--cc=Szabolcs.Nagy@arm.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=debug@rivosinc.com \
--cc=dietmar.eggemann@arm.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=wilco.dijkstra@arm.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yury.khrustalev@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).