From: Sohil Mehta <sohil.mehta@intel.com>

Linear Address Space Separation (LASS) is a security feature that
intends to prevent malicious virtual address space accesses across
user/kernel mode.

Such mode based access protection already exists today with paging and
features such as SMEP and SMAP. However, to enforce these protections,
the processor must traverse the paging structures in memory.  Malicious
software can use timing information resulting from this traversal to
determine details about the paging structures, and these details may
also be used to determine the layout of the kernel memory.

The LASS mechanism provides the same mode-based protections as paging
but without traversing the paging structures. Because the protections
enforced by LASS are applied before paging, software will not be able to
derive paging-based timing information from the various caching
structures such as the TLBs, mid-level caches, page walker, data caches,
etc.

LASS enforcement relies on the typical kernel implementation to divide
the 64-bit virtual address space into two halves:
  Addr[63]=0 -> User address space
  Addr[63]=1 -> Kernel address space

Any data access or code execution across address spaces typically
results in a #GP fault.

The LASS enforcement for kernel data access is dependent on CR4.SMAP
being set. The enforcement can be disabled by toggling the RFLAGS.AC bit
similar to SMAP.

Define the CPU feature bits to enumerate this feature and include
feature dependencies to reflect the same.

Co-developed-by: Yian Chen <yian.chen@intel.com>
Signed-off-by: Yian Chen <yian.chen@intel.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/Kconfig.cpufeatures                |  4 ++++
 arch/x86/include/asm/cpufeatures.h          |  1 +
 arch/x86/include/asm/smap.h                 | 22 +++++++++++++++++++--
 arch/x86/include/uapi/asm/processor-flags.h |  2 ++
 arch/x86/kernel/cpu/cpuid-deps.c            |  1 +
 tools/arch/x86/include/asm/cpufeatures.h    |  1 +
 6 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures
index 250c10627ab3..9574c198fc08 100644
--- a/arch/x86/Kconfig.cpufeatures
+++ b/arch/x86/Kconfig.cpufeatures
@@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID
 	def_bool y
 	depends on !X86_64
 
+config X86_DISABLED_FEATURE_LASS
+	def_bool y
+	depends on !X86_64
+
 config X86_DISABLED_FEATURE_PKU
 	def_bool y
 	depends on !X86_INTEL_MEMORY_PROTECTION_KEYS
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index ee176236c2be..4473a6f7800b 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -313,6 +313,7 @@
 #define X86_FEATURE_SM4			(12*32+ 2) /* SM4 instructions */
 #define X86_FEATURE_AVX_VNNI		(12*32+ 4) /* "avx_vnni" AVX VNNI instructions */
 #define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT16 instructions */
+#define X86_FEATURE_LASS		(12*32+ 6) /* "lass" Linear Address Space Separation */
 #define X86_FEATURE_CMPCCXADD           (12*32+ 7) /* CMPccXADD instructions */
 #define X86_FEATURE_ARCH_PERFMON_EXT	(12*32+ 8) /* Intel Architectural PerfMon Extension */
 #define X86_FEATURE_FZRM		(12*32+10) /* Fast zero-length REP MOVSB */
diff --git a/arch/x86/include/asm/smap.h b/arch/x86/include/asm/smap.h
index 4f84d421d1cf..1f36c5b26949 100644
--- a/arch/x86/include/asm/smap.h
+++ b/arch/x86/include/asm/smap.h
@@ -23,18 +23,36 @@
 
 #else /* __ASSEMBLER__ */
 
+/*
+ * The CLAC/STAC instructions toggle enforcement of X86_FEATURE_SMAP.
+ *
+ * X86_FEATURE_LASS requires flipping the AC flag when accessing the lower half
+ * of the virtual address space, regardless of the _PAGE_BIT_USER bit in the
+ * page tables. lass_clac/stac() should be used for these cases.
+ *
+ * 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_clac(void)
+{
+	alternative("", "clac", X86_FEATURE_LASS);
+}
+
+static __always_inline void lass_stac(void)
+{
+	alternative("", "stac", X86_FEATURE_LASS);
+}
+
 static __always_inline unsigned long smap_save(void)
 {
 	unsigned long flags;
diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include/uapi/asm/processor-flags.h
index f1a4adc78272..81d0c8bf1137 100644
--- a/arch/x86/include/uapi/asm/processor-flags.h
+++ b/arch/x86/include/uapi/asm/processor-flags.h
@@ -136,6 +136,8 @@
 #define X86_CR4_PKE		_BITUL(X86_CR4_PKE_BIT)
 #define X86_CR4_CET_BIT		23 /* enable Control-flow Enforcement Technology */
 #define X86_CR4_CET		_BITUL(X86_CR4_CET_BIT)
+#define X86_CR4_LASS_BIT	27 /* enable Linear Address Space Separation support */
+#define X86_CR4_LASS		_BITUL(X86_CR4_LASS_BIT)
 #define X86_CR4_LAM_SUP_BIT	28 /* LAM for supervisor pointers */
 #define X86_CR4_LAM_SUP		_BITUL(X86_CR4_LAM_SUP_BIT)
 
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 46efcbd6afa4..98d0cdd82574 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -89,6 +89,7 @@ static const struct cpuid_dep cpuid_deps[] = {
 	{ X86_FEATURE_SHSTK,			X86_FEATURE_XSAVES    },
 	{ X86_FEATURE_FRED,			X86_FEATURE_LKGS      },
 	{ X86_FEATURE_SPEC_CTRL_SSBD,		X86_FEATURE_SPEC_CTRL },
+	{ X86_FEATURE_LASS,			X86_FEATURE_SMAP      },
 	{}
 };
 
diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/include/asm/cpufeatures.h
index e02be2962a01..20df2ce5d339 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -313,6 +313,7 @@
 #define X86_FEATURE_SM4			(12*32+ 2) /* SM4 instructions */
 #define X86_FEATURE_AVX_VNNI		(12*32+ 4) /* "avx_vnni" AVX VNNI instructions */
 #define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT16 instructions */
+#define X86_FEATURE_LASS		(12*32+ 6) /* "lass" Linear Address Space Separation */
 #define X86_FEATURE_CMPCCXADD           (12*32+ 7) /* CMPccXADD instructions */
 #define X86_FEATURE_ARCH_PERFMON_EXT	(12*32+ 8) /* Intel Architectural PerfMon Extension */
 #define X86_FEATURE_FZRM		(12*32+10) /* Fast zero-length REP MOVSB */
-- 
2.47.2

On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
>  
> +/*
> + * The CLAC/STAC instructions toggle enforcement of X86_FEATURE_SMAP.
> + *
> + * X86_FEATURE_LASS requires flipping the AC flag when accessing the lower half
> + * of the virtual address space, regardless of the _PAGE_BIT_USER bit in the
> + * page tables. lass_clac/stac() should be used for these cases.
> + *

Is this supposed to be "regardless" or only when the _PAGE_BIT_USER bit
it set? The way the sentence is worded it would seem that the kernel
could always use lass_clac()/stac() since the value in _PAGE_BIT_USER
doesn't matter.

Please correct me if I am wrong, but here is my understanding:

X86_FEATURE_SMAP and X86_FEATURE_LASS both complain when the kernel
tries to access the lower half of the virtual addresses.

SMAP flags an issue if _PAGE_BIT_USER is not set. LASS would #GP in both
cases with or without the _PAGE_BIT_USER being set.

However, in terms of usage, we want to use LASS specific stac()/clac()
only when _PAGE_BIT_USER is set. Since this won't be flagged by SMAP.

@Dave Hansen, you had suggested separating out the SMAP/LASS AC toggle
functions. But, the difference in usage between both of them seems very
subtle. Could this be easily misused?

For example, there is no failure that would happen if someone
incorrectly uses the SMAP specific clac()/stac() calls instead of the
LASS ones.

> + * 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_clac(void)
> +{
> +	alternative("", "clac", X86_FEATURE_LASS);
> +}
> +
> +static __always_inline void lass_stac(void)
> +{
> +	alternative("", "stac", X86_FEATURE_LASS);
> +}
> +

On June 20, 2025 11:14:56 AM PDT, Sohil Mehta <sohil.mehta@intel.com> wrote:
>On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
>>  
>> +/*
>> + * The CLAC/STAC instructions toggle enforcement of X86_FEATURE_SMAP.
>> + *
>> + * X86_FEATURE_LASS requires flipping the AC flag when accessing the lower half
>> + * of the virtual address space, regardless of the _PAGE_BIT_USER bit in the
>> + * page tables. lass_clac/stac() should be used for these cases.
>> + *
>
>Is this supposed to be "regardless" or only when the _PAGE_BIT_USER bit
>it set? The way the sentence is worded it would seem that the kernel
>could always use lass_clac()/stac() since the value in _PAGE_BIT_USER
>doesn't matter.
>
>Please correct me if I am wrong, but here is my understanding:
>
>X86_FEATURE_SMAP and X86_FEATURE_LASS both complain when the kernel
>tries to access the lower half of the virtual addresses.
>
>SMAP flags an issue if _PAGE_BIT_USER is not set. LASS would #GP in both
>cases with or without the _PAGE_BIT_USER being set.
>
>However, in terms of usage, we want to use LASS specific stac()/clac()
>only when _PAGE_BIT_USER is set. Since this won't be flagged by SMAP.
>
>@Dave Hansen, you had suggested separating out the SMAP/LASS AC toggle
>functions. But, the difference in usage between both of them seems very
>subtle. Could this be easily misused?
>
>For example, there is no failure that would happen if someone
>incorrectly uses the SMAP specific clac()/stac() calls instead of the
>LASS ones.
>
>> + * 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_clac(void)
>> +{
>> +	alternative("", "clac", X86_FEATURE_LASS);
>> +}
>> +
>> +static __always_inline void lass_stac(void)
>> +{
>> +	alternative("", "stac", X86_FEATURE_LASS);
>> +}
>> +

"Regardless" is correct. LASS only considers which hemisphere the virtual address is located in, because it is explicitly designed to prevent walking the page tables in the "wrong" hemisphere and therefore speculative accesses that happen to form pointers into user space addresses will not cause TLB or cache fills that might be possible to probe.

The obvious exception is when the kernel is intentionally performing accesses on behalf of user space, which is exactly what SMAP tells the hardware already.

On 6/20/25 11:14, Sohil Mehta wrote:
> @Dave Hansen, you had suggested separating out the SMAP/LASS AC toggle
> functions. But, the difference in usage between both of them seems very
> subtle. Could this be easily misused?

Logically there are two completely different things:

	1. Touching userspace
	2. Touching the lower half of the address space

If it's only userspace in the lower half of the address space, then
there's no controversy. But the problem obviously occurs when you want
to touch kernel mappings in the lower half of the address space.

I want to preserve the "stac/clas" meaning as just "touch userspace".

The new functions should be for "touch the lower half of the address
space" alone. Maybe it should be:

	lass_disable_enforcement()
	lass_enable_enforcement()

The only downside of not having stac/clac in the names is that it's not
obvious that they have an impact on SMAP because they're named to be
LASS-only. But I'm not super worried about this. If we have a
proliferation of call sites we have bigger problem on our hands.

> > functions. But, the difference in usage between both of them seems very
> > subtle. Could this be easily misused?
>
> Logically there are two completely different things:
>
>       1. Touching userspace
>       2. Touching the lower half of the address space
>
> If it's only userspace in the lower half of the address space, then
> there's no controversy. But the problem obviously occurs when you want
> to touch kernel mappings in the lower half of the address space.

Why does the kernel create the mappings to poke kernel text
for ALTERNATIVE patching in the lower half of the address space?

Instead of special "we really to want to access the lower addresses"
code, wouldn't it be easier to map the "poke" virtual addresses in normal
kernel upper-half space?

-Tony

On 6/23/25 09:25, Luck, Tony wrote:
>>> functions. But, the difference in usage between both of them seems very
>>> subtle. Could this be easily misused?
>>
>> Logically there are two completely different things:
>>
>>       1. Touching userspace
>>       2. Touching the lower half of the address space
>>
>> If it's only userspace in the lower half of the address space, then
>> there's no controversy. But the problem obviously occurs when you want
>> to touch kernel mappings in the lower half of the address space.
> 
> Why does the kernel create the mappings to poke kernel text
> for ALTERNATIVE patching in the lower half of the address space?
> 
> Instead of special "we really to want to access the lower addresses"
> code, wouldn't it be easier to map the "poke" virtual addresses in normal
> kernel upper-half space?

The upper half of the address space is shared kernel space, right? Every
PGD has identical contents in the upper half. So if we create a mapping
there,everybody get access to it. Every mm can access it. Every
*process* can access it. It still has kernel permissions of course, but
it's still a place that everybody can get at.

The lower half is *ONLY* accessible to the local mm. In this case, only
the text poking mm. It's a natural, safe, place to create a mapping that
you want to be private and not be exploited.

So, doing it in the upper half is risky.

If we *wanted*, we could have a non-shared PGD entry in the top half of
the address space. But we'd need to reserve its address space and all
that jazz. I'm not sure it's any better than just disabling LASS
enforcement for a moment.

> >> Logically there are two completely different things:
> >>
> >>       1. Touching userspace
> >>       2. Touching the lower half of the address space
> >>
> >> If it's only userspace in the lower half of the address space, then
> >> there's no controversy. But the problem obviously occurs when you want
> >> to touch kernel mappings in the lower half of the address space.
> >
> > Why does the kernel create the mappings to poke kernel text
> > for ALTERNATIVE patching in the lower half of the address space?
> >
> > Instead of special "we really to want to access the lower addresses"
> > code, wouldn't it be easier to map the "poke" virtual addresses in normal
> > kernel upper-half space?
>
> The upper half of the address space is shared kernel space, right? Every
> PGD has identical contents in the upper half. So if we create a mapping
> there,everybody get access to it. Every mm can access it. Every
> *process* can access it. It still has kernel permissions of course, but
> it's still a place that everybody can get at.
>
> The lower half is *ONLY* accessible to the local mm. In this case, only
> the text poking mm. It's a natural, safe, place to create a mapping that
> you want to be private and not be exploited.
>
> So, doing it in the upper half is risky.
>
> If we *wanted*, we could have a non-shared PGD entry in the top half of
> the address space. But we'd need to reserve its address space and all
> that jazz. I'm not sure it's any better than just disabling LASS
> enforcement for a moment.

Maybe it’s a thing to put on the list for "when x86 drops support for 32-bit".

Reserving a PGD entry in the kernel half of the address space for
local CPU use would be practical then. Perhaps there might be other
uses too.

-Tony

On June 23, 2025 4:13:34 PM PDT, "Luck, Tony" <tony.luck@intel.com> wrote:
>> >> Logically there are two completely different things:
>> >>
>> >>       1. Touching userspace
>> >>       2. Touching the lower half of the address space
>> >>
>> >> If it's only userspace in the lower half of the address space, then
>> >> there's no controversy. But the problem obviously occurs when you want
>> >> to touch kernel mappings in the lower half of the address space.
>> >
>> > Why does the kernel create the mappings to poke kernel text
>> > for ALTERNATIVE patching in the lower half of the address space?
>> >
>> > Instead of special "we really to want to access the lower addresses"
>> > code, wouldn't it be easier to map the "poke" virtual addresses in normal
>> > kernel upper-half space?
>>
>> The upper half of the address space is shared kernel space, right? Every
>> PGD has identical contents in the upper half. So if we create a mapping
>> there,everybody get access to it. Every mm can access it. Every
>> *process* can access it. It still has kernel permissions of course, but
>> it's still a place that everybody can get at.
>>
>> The lower half is *ONLY* accessible to the local mm. In this case, only
>> the text poking mm. It's a natural, safe, place to create a mapping that
>> you want to be private and not be exploited.
>>
>> So, doing it in the upper half is risky.
>>
>> If we *wanted*, we could have a non-shared PGD entry in the top half of
>> the address space. But we'd need to reserve its address space and all
>> that jazz. I'm not sure it's any better than just disabling LASS
>> enforcement for a moment.
>
>Maybe it’s a thing to put on the list for "when x86 drops support for 32-bit".
>
>Reserving a PGD entry in the kernel half of the address space for
>local CPU use would be practical then. Perhaps there might be other
>uses too.
>
>-Tony
>

Are we actually doing patching on more than one CPU at a time?

> Are we actually doing patching on more than one CPU at a time?

We could call static_key_enable()/static_key_disable() for different
keys at the same time from multiple CPUs.

Do we actually do that? Probably not.

-Tony

On June 23, 2025 5:10:50 PM PDT, "Luck, Tony" <tony.luck@intel.com> wrote:
>> Are we actually doing patching on more than one CPU at a time?
>
>We could call static_key_enable()/static_key_disable() for different
>keys at the same time from multiple CPUs.
>
>Do we actually do that? Probably not.
>
>-Tony
>

But does it actually *work*?

On 6/20/2025 11:24 AM, Dave Hansen wrote:
> On 6/20/25 11:14, Sohil Mehta wrote:
>> @Dave Hansen, you had suggested separating out the SMAP/LASS AC toggle
>> functions. But, the difference in usage between both of them seems very
>> subtle. Could this be easily misused?
> 
> Logically there are two completely different things:
> 
> 	1. Touching userspace
> 	2. Touching the lower half of the address space
> 
> If it's only userspace in the lower half of the address space, then
> there's no controversy. But the problem obviously occurs when you want
> to touch kernel mappings in the lower half of the address space.
> 

Makes sense. If we decide to go this way, we should capture some of this
thinking into the kernel comments. I find the current wording very
ambiguous.

> I want to preserve the "stac/clas" meaning as just "touch userspace".
> 
> The new functions should be for "touch the lower half of the address
> space" alone. Maybe it should be:
> 
> 	lass_disable_enforcement()
> 	lass_enable_enforcement()
> 
> The only downside of not having stac/clac in the names is that it's not
> obvious that they have an impact on SMAP because they're named to be
> LASS-only. 

Yeah, the reverse is also true, where the SMAP specific clac()/stac()
toggle LASS enforcement :)

On Fri, Jun 20, 2025 at 04:53:09PM +0300, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index ee176236c2be..4473a6f7800b 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -313,6 +313,7 @@
>  #define X86_FEATURE_SM4			(12*32+ 2) /* SM4 instructions */
>  #define X86_FEATURE_AVX_VNNI		(12*32+ 4) /* "avx_vnni" AVX VNNI instructions */
>  #define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT16 instructions */
> +#define X86_FEATURE_LASS		(12*32+ 6) /* "lass" Linear Address Space Separation */

