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

[Mathias Krause]

On 07.05.26 21:53, Edgecombe, Rick P wrote:
> 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 */

I explicitly didn't propose that as I was under the assumption, hiding
that feature bit is intentional. But, as it was you who added that bit
like that in 701fb66d576e ("x86/cpufeatures: Add CPU feature flags for
shadow stacks") and is now proposing otherwise, I won't object either.

> 
> 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)

But that sounds more like having the need for an official chicken bit,
like I was proposing, no? Using 'clearcpuid=shstk' as a workaround for
whatever KVM bugs, similar in spirit to 'nousershstk', but without the
kernel taint?

>>>
>>> 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?

For *me*, 'clearcpuid=shstk,ibt' would be sufficient for my debugging
needs. It's just a question if there's more demand beside some random
kernel hacker needing a knob to disable potential problematic features,
i.e. do we expect actual *end users* having a need to fully disable CET
shadow stacks too?


Thanks,
Mathias