Re: [PATCHv7 03/16] x86/alternatives: Disable LASS when patching kernel alternatives

Dave Hansen
2025-06-26T14:19:02Z

On 6/26/25 06:49, Peter Zijlstra wrote:
>> +static __always_inline void lass_enable_enforcement(void)
>> +{
>> + alternative("", "clac", X86_FEATURE_LASS);
>> +}
>> +
>> +static __always_inline void lass_disable_enforcement(void)
>> +{
>> + alternative("", "stac", X86_FEATURE_LASS);
>> +}
> Much hate for this naming. WTH was wrong with lass_{clac,stac}()?
>
> We're not calling those other functions smap_{en,dis}able_enforcement()
> either (and please don't take that as a suggestion, its terrible
> naming).

It was a response to a comment from Sohil about the delta between
lass_{cl,st}ac() and plain {cl,st}ac() being subtle. They are subtle,
but I don't think it's fixable with naming.

There are lots of crazy gymnastics we could do. But there are so few
sites where AC is twiddled for LASS that I don't think it's worth it.

Let's just use the lass_{cl,st}ac() and comment both variants. First,
the existing stac()/clac():

/*
* Use these when accessing userspace (_PAGE_USER)
* mappings, regardless of location.
*/

and the new ones:

/*
* Use these when accessing kernel mappings (!_PAGE_USER)
* in the lower half of the address space.
*/

Any objections to doing that?