This needs to be in /proc/cpuinfo because...?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Fri, Jun 20, 2025 at 06:35:04PM +0200, Borislav Petkov wrote:
> On Fri, Jun 20, 2025 at 04:53:09PM +0300, Kirill A. Shutemov wrote:
> > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> > index ee176236c2be..4473a6f7800b 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -313,6 +313,7 @@
> >  #define X86_FEATURE_SM4			(12*32+ 2) /* SM4 instructions */
> >  #define X86_FEATURE_AVX_VNNI		(12*32+ 4) /* "avx_vnni" AVX VNNI instructions */
> >  #define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT16 instructions */
> > +#define X86_FEATURE_LASS		(12*32+ 6) /* "lass" Linear Address Space Separation */
> 
> This needs to be in /proc/cpuinfo because...?

What is current policy around it ?

I think it is useful to advertise security features in cpuinfo. LASS fits
next to SMAP/SMEP/UMIP.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On Fri, Jun 20, 2025 at 08:33:36PM +0300, Kirill A. Shutemov wrote:
> What is current policy around it ?

Documentation/arch/x86/cpuinfo.rst

> I think it is useful to advertise security features in cpuinfo.

Because who's going to consume them?

Don't get me wrong - I am trying to see whether the whole use case for this is
well thought out. Because it becomes an ABI.

