Re: [PATCH v3] x86/cpufeatures: Make X86_FEATURE_SHSTK clearcpuid-able

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

On Thu, 2026-05-14 at 19:12 +0200, Borislav Petkov wrote:
> On Thu, May 14, 2026 at 05:07:30PM +0000, Edgecombe, Rick P wrote:
> > Do we want a non-taint version of this capability? That was Mathias' original
> > approach, but his use was just debugging. So hence, this.
> 
> No, we don't:
> 
>                         Also note that user programs calling CPUID directly
>                         or using the feature without checking anything
>                         will still see it. This just prevents it from
>                         being used by the kernel or shown in /proc/cpuinfo.
>                         Also note the kernel might malfunction if you disable
>                         some critical bits.
> 
> Do you want to debug issues because someone decided to shoot our
> representation of a CPUID flag and something is not being detected because of
> this and you're scratching your head why TF it happens?

I didn't mean to support disabling them all. I meant have a thing with the same
format as clearcpuid, but only works for features we want to support. So maybe
like disable=usershstk. And then have just less code to have to cover all the
nofoo cases. It would only support limited bits that were intentionally added.

This is not a well thought out idea though.

> 
> > Also, have you ever thought about keeping a list of approved clearcpuid values
> > that are supported for normal runtime. People could use it to turn off features
> > without picking up a taint? Like maybe people want to turn off something for
> > performance reasons or something. Then we can have one interface for it all,
> > instead of various nousershstk-like flags. Not sure if it's a good.
> 
> No, we have "no..." cmdline arguments for things where disabling the feature
> makes sense. And we support those.
> 
> The other "no..." switches we add usually as part of a chicken bit when adding
> a new feature. Subsequently, we delete them after it turns out the
> implementation is fine and there's no need for any chicken bit anymore.

Oh, I didn't realize they were intended to be short term things.

> 
> If "nousershstk" has a good use case like being able to disable CET issues,
> then by all means, that justifies supporting it fully.

Fair enough, thanks for the consideration.