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

[Mathias Krause]

On 16.05.26 17:27, Borislav Petkov wrote:
> On Fri, May 15, 2026 at 06:11:46PM +0200, Mathias Krause wrote:
>> Funny to see how x86 maintainer options completely disagree on this, see
>> https://lore.kernel.org/lkml/739e4dd0-84a3-4b37-8cc3-b7ec59737010@xxxxxxxxx/
> 
> You mean we should have an internal meeting first to agree on maintainer
> policy so that we can have a common, unified messaging to the rest of the
> community...?

?!?

> 
> Or are we allowed to disagree and find the most optimal solution in the
> process?

Of course you are. However, it would be nice to object in time and not
make a contributor implement N iterations, each being different, just
because the next maintainer didn't like the previous version. Or, at
least, other maintainers chiming in and commenting to the direction
change from their proposal. Neither happened here.

I mean, it's a stupid debugging feature, how perfect does it need to be?

> 
> Pfff.
> 
>> No, it should not, as that's only for the user portion
>> (X86_FEATURE_USER_SHSTK != X86_FEATURE_SHSTK).
>>
>> Even though there is (currently) no kernel level shadow stack support,
>> KVM may still want to pass it down to guests for their usage -- even if
>> the host *userland* shouldn't make use of it because of "nousershstk".
> 
> So do a global "disable control-flow enforcement" thing which disables all
> related features, as Rick points out.

Sorry, I can't figure which suggestion of Rick you are referring to but
maybe you're mixing it up with that?:
https://lore.kernel.org/lkml/bf9738e1-330e-4c87-a294-e8dce100ffc2@xxxxxxxxxxxxxx/

> 
> That one should dump a warning saying what also it disables and that it should
> be a debugging option. And I'm thinking it probably should taint the kernel
> too because we don't want people left'n'right to turn off shadow stacks and
> then complain...

This is getting ridiculous. It's a debug feature by nature and it feels
like clearcpuid=shstk would almost perfectly match above requirements.

> 
> Btw, this is my own opinion and just a suggestion - not a x86 maintainer
> stance. I'm throwing this out so that someone else can propose a better one
> and we arrive at the proper solution eventually. I.e., as we have always done
> it on the mailing list...
> 

Yeah, I'm out. We just handle this downstream.

Thanks,
Mathias