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

[Edgecombe, Rick P]

On Fri, 2026-05-08 at 09:23 +0200, Mathias Krause wrote:
> 
> 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.

It sort of was intentional back then. CET has a weird user/supervisor split,
where it is split user/supervisor in some sense but locked together in other
senses. There was a suggestion to make up some user and kernel feature bits so
Linux could differentiate which it actually supports or is using. Which is where
user_shstk came from. However, ibt already has just "ibt" to control the kernel
support. And the split idea only works part ways, because user and supervisor
are linked together in some ways. Really that one should have been be kernel_ibt
or something to be clearer, but it predated the user_shstk discussion.

But from where we are today, I guess adding "shstk" seems ok. I guess your patch
has the benefit of not stirring the messy waters. Not stirring the waters is
maybe a valid answer to Dave's question. I'm ok either way, maybe lean towards
adding "shstk".

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

For users to turn off shadow stack for guests? You can do this via the KVM API
in the normal way you customize guests.

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

Today I think no? We have nousershstk for shadow stack users, and ibt=off for
ibt. So everything is covered from the user's perspective.