But if no one is going to use it, why bother?

Arguably, for this thing the argument would be - as it is put in that file
above:

"So, the current use of /proc/cpuinfo is to show features which the
kernel has *enabled* and *supports*."

as it has been enabled by machinery.

So that's ok. I'm just making sure we're on the same page and you're not
aiming at something completely different with this.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Fri, Jun 20, 2025 at 08:29:43PM +0200, Borislav Petkov wrote:
> On Fri, Jun 20, 2025 at 08:33:36PM +0300, Kirill A. Shutemov wrote:
> > What is current policy around it ?
> 
> Documentation/arch/x86/cpuinfo.rst
> 
> > I think it is useful to advertise security features in cpuinfo.
> 
> Because who's going to consume them?
> 
> Don't get me wrong - I am trying to see whether the whole use case for this is
> well thought out. Because it becomes an ABI.
> 
> But if no one is going to use it, why bother?
> 
> Arguably, for this thing the argument would be - as it is put in that file
> above:
> 
> "So, the current use of /proc/cpuinfo is to show features which the
> kernel has *enabled* and *supports*."
> 
> as it has been enabled by machinery.
> 
> So that's ok. I'm just making sure we're on the same page and you're not
> aiming at something completely different with this.

What about this:

LASS provides protection against a class of speculative attacks, such as
SLAM[1]. Add the "lass" flag to /proc/cpuinfo to indicate that the feature
is supported by hardware and enabled by the kernel. This allows userspace
to determine if the setup is secure against such attacks.

[1] https://download.vusec.net/papers/slam_sp24.pdf

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On Mon, Jun 23, 2025 at 11:17:02AM +0300, Kirill A. Shutemov wrote:
> What about this:
> 
> LASS provides protection against a class of speculative attacks, such as
> SLAM[1]. Add the "lass" flag to /proc/cpuinfo to indicate that the feature
> is supported by hardware and enabled by the kernel. This allows userspace
> to determine if the setup is secure against such attacks.

Yeah, thanks.

I'm still not fully on board with userspace determining whether they're
mitigated or not but that's a general problem with our mitigations.

Also, I haven't looked at the patchset yet but I think it should be also
adding code to bugs.c to make all those vulns which it addresses, report that
they're mitigated by LASS now in

grep -r . /sys/devices/system/cpu/vulnerabilities/

output.

Which makes your cpuinfo flag not really needed as we already have a special
method for the mitigations reporting.

