| Message ID | 20250620135325.3300848-2-kirill.shutemov@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | x86: Enable Linear Address Space Separation support | expand |
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
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
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.
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.
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 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.
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.
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 */