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

From: Peter Zijlstra
Date: Thu Jun 26 2025 - 09:51:34 EST


On Wed, Jun 25, 2025 at 03:50:56PM +0300, Kirill A. Shutemov wrote:

> +/*
> + * The CLAC/STAC instructions toggle the enforcement of X86_FEATURE_SMAP and
> + * X86_FEATURE_LASS.
> + *
> + * SMAP enforcement is based on the _PAGE_BIT_USER bit in the page tables: the
> + * kernel is not allowed to touch pages with the bit set unless the AC bit is
> + * set.
> + *
> + * LASS enforcement is based on bit 63 of the virtual address. The kernel is
> + * not allowed to touch memory in the lower half of the virtual address space
> + * unless the AC bit is set.
> + *
> + * Note: a barrier is implicit in alternative().
> + */
> +
> static __always_inline void clac(void)
> {
> - /* Note: a barrier is implicit in alternative() */
> alternative("", "clac", X86_FEATURE_SMAP);
> }
>
> static __always_inline void stac(void)
> {
> - /* Note: a barrier is implicit in alternative() */
> alternative("", "stac", X86_FEATURE_SMAP);
> }
>
> +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).