But ok, it has gotten kernel enablement so stating so in cpuinfo is ok.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Mon, Jun 23, 2025 at 12:21:05PM +0200, Borislav Petkov wrote:
> On Mon, Jun 23, 2025 at 11:17:02AM +0300, Kirill A. Shutemov wrote:
> > What about this:
> > 
> > LASS provides protection against a class of speculative attacks, such as
> > SLAM[1]. Add the "lass" flag to /proc/cpuinfo to indicate that the feature
> > is supported by hardware and enabled by the kernel. This allows userspace
> > to determine if the setup is secure against such attacks.
> 
> Yeah, thanks.
> 
> I'm still not fully on board with userspace determining whether they're
> mitigated or not but that's a general problem with our mitigations.
> 
> Also, I haven't looked at the patchset yet but I think it should be also
> adding code to bugs.c to make all those vulns which it addresses, report that
> they're mitigated by LASS now in
> 
> grep -r . /sys/devices/system/cpu/vulnerabilities/
> 
> output.
> 
> Which makes your cpuinfo flag not really needed as we already have a special
> method for the mitigations reporting.
> 
> But ok, it has gotten kernel enablement so stating so in cpuinfo is ok.

Due to SLAM, we decided to postpone LAM enabling, until LASS is landed.

I am not sure if we want to add static
/sys/devices/system/cpu/vulnerabilities/slam with "Mitigation: LASS".

There might be other yet-to-be-discovered speculative attacks that LASS
mitigates. Security features have to visible to userspace independently of
known vulnerabilities.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On Mon, Jun 23, 2025 at 04:42:41PM +0300, Kirill A. Shutemov wrote:
> Due to SLAM, we decided to postpone LAM enabling, until LASS is landed.
> 
> I am not sure if we want to add static
> /sys/devices/system/cpu/vulnerabilities/slam with "Mitigation: LASS".
> 
> There might be other yet-to-be-discovered speculative attacks that LASS
> mitigates. Security features have to visible to userspace independently of
> known vulnerabilities.

... and the fact that a vuln is being mitigated by stating that in
/sys/devices/system/cpu/vulnerabilities/ needs to happen too.

I'm not talking about LAM enablement - I'm talking about adding a

SPECTRE_V1_MITIGATION_LASS

and setting that when X86_FEATURE_LASS is set so that luserspace gets told
that

"Spectre V1 : Mitigation: LASS"

or so.

Makes more sense?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Thu, Jun 26, 2025 at 05:18:37PM +0200, Borislav Petkov wrote:
> On Mon, Jun 23, 2025 at 04:42:41PM +0300, Kirill A. Shutemov wrote:
> > Due to SLAM, we decided to postpone LAM enabling, until LASS is landed.
> > 
> > I am not sure if we want to add static
> > /sys/devices/system/cpu/vulnerabilities/slam with "Mitigation: LASS".
> > 
> > There might be other yet-to-be-discovered speculative attacks that LASS
> > mitigates. Security features have to visible to userspace independently of
> > known vulnerabilities.
> 
> ... and the fact that a vuln is being mitigated by stating that in
> /sys/devices/system/cpu/vulnerabilities/ needs to happen too.
> 
> I'm not talking about LAM enablement - I'm talking about adding a
> 
> SPECTRE_V1_MITIGATION_LASS
> 
> and setting that when X86_FEATURE_LASS is set so that luserspace gets told
> that
> 
> "Spectre V1 : Mitigation: LASS"
> 
> or so.
> 
> Makes more sense?

