Re: [PATCH v2] x86/shstk: Provide kernel command line knob to disable

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Thu, 2026-05-07 at 15:39 +0200, Mathias Krause wrote:
> On 07.05.26 00:45, Edgecombe, Rick P wrote:
> > On Wed, 2026-05-06 at 12:03 -0700, Dave Hansen wrote:
> > > Is there a reason that clearcpuid=shstk doesn't work in this case? I
> > > guess shstk and ibt are peers, but I was kinda hoping we'd stop adding
> > > these for every single CPU feature at _some_ point.
> > 
> > Oh yea, for the reason of "debugging related issues during early boot"
> > clearcpuid of shstk and ibt should be fine. It taints the kernel, but should be
> > fine for debugging? If I'm reading this right, the kernel does the clearcpuid
> > processing before setting up CET bits.
> 
> Unfortunately, neither 'clearcpuid=shstk' nor 'clearcpuid=user_shstk'
> are of any help.
> 
> The former doesn't work because X86_FEATURE_SHSTK has no procfs-visible
> string attached, therefore no entry in x86_cap_flags[] and therefore
> can't be found via "shstk" in parse_set_clear_cpuid().
> 
> The latter only clears X86_FEATURE_USER_SHSTK which is a synthetic
> feature bit but setup_cet() only looks for X86_FEATURE_SHSTK.

So alternatively we could just do:

diff --git a/tools/arch/x86/include/asm/cpufeatures.h
b/tools/arch/x86/include/asm/cpufeatures.h
index c3b53beb13007..270341e786f28 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -392,7 +392,7 @@
 #define X86_FEATURE_OSPKE              (16*32+ 4) /* "ospke" OS Protection Keys
Enable */
 #define X86_FEATURE_WAITPKG            (16*32+ 5) /* "waitpkg"
UMONITOR/UMWAIT/TPAUSE Instructions */
 #define X86_FEATURE_AVX512_VBMI2       (16*32+ 6) /* "avx512_vbmi2" Additional
AVX512 Vector Bit Manipulation s/
-#define X86_FEATURE_SHSTK              (16*32+ 7) /* Shadow stack */
+#define X86_FEATURE_SHSTK              (16*32+ 7) /* "shstk" Shadow stack */
 #define X86_FEATURE_GFNI               (16*32+ 8) /* "gfni" Galois Field New
Instructions */
 #define X86_FEATURE_VAES               (16*32+ 9) /* "vaes" Vector AES */
 #define X86_FEATURE_VPCLMULQDQ         (16*32+10) /* "vpclmulqdq" Carry-Less
Multiplication Double Quadword */


Now that KVM uses this this feature independently of X86_FEATURE_USER_SHSTK, it
might be good to have the plain HW shstk feature exposed for just normal runtime
user use. (+Chao, for KVM CET)

> 
> > 
> > I'm remembering we actually already have a "nousershstk" too, which covers the
> > "userspace init cet violations break boot" usage.
> 
> Oh, interesting. That'd be the equivalent of 'clearcpuid=user_shstk', right?

Right, except for no taint.

> 
> > 
> > What that doesn't do though, is clear CR4.CET. With nousershstk, KVM can still
> > use CET. So that is what is missing. A way to clear CR4.CET without tainting the
> > kernel when HW supports CET. Do we need it?
> > 
> 
> Right! Clearing, or, moreover, not setting CR4.CET=1 is what I need for
> the debugging use cases I have in mind and had to hack around a few
> times in the past.
> 
> Case in point, the last debugging session involved a bug with CPU
> hotplug where the E-cores did not reset their IA32_S_CET MSR on #INIT
> but the P-cores did (which wasn't the bug, as that's perfectly fine
> SDM-documented behaviour (not resetting, that is)).

But the above works for this case, right? The taint doesn't matter for
debugging?