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

[Mathias Krause]

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.

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

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

I had a system with CPU hotplug working on the P-cores but not on the
E-cores which took a while to debug because the E-cores died hard very
early on. CET was in effect way too early (not only in CR4 but also all
features via the (stale) MSR), calling a function that didn't had the
required ENDBR, causing an early, unhandled #CP.

So, a way to prevent CR4.CET enabling from happening would be nice to
have for future debugging sessions.

Thanks,
Mathias