I meant this crap, ofc:

        switch (bug) {
        case X86_BUG_CPU_MELTDOWN:
                if (boot_cpu_has(X86_FEATURE_PTI))
                        return sysfs_emit(buf, "Mitigation: PTI\n");

This should say "Mitigation: LASS" if LASS is enabled...

Which begs the question: how do LASS and PTI interact now?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 6/26/25 09:07, Borislav Petkov wrote:
>> Makes more sense?
> I meant this crap, ofc:
> 
>         switch (bug) {
>         case X86_BUG_CPU_MELTDOWN:
>                 if (boot_cpu_has(X86_FEATURE_PTI))
>                         return sysfs_emit(buf, "Mitigation: PTI\n");
> 
> This should say "Mitigation: LASS" if LASS is enabled...
> 
> Which begs the question: how do LASS and PTI interact now?

Maybe my babbling about LASS mitigation Meltdown was ill considered. It
seems that I've just muddied the waters.

All the real LASS-capable hardware also has RDCL_NO=1 which is the
_actual_ x86 Meltdown mitigation. Those systems are not vulnerable to
Meltdown in the first place.

They should say: "Not affected" for Meltdown, both before and after LASS.

On Thu, Jun 26, 2025 at 10:21:23AM -0700, Dave Hansen wrote:
> On 6/26/25 09:07, Borislav Petkov wrote:
> >> Makes more sense?
> > I meant this crap, ofc:
> > 
> >         switch (bug) {
> >         case X86_BUG_CPU_MELTDOWN:
> >                 if (boot_cpu_has(X86_FEATURE_PTI))
> >                         return sysfs_emit(buf, "Mitigation: PTI\n");
> > 
> > This should say "Mitigation: LASS" if LASS is enabled...
> > 
> > Which begs the question: how do LASS and PTI interact now?
> 
> Maybe my babbling about LASS mitigation Meltdown was ill considered. It
> seems that I've just muddied the waters.
> 
> All the real LASS-capable hardware also has RDCL_NO=1 which is the
> _actual_ x86 Meltdown mitigation. Those systems are not vulnerable to
> Meltdown in the first place.
> 
> They should say: "Not affected" for Meltdown, both before and after LASS.

Right. To best of my knowledge, SLAM is the only known vulnerability LASS
fixes directly so far.

So, we want an entry for SLAM?

I don't think it is very useful as we don't allow LAM if LASS is missing.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On 6/27/25 03:25, Kirill A. Shutemov wrote:
> So, we want an entry for SLAM?

SLAM wasn't ever a practical problem anywhere, so I don't think we need
to do anything on top of what we already did.

On Fri, Jun 27, 2025 at 01:25:12PM +0300, Kirill A. Shutemov wrote:
> So, we want an entry for SLAM?
> 
> I don't think it is very useful as we don't allow LAM if LASS is missing.

Nah, it is all clear now.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Hi--

On 6/20/25 6:53 AM, Kirill A. Shutemov wrote:
> From: Sohil Mehta <sohil.mehta@intel.com>
> 
> Linear Address Space Separation (LASS) is a security feature that
> intends to prevent malicious virtual address space accesses across
> user/kernel mode.
> 
> Such mode based access protection already exists today with paging and
> features such as SMEP and SMAP. However, to enforce these protections,
> the processor must traverse the paging structures in memory.  Malicious
> software can use timing information resulting from this traversal to
> determine details about the paging structures, and these details may
> also be used to determine the layout of the kernel memory.
> 
> The LASS mechanism provides the same mode-based protections as paging
> but without traversing the paging structures. Because the protections
> enforced by LASS are applied before paging, software will not be able to
> derive paging-based timing information from the various caching
> structures such as the TLBs, mid-level caches, page walker, data caches,
> etc.
> 
> LASS enforcement relies on the typical kernel implementation to divide
> the 64-bit virtual address space into two halves:
>   Addr[63]=0 -> User address space
>   Addr[63]=1 -> Kernel address space
> 
> Any data access or code execution across address spaces typically
> results in a #GP fault.
> 
> The LASS enforcement for kernel data access is dependent on CR4.SMAP
> being set. The enforcement can be disabled by toggling the RFLAGS.AC bit
> similar to SMAP.
> 
> Define the CPU feature bits to enumerate this feature and include
> feature dependencies to reflect the same.
> 
> Co-developed-by: Yian Chen <yian.chen@intel.com>
> Signed-off-by: Yian Chen <yian.chen@intel.com>
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/Kconfig.cpufeatures                |  4 ++++
>  arch/x86/include/asm/cpufeatures.h          |  1 +
>  arch/x86/include/asm/smap.h                 | 22 +++++++++++++++++++--
>  arch/x86/include/uapi/asm/processor-flags.h |  2 ++
>  arch/x86/kernel/cpu/cpuid-deps.c            |  1 +
>  tools/arch/x86/include/asm/cpufeatures.h    |  1 +
>  6 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures
> index 250c10627ab3..9574c198fc08 100644
> --- a/arch/x86/Kconfig.cpufeatures
> +++ b/arch/x86/Kconfig.cpufeatures
> @@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID
>  	def_bool y
>  	depends on !X86_64
>  
> +config X86_DISABLED_FEATURE_LASS
> +	def_bool y
> +	depends on !X86_64

Please explain why this is   !X86_64.
Thanks.

> +
>  config X86_DISABLED_FEATURE_PKU
>  	def_bool y
>  	depends on !X86_INTEL_MEMORY_PROTECTION_KEYS


-- 
~Randy

On 6/20/2025 9:02 AM, Randy Dunlap wrote:
>> +config X86_DISABLED_FEATURE_LASS
>> +	def_bool y
>> +	depends on !X86_64
> Please explain why this is   !X86_64.

When NOT on X86_64, the LASS code should not be compiled.

But first of all, as I replied earlier, X86_DISABLED_FEATURE_LASS is
completely not needed.

Thanks!
     Xin

On 6/20/25 9:12 AM, Xin Li wrote:
> On 6/20/2025 9:02 AM, Randy Dunlap wrote:
>>> +config X86_DISABLED_FEATURE_LASS
>>> +    def_bool y
>>> +    depends on !X86_64
>> Please explain why this is   !X86_64.
> 
> When NOT on X86_64, the LASS code should not be compiled.

Ah yes, the double negative caught me.

> But first of all, as I replied earlier, X86_DISABLED_FEATURE_LASS is
> completely not needed.

That's good.

Thanks.

-- 
~Randy

On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures
> index 250c10627ab3..9574c198fc08 100644
> --- a/arch/x86/Kconfig.cpufeatures
> +++ b/arch/x86/Kconfig.cpufeatures
> @@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID
>   	def_bool y
>   	depends on !X86_64
>   
> +config X86_DISABLED_FEATURE_LASS
> +	def_bool y
> +	depends on !X86_64
> +
>   config X86_DISABLED_FEATURE_PKU
>   	def_bool y
>   	depends on !X86_INTEL_MEMORY_PROTECTION_KEYS

You don't need to add X86_DISABLED_FEATURE_LASS, because the LASS code
is NOT optional at build time, i.e., you now don't have CONFIG_X86_LASS.

It was removed per the change log:

Changes from v1[1]:
- Remove CONFIG_X86_LASS

Thanks!
     Xin

On Fri, Jun 20, 2025 at 08:36:30AM -0700, Xin Li wrote:
> On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
> > diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures
> > index 250c10627ab3..9574c198fc08 100644
> > --- a/arch/x86/Kconfig.cpufeatures
> > +++ b/arch/x86/Kconfig.cpufeatures
> > @@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID
> >   	def_bool y
> >   	depends on !X86_64
> > +config X86_DISABLED_FEATURE_LASS
> > +	def_bool y
> > +	depends on !X86_64
> > +
> >   config X86_DISABLED_FEATURE_PKU
> >   	def_bool y
> >   	depends on !X86_INTEL_MEMORY_PROTECTION_KEYS
> 
> You don't need to add X86_DISABLED_FEATURE_LASS, because the LASS code
> is NOT optional at build time, i.e., you now don't have CONFIG_X86_LASS.

Hmm. But it is optional. It depends on CONFIG_X86_64. I don't think we
want it to be advertised on 32-bit kernels.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On 6/20/2025 10:31 AM, Kirill A. Shutemov wrote:
> On Fri, Jun 20, 2025 at 08:36:30AM -0700, Xin Li wrote:
>> On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
>>> diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures
>>> index 250c10627ab3..9574c198fc08 100644
>>> --- a/arch/x86/Kconfig.cpufeatures
>>> +++ b/arch/x86/Kconfig.cpufeatures
>>> @@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID
>>>    	def_bool y
>>>    	depends on !X86_64
>>> +config X86_DISABLED_FEATURE_LASS
>>> +	def_bool y
>>> +	depends on !X86_64
>>> +
>>>    config X86_DISABLED_FEATURE_PKU
>>>    	def_bool y
>>>    	depends on !X86_INTEL_MEMORY_PROTECTION_KEYS
>>
>> You don't need to add X86_DISABLED_FEATURE_LASS, because the LASS code
>> is NOT optional at build time, i.e., you now don't have CONFIG_X86_LASS.
> 
> Hmm. But it is optional. It depends on CONFIG_X86_64. I don't think we
> want it to be advertised on 32-bit kernels.
> 

I kind of ignore 32-bit...

But I simply hate adding a disabled feature that depends on !X86_64;
x86_64 has a broad scope, and new CPU features are often intentionally
not enabled for 32-bit.

(X86_DISABLED_FEATURE_PCID is the only one before LASS)

On June 20, 2025 4:46:21 PM PDT, Xin Li <xin@zytor.com> wrote:
>On 6/20/2025 10:31 AM, Kirill A. Shutemov wrote:
>> On Fri, Jun 20, 2025 at 08:36:30AM -0700, Xin Li wrote:
>>> On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
>>>> diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures
>>>> index 250c10627ab3..9574c198fc08 100644
>>>> --- a/arch/x86/Kconfig.cpufeatures
>>>> +++ b/arch/x86/Kconfig.cpufeatures
>>>> @@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID
>>>>    	def_bool y
>>>>    	depends on !X86_64
>>>> +config X86_DISABLED_FEATURE_LASS
>>>> +	def_bool y
>>>> +	depends on !X86_64
>>>> +
>>>>    config X86_DISABLED_FEATURE_PKU
>>>>    	def_bool y
>>>>    	depends on !X86_INTEL_MEMORY_PROTECTION_KEYS
>>> 
>>> You don't need to add X86_DISABLED_FEATURE_LASS, because the LASS code
>>> is NOT optional at build time, i.e., you now don't have CONFIG_X86_LASS.
>> 
>> Hmm. But it is optional. It depends on CONFIG_X86_64. I don't think we
>> want it to be advertised on 32-bit kernels.
>> 
>
>I kind of ignore 32-bit...
>
>But I simply hate adding a disabled feature that depends on !X86_64;
>x86_64 has a broad scope, and new CPU features are often intentionally
>not enabled for 32-bit.
>
>(X86_DISABLED_FEATURE_PCID is the only one before LASS)
>
>

More importantly, it is wrong. 

The 32-bit build can depend on this feature not existing, therefore it SHOULD be listed as a disabled feature.

On 2025-06-20 17:45, H. Peter Anvin wrote:
>>
>> But I simply hate adding a disabled feature that depends on !X86_64;
>> x86_64 has a broad scope, and new CPU features are often intentionally
>> not enabled for 32-bit.
>>
>> (X86_DISABLED_FEATURE_PCID is the only one before LASS)
> 
> More importantly, it is wrong.
> 
> The 32-bit build can depend on this feature not existing, therefore it SHOULD be listed as a disabled feature.
> 

Ok, that was word salad. What I meant was that the original patch is 
correct, and we SHOULD have this as a disabled feature.

The reason is that it reduces the need to explicitly test for 32/64 bits 
for features that don't exist on 32 bits. When they are flagged as 
disabled, they get filtered out *at compile time*.

	-hpa

On 6/20/2025 5:50 PM, H. Peter Anvin wrote:
> On 2025-06-20 17:45, H. Peter Anvin wrote:
>>>
>>> But I simply hate adding a disabled feature that depends on !X86_64;
>>> x86_64 has a broad scope, and new CPU features are often intentionally
>>> not enabled for 32-bit.
>>>
>>> (X86_DISABLED_FEATURE_PCID is the only one before LASS)
>>
>> More importantly, it is wrong.
>>
>> The 32-bit build can depend on this feature not existing, therefore it 
>> SHOULD be listed as a disabled feature.
>>
> 
> Ok, that was word salad. What I meant was that the original patch is 
> correct, and we SHOULD have this as a disabled feature.

Agreed!

> The reason is that it reduces the need to explicitly test for 32/64 bits 
> for features that don't exist on 32 bits. When they are flagged as 
> disabled, they get filtered out *at compile time*.

It's better to make it depend on X86_32 directly rather than !X86_64:

config X86_DISABLED_FEATURE_LASS
	def_bool y
	depends on X86_32


But the disabled feature list due to lack of 32-bit enabling will keep
growing until we remove 32-bit kernel code.

Wondering should we bother enforcing cpuid_deps[] on 32-bit?

IOW, turn off the feature when its dependency isn’t satisfied on 32b-it;
don’t just throw a warning and hope for the best.

Thanks!
     Xin

On June 23, 2025 10:40:59 AM PDT, Xin Li <xin@zytor.com> wrote:
>On 6/20/2025 5:50 PM, H. Peter Anvin wrote:
>> On 2025-06-20 17:45, H. Peter Anvin wrote:
>>>> 
>>>> But I simply hate adding a disabled feature that depends on !X86_64;
>>>> x86_64 has a broad scope, and new CPU features are often intentionally
>>>> not enabled for 32-bit.
>>>> 
>>>> (X86_DISABLED_FEATURE_PCID is the only one before LASS)
>>> 
>>> More importantly, it is wrong.
>>> 
>>> The 32-bit build can depend on this feature not existing, therefore it SHOULD be listed as a disabled feature.
>>> 
>> 
>> Ok, that was word salad. What I meant was that the original patch is correct, and we SHOULD have this as a disabled feature.
>
>Agreed!
>
>> The reason is that it reduces the need to explicitly test for 32/64 bits for features that don't exist on 32 bits. When they are flagged as disabled, they get filtered out *at compile time*.
>
>It's better to make it depend on X86_32 directly rather than !X86_64:
>
>config X86_DISABLED_FEATURE_LASS
>	def_bool y
>	depends on X86_32
>
>
>But the disabled feature list due to lack of 32-bit enabling will keep
>growing until we remove 32-bit kernel code.
>
>Wondering should we bother enforcing cpuid_deps[] on 32-bit?
>
>IOW, turn off the feature when its dependency isn’t satisfied on 32b-it;
>don’t just throw a warning and hope for the best.
>
>Thanks!
>    Xin
>

We should have the dependencies enforced; in fact, preferably we would enforce them at build time as well.

On 6/23/2025 7:04 PM, H. Peter Anvin wrote:
> On June 23, 2025 10:40:59 AM PDT, Xin Li <xin@zytor.com> wrote:
>> On 6/20/2025 5:50 PM, H. Peter Anvin wrote:
>>> On 2025-06-20 17:45, H. Peter Anvin wrote:
>>>>>
>>>>> But I simply hate adding a disabled feature that depends on !X86_64;
>>>>> x86_64 has a broad scope, and new CPU features are often intentionally
>>>>> not enabled for 32-bit.
>>>>>
>>>>> (X86_DISABLED_FEATURE_PCID is the only one before LASS)
>>>>
>>>> More importantly, it is wrong.
>>>>
>>>> The 32-bit build can depend on this feature not existing, therefore it SHOULD be listed as a disabled feature.
>>>>
>>>
>>> Ok, that was word salad. What I meant was that the original patch is correct, and we SHOULD have this as a disabled feature.
>>
>> Agreed!
>>
>>> The reason is that it reduces the need to explicitly test for 32/64 bits for features that don't exist on 32 bits. When they are flagged as disabled, they get filtered out *at compile time*.
>>
>> It's better to make it depend on X86_32 directly rather than !X86_64:
>>
>> config X86_DISABLED_FEATURE_LASS
>> 	def_bool y
>> 	depends on X86_32
>>
>>
>> But the disabled feature list due to lack of 32-bit enabling will keep
>> growing until we remove 32-bit kernel code.
>>
>> Wondering should we bother enforcing cpuid_deps[] on 32-bit?
>>
>> IOW, turn off the feature when its dependency isn’t satisfied on 32b-it;
>> don’t just throw a warning and hope for the best.
>>
>> Thanks!
>>     Xin
>>
> 
> We should have the dependencies enforced; in fact, preferably we would enforce them at build time as well.
> 
> 

Yeah, sounds something we can do later :)

On 6/23/2025 9:57 PM, Xin Li wrote:
> On 6/23/2025 7:04 PM, H. Peter Anvin wrote:
>> On June 23, 2025 10:40:59 AM PDT, Xin Li <xin@zytor.com> wrote:
>>> On 6/20/2025 5:50 PM, H. Peter Anvin wrote:
>>>> On 2025-06-20 17:45, H. Peter Anvin wrote:
>>>>>>
>>>>>> But I simply hate adding a disabled feature that depends on !X86_64;
>>>>>> x86_64 has a broad scope, and new CPU features are often 
>>>>>> intentionally
>>>>>> not enabled for 32-bit.
>>>>>>
>>>>>> (X86_DISABLED_FEATURE_PCID is the only one before LASS)
>>>>>
>>>>> More importantly, it is wrong.
>>>>>
>>>>> The 32-bit build can depend on this feature not existing, therefore 
>>>>> it SHOULD be listed as a disabled feature.
>>>>>
>>>>
>>>> Ok, that was word salad. What I meant was that the original patch is 
>>>> correct, and we SHOULD have this as a disabled feature.
>>>
>>> Agreed!
>>>
>>>> The reason is that it reduces the need to explicitly test for 32/64 
>>>> bits for features that don't exist on 32 bits. When they are flagged 
>>>> as disabled, they get filtered out *at compile time*.
>>>
>>> It's better to make it depend on X86_32 directly rather than !X86_64:
>>>
>>> config X86_DISABLED_FEATURE_LASS
>>>     def_bool y
>>>     depends on X86_32
>>>
>>>
>>> But the disabled feature list due to lack of 32-bit enabling will keep
>>> growing until we remove 32-bit kernel code.
>>>
>>> Wondering should we bother enforcing cpuid_deps[] on 32-bit?
>>>
>>> IOW, turn off the feature when its dependency isn’t satisfied on 32b-it;
>>> don’t just throw a warning and hope for the best.
>>>
>>> Thanks!
>>>     Xin
>>>
>>
>> We should have the dependencies enforced; in fact, preferably we would 
>> enforce them at build time as well.
>>
>>
> 
> Yeah, sounds something we can do later :)
> 

We could introduce a new Kconfig file at

     arch/x86/Kconfig.cpufeatures.disabled_on_32bit

to track all features disabled due to lack of 32-bit support.

On 6/20/25 06:53, Kirill A. Shutemov wrote:
> +static __always_inline void lass_clac(void)
> +{
> +	alternative("", "clac", X86_FEATURE_LASS);
> +}
> +
> +static __always_inline void lass_stac(void)
> +{
> +	alternative("", "stac", X86_FEATURE_LASS);
> +}

There are differing opinions on how to introduce code. Do you do it up
front and then use it later in the series? Or do you only introduce
infrastructure when you use it?

Doing what you have here (introduce first, use later) is fine. But it
does incur an increased burden of explaining things.

These two functions in particular mean that you have to at least allude
to how these get used later in the series.