arch/x86/kernel/shstk.c | 9 +++++++++ 1 file changed, 9 insertions(+)
Provide a kernel command line option 'shstk=off' to disable CET shadow
stacks, much like 'ibt=off' can be used to disable CET IBT.
With both set to off, it avoids setting CR4.CET on capable hardware to
allow debugging related issues during early boot.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
---
arch/x86/kernel/shstk.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
index 978232b6d48d..68b46bf1540b 100644
--- a/arch/x86/kernel/shstk.c
+++ b/arch/x86/kernel/shstk.c
@@ -542,6 +542,15 @@ static int shstk_disable(void)
return 0;
}
+static int __init shstk_configure(char *str)
+{
+ if (!strcmp(str, "off"))
+ setup_clear_cpu_cap(X86_FEATURE_SHSTK);
+
+ return 1;
+}
+__setup("shstk=", shstk_configure);
+
SYSCALL_DEFINE3(map_shadow_stack, unsigned long, addr, unsigned long, size, unsigned int, flags)
{
bool set_tok = flags & SHADOW_STACK_SET_TOKEN;
--
2.47.3
On Thu, Apr 02, 2026 at 05:44:05PM +0200, Mathias Krause wrote: > Provide a kernel command line option 'shstk=off' to disable CET shadow > stacks, much like 'ibt=off' can be used to disable CET IBT. > > With both set to off, it avoids setting CR4.CET on capable hardware to > allow debugging related issues during early boot. Why though?
On 02.04.26 17:54, Peter Zijlstra wrote: > On Thu, Apr 02, 2026 at 05:44:05PM +0200, Mathias Krause wrote: >> Provide a kernel command line option 'shstk=off' to disable CET shadow >> stacks, much like 'ibt=off' can be used to disable CET IBT. >> >> With both set to off, it avoids setting CR4.CET on capable hardware to >> allow debugging related issues during early boot. > > Why though? I ran into related issues three times in the past now, where the lack of early exception handling and the lack of a knob to disable CR4.CET=1 enabling made debugging this a real PITA. Now, with QEMU having gained CET virtualization support, that may be less of an issue. However, in at least one case the UEFI firmware was involved and I had to test&debug on bare metal. Having such a knob allows ruling out or pin-pointing CET as the cause more easily. Thanks, Mathias
On Thu, Apr 02, 2026 at 05:59:46PM +0200, Mathias Krause wrote: > On 02.04.26 17:54, Peter Zijlstra wrote: > > On Thu, Apr 02, 2026 at 05:44:05PM +0200, Mathias Krause wrote: > >> Provide a kernel command line option 'shstk=off' to disable CET shadow > >> stacks, much like 'ibt=off' can be used to disable CET IBT. > >> > >> With both set to off, it avoids setting CR4.CET on capable hardware to > >> allow debugging related issues during early boot. > > > > Why though? > > I ran into related issues three times in the past now, where the lack of > early exception handling and the lack of a knob to disable CR4.CET=1 > enabling made debugging this a real PITA. Now, with QEMU having gained > CET virtualization support, that may be less of an issue. Ah, I wrote the kernel IBT code using a host/qemu patched with very early versions of those patches. It did indeed take ages for that stuff to land upstream. > However, in at least one case the UEFI firmware was involved and I had > to test&debug on bare metal. Having such a knob allows ruling out or > pin-pointing CET as the cause more easily. Fair enough, although this should probably have made it in the Changelog. Other than that, Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
On Thu, 2026-04-02 at 18:04 +0200, Peter Zijlstra wrote: > > However, in at least one case the UEFI firmware was involved and I > > had to test&debug on bare metal. Having such a knob allows ruling > > out or pin-pointing CET as the cause more easily. > > Fair enough, although this should probably have made it in the > Changelog. > > Other than that, Some firmwares use supervisor shadow stack in SMM and have had issues with CR4.CET set. But these were BIOS crashes. The other usefulness could be recovering from shadow stack crashes in early userspace that block boot. Acked-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Could we add something to the docs though?
On 02.04.26 18:53, Edgecombe, Rick P wrote: > On Thu, 2026-04-02 at 18:04 +0200, Peter Zijlstra wrote: >>> However, in at least one case the UEFI firmware was involved and I >>> had to test&debug on bare metal. Having such a knob allows ruling >>> out or pin-pointing CET as the cause more easily. >> >> Fair enough, although this should probably have made it in the >> Changelog. >> >> Other than that, > > Some firmwares use supervisor shadow stack in SMM and have had issues > with CR4.CET set. But these were BIOS crashes. TIL! :D > > The other usefulness could be recovering from shadow stack crashes in > early userspace that block boot. Jepp. A chicken-bit is always nice to have, IMHO. > > Acked-by: Rick Edgecombe <rick.p.edgecombe@intel.com> > > Could we add something to the docs though? As the 'ibt=off' commandline option lacks documentation as well, I don't think it's needed. There are other parameters, e.g. "debug-alternative", that are useful debugging tools but also lack documentation. The reason for that is likely that these switches are meant for developers and these can 'git grep -w __setup' easily to hunt for these. Thanks, Mathias
On 4/2/26 09:53, Edgecombe, Rick P wrote: > Could we add something to the docs though? Yes, an update to Documentation/admin-guide/kernel-parameters.txt is in order. Bonus points if the missing ibt=off gets added too.
On 02.04.26 18:57, Dave Hansen wrote: > On 4/2/26 09:53, Edgecombe, Rick P wrote: >> Could we add something to the docs though? > > Yes, an update to Documentation/admin-guide/kernel-parameters.txt is in > order. Bonus points if the missing ibt=off gets added too. Ready to pick up my bonus points: :D https://lore.kernel.org/lkml/20260402173606.1096172-1-minipli@grsecurity.net/ Cheers, Mathias
© 2016 - 2026 Red Hat, Inc.