Re: [PATCH] x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall

Re: [PATCH] x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall

[Kirill A. Shutemov]

Please ignore this patch. It was sent by mistake. The same patch included
in the patchset in the right spot.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCHv7 00/16] x86: Enable Linear Address Space Separation support

[Vegard Nossum]

On 25/06/2025 14:50, Kirill A. Shutemov wrote:
> Linear Address Space Separation (LASS) is a security feature that intends to
> prevent malicious virtual address space accesses across user/kernel mode.

I applied these patches on top of tip/master and when I try to boot it
fails with errno 12 (ENOMEM - Cannot allocate memory):

[    1.517526] Kernel panic - not syncing: Requested init /bin/bash 
failed (error -12).

Just using standard defconfig and booting in qemu/KVM with 2G RAM.

Bisect lands on "x86/asm: Introduce inline memcpy and memset".

Thanks,


Vegard

Re: [PATCHv7 00/16] x86: Enable Linear Address Space Separation support

[Vegard Nossum]

On 26/06/2025 11:22, Vegard Nossum wrote:
> 
> On 25/06/2025 14:50, Kirill A. Shutemov wrote:
>> Linear Address Space Separation (LASS) is a security feature that 
>> intends to
>> prevent malicious virtual address space accesses across user/kernel mode.
> 
> I applied these patches on top of tip/master and when I try to boot it
> fails with errno 12 (ENOMEM - Cannot allocate memory):
> 
> [    1.517526] Kernel panic - not syncing: Requested init /bin/bash 
> failed (error -12).
> 
> Just using standard defconfig and booting in qemu/KVM with 2G RAM.
> 
> Bisect lands on "x86/asm: Introduce inline memcpy and memset".

I think the newly added mulq to rep_stos_alternative clobbers %rdx, at
least this patch fixed it for me:

diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 5cd0f18a431fe..bc096526432a1 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
@@ -28,7 +28,7 @@ static __always_inline void *__inline_memcpy(void *to, 
const void *from, size_t
                      "2:\n\t"
                      _ASM_EXTABLE_UA(1b, 2b)
                      :"+c" (len), "+D" (to), "+S" (from), 
ASM_CALL_CONSTRAINT
-                    : : "memory", _ASM_AX);
+                    : : "memory", _ASM_AX, _ASM_DX);

         return ret + len;
  }
@@ -44,7 +44,7 @@ static __always_inline void *__inline_memset(void 
*addr, int v, size_t len)
                      _ASM_EXTABLE_UA(1b, 2b)
                      : "+c" (len), "+D" (addr), ASM_CALL_CONSTRAINT
                      : "a" ((uint8_t)v)
-                    : "memory", _ASM_SI);
+                    : "memory", _ASM_SI, _ASM_DX);

         return ret + len;
  }
diff --git a/arch/x86/lib/clear_page_64.S b/arch/x86/lib/clear_page_64.S
index ca94828def624..77cfd75718623 100644
--- a/arch/x86/lib/clear_page_64.S
+++ b/arch/x86/lib/clear_page_64.S
@@ -64,6 +64,7 @@ EXPORT_SYMBOL_GPL(clear_page_erms)
   *
   * Output:
   * rcx: uncleared bytes or 0 if successful.
+ * rdx: clobbered
   */
  SYM_FUNC_START(rep_stos_alternative)
         ANNOTATE_NOENDBR

Thanks,


Vegard

Re: [PATCHv7 00/16] x86: Enable Linear Address Space Separation support

[Kirill A. Shutemov]

On Thu, Jun 26, 2025 at 11:35:21AM +0200, Vegard Nossum wrote:
> 
> On 26/06/2025 11:22, Vegard Nossum wrote:
> > 
> > On 25/06/2025 14:50, Kirill A. Shutemov wrote:
> > > Linear Address Space Separation (LASS) is a security feature that
> > > intends to
> > > prevent malicious virtual address space accesses across user/kernel mode.
> > 
> > I applied these patches on top of tip/master and when I try to boot it
> > fails with errno 12 (ENOMEM - Cannot allocate memory):
> > 
> > [    1.517526] Kernel panic - not syncing: Requested init /bin/bash
> > failed (error -12).

For some reason, I failed to reproduce it. What is your toolchain?

> > Just using standard defconfig and booting in qemu/KVM with 2G RAM.
> > 
> > Bisect lands on "x86/asm: Introduce inline memcpy and memset".
> 
> I think the newly added mulq to rep_stos_alternative clobbers %rdx,

Yes, it makes sense.

> at
> least this patch fixed it for me:
> 
> diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
> index 5cd0f18a431fe..bc096526432a1 100644
> --- a/arch/x86/include/asm/string.h
> +++ b/arch/x86/include/asm/string.h
> @@ -28,7 +28,7 @@ static __always_inline void *__inline_memcpy(void *to,
> const void *from, size_t
>                      "2:\n\t"
>                      _ASM_EXTABLE_UA(1b, 2b)
>                      :"+c" (len), "+D" (to), "+S" (from),
> ASM_CALL_CONSTRAINT
> -                    : : "memory", _ASM_AX);
> +                    : : "memory", _ASM_AX, _ASM_DX);
> 
>         return ret + len;
>  }

This part is not needed. rep_movs_alternative() doesn't touch RDX.

I will fold the patch below.

Or maybe some asm guru can suggest a better way to fix it without
clobbering RDX?

diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 5cd0f18a431f..b0a26a3f11e0 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
@@ -44,7 +44,7 @@ static __always_inline void *__inline_memset(void *addr, int v, size_t len)
 		     _ASM_EXTABLE_UA(1b, 2b)
 		     : "+c" (len), "+D" (addr), ASM_CALL_CONSTRAINT
 		     : "a" ((uint8_t)v)
-		     : "memory", _ASM_SI);
+		     : "memory", _ASM_SI, _ASM_DX);
 
 	return ret + len;
 }
diff --git a/arch/x86/lib/clear_page_64.S b/arch/x86/lib/clear_page_64.S
index ca94828def62..d904c781fa3f 100644
--- a/arch/x86/lib/clear_page_64.S
+++ b/arch/x86/lib/clear_page_64.S
@@ -64,12 +64,15 @@ EXPORT_SYMBOL_GPL(clear_page_erms)
  *
  * Output:
  * rcx: uncleared bytes or 0 if successful.
+ * rdx: clobbered
  */
 SYM_FUNC_START(rep_stos_alternative)
 	ANNOTATE_NOENDBR
 
 	movzbq %al, %rsi
 	movabs $0x0101010101010101, %rax
+
+	/* %rdx:%rax = %rax * %rsi */
 	mulq %rsi
 
 	cmpq $64,%rcx
-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCHv7 00/16] x86: Enable Linear Address Space Separation support

[Vegard Nossum]

On 26/06/2025 14:47, Kirill A. Shutemov wrote:
> On Thu, Jun 26, 2025 at 11:35:21AM +0200, Vegard Nossum wrote:
>> On 26/06/2025 11:22, Vegard Nossum wrote:
>>> On 25/06/2025 14:50, Kirill A. Shutemov wrote:
>>>> Linear Address Space Separation (LASS) is a security feature that
>>>> intends to
>>>> prevent malicious virtual address space accesses across user/kernel mode.
>>>
>>> I applied these patches on top of tip/master and when I try to boot it
>>> fails with errno 12 (ENOMEM - Cannot allocate memory):
>>>
>>> [    1.517526] Kernel panic - not syncing: Requested init /bin/bash
>>> failed (error -12).
> 
> For some reason, I failed to reproduce it. What is your toolchain?

$ gcc --version
gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2.1.0.1)

I tried to diff vmlinux with and without the clobber change and I see a
bunch of changed functions, the first one I looked at is calling
put_user() -- I guess anything could be affected, really.

>> @@ -28,7 +28,7 @@ static __always_inline void *__inline_memcpy(void *to,
>> const void *from, size_t
>>                       "2:\n\t"
>>                       _ASM_EXTABLE_UA(1b, 2b)
>>                       :"+c" (len), "+D" (to), "+S" (from),
>> ASM_CALL_CONSTRAINT
>> -                    : : "memory", _ASM_AX);
>> +                    : : "memory", _ASM_AX, _ASM_DX);
>>
>>          return ret + len;
>>   }
> 
> This part is not needed. rep_movs_alternative() doesn't touch RDX.

True, I didn't look closely enough...

> I will fold the patch below.

Thanks,


Vegard

Re: [PATCHv7 00/16] x86: Enable Linear Address Space Separation support

[David Laight]

On Thu, 26 Jun 2025 15:47:36 +0300
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:

> On Thu, Jun 26, 2025 at 11:35:21AM +0200, Vegard Nossum wrote:
> > 
> > On 26/06/2025 11:22, Vegard Nossum wrote:  
> > > 
> > > On 25/06/2025 14:50, Kirill A. Shutemov wrote:  
> > > > Linear Address Space Separation (LASS) is a security feature that
> > > > intends to
> > > > prevent malicious virtual address space accesses across user/kernel mode.  
> > > 
> > > I applied these patches on top of tip/master and when I try to boot it
> > > fails with errno 12 (ENOMEM - Cannot allocate memory):
> > > 
> > > [    1.517526] Kernel panic - not syncing: Requested init /bin/bash
> > > failed (error -12).  
> 
> For some reason, I failed to reproduce it. What is your toolchain?
> 
> > > Just using standard defconfig and booting in qemu/KVM with 2G RAM.
> > > 
> > > Bisect lands on "x86/asm: Introduce inline memcpy and memset".  
> > 
> > I think the newly added mulq to rep_stos_alternative clobbers %rdx,  
> 
> Yes, it makes sense.
> 
> > at
> > least this patch fixed it for me:
> > 
> > diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
> > index 5cd0f18a431fe..bc096526432a1 100644
> > --- a/arch/x86/include/asm/string.h
> > +++ b/arch/x86/include/asm/string.h
> > @@ -28,7 +28,7 @@ static __always_inline void *__inline_memcpy(void *to,
> > const void *from, size_t
> >                      "2:\n\t"
> >                      _ASM_EXTABLE_UA(1b, 2b)
> >                      :"+c" (len), "+D" (to), "+S" (from),
> > ASM_CALL_CONSTRAINT
> > -                    : : "memory", _ASM_AX);
> > +                    : : "memory", _ASM_AX, _ASM_DX);
> > 
> >         return ret + len;
> >  }  
> 
> This part is not needed. rep_movs_alternative() doesn't touch RDX.
> 
> I will fold the patch below.
> 
> Or maybe some asm guru can suggest a better way to fix it without
> clobbering RDX?

Or separate out the code where the value is a compile-time zero.
That is pretty much 99% of the calls.

	David

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

[Peter Zijlstra]

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).

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

[Dave Hansen]

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?

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

[Kirill A. Shutemov]

On Thu, Jun 26, 2025 at 07:18:59AM -0700, Dave Hansen wrote:
> 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?

Looks good. Will update the patch.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCHv7 01/16] x86/cpu: Enumerate the LASS feature bits

[Borislav Petkov]

On Wed, Jun 25, 2025 at 03:50:53PM +0300, 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.
> 
> 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
> 
> 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/uapi/asm/processor-flags.h | 2 ++
>  arch/x86/kernel/cpu/cpuid-deps.c            | 1 +
>  tools/arch/x86/include/asm/cpufeatures.h    | 1 +
>  5 files changed, 9 insertions(+)

Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCHv7 01/16] x86/cpu: Enumerate the LASS feature bits

[Xin Li]

On 6/25/2025 5:50 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.
> 
> 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
> 
> 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/uapi/asm/processor-flags.h | 2 ++
>   arch/x86/kernel/cpu/cpuid-deps.c            | 1 +
>   tools/arch/x86/include/asm/cpufeatures.h    | 1 +
>   5 files changed, 9 insertions(+)
> 
> diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures
> index 250c10627ab3..733d5aff2456 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_32
> +
>   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 b78af55aa22e..8eef1ad7aca2 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/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 ee176236c2be..4473a6f7800b 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 */

Reviewed-by: Xin Li (Intel) <xin@zytor.com>

Re: [PATCHv7 13/16] x86/traps: Handle LASS thrown #SS

[Xin Li]

On 6/25/2025 5:51 AM, Kirill A. Shutemov wrote:
> LASS throws a #GP for any violations except for stack register accesses,
> in which case it throws a #SS instead. Handle this similarly to how other
> LASS violations are handled.
> 
> In case of FRED, before handling #SS as LASS violation, kernel has to
> check if there's a fixup for the exception. It can address #SS due to
> invalid user context on ERETU[1]. See 5105e7687ad3 ("x86/fred: Fixup

Forgot to put the link to [1]?  Maybe just remove "[1]"?

> fault on ERETU by jumping to fred_entrypoint_user") for more details.
> 
> Co-developed-by: Alexander Shishkin <alexander.shishkin@linux.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/kernel/traps.c | 39 +++++++++++++++++++++++++++++++++------
>   1 file changed, 33 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index e2ad760b17ea..f1f92e1ba524 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -418,12 +418,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present)
>   		      SIGBUS, 0, NULL);
>   }
>   
> -DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment)
> -{
> -	do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS,
> -		      0, NULL);
> -}
> -
>   DEFINE_IDTENTRY_ERRORCODE(exc_alignment_check)
>   {
>   	char *str = "alignment check";
> @@ -866,6 +860,39 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
>   	cond_local_irq_disable(regs);
>   }
>   
> +#define SSFSTR "stack segment fault"
> +
> +DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment)
> +{
> +	if (user_mode(regs))
> +		goto error_trap;
> +
> +	if (cpu_feature_enabled(X86_FEATURE_FRED) &&
> +	    fixup_exception(regs, X86_TRAP_SS, error_code, 0))
> +		return;
> +

Thanks for making the change for FRED.

> +	if (cpu_feature_enabled(X86_FEATURE_LASS)) {
> +		enum kernel_gp_hint hint;
> +		unsigned long gp_addr;
> +
> +		hint = get_kernel_gp_address(regs, &gp_addr);
> +		if (hint != GP_NO_HINT) {
> +			printk(SSFSTR ", %s 0x%lx", kernel_gp_hint_help[hint],
> +			       gp_addr);
> +		}
> +
> +		if (hint != GP_NON_CANONICAL)
> +			gp_addr = 0;

Nit: GP/gp don't seem fit here, maybe we need a more generic name?

Sorry I don't have a recommendation.

> +
> +		die_addr(SSFSTR, regs, error_code, gp_addr);
> +		return;
> +	}
> +
> +error_trap:
> +	do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS,
> +		0, NULL);

The indentation has changed; I believe the original formatting is
preferable.

> +}
> +
>   static bool do_int3(struct pt_regs *regs)
>   {
>   	int res;

Just minor comments, so

Reviewed-by: Xin Li (Intel) <xin@zytor.com>

Re: [PATCHv7 13/16] x86/traps: Handle LASS thrown #SS

[Kirill A. Shutemov]

On Thu, Jun 26, 2025 at 10:57:47AM -0700, Xin Li wrote:
> On 6/25/2025 5:51 AM, Kirill A. Shutemov wrote:
> > LASS throws a #GP for any violations except for stack register accesses,
> > in which case it throws a #SS instead. Handle this similarly to how other
> > LASS violations are handled.
> > 
> > In case of FRED, before handling #SS as LASS violation, kernel has to
> > check if there's a fixup for the exception. It can address #SS due to
> > invalid user context on ERETU[1]. See 5105e7687ad3 ("x86/fred: Fixup
> 
> Forgot to put the link to [1]?  Maybe just remove "[1]"?

I will add the link. It is important context.

> > fault on ERETU by jumping to fred_entrypoint_user") for more details.
> > 
> > Co-developed-by: Alexander Shishkin <alexander.shishkin@linux.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/kernel/traps.c | 39 +++++++++++++++++++++++++++++++++------
> >   1 file changed, 33 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > index e2ad760b17ea..f1f92e1ba524 100644
> > --- a/arch/x86/kernel/traps.c
> > +++ b/arch/x86/kernel/traps.c
> > @@ -418,12 +418,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present)
> >   		      SIGBUS, 0, NULL);
> >   }
> > -DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment)
> > -{
> > -	do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS,
> > -		      0, NULL);
> > -}
> > -
> >   DEFINE_IDTENTRY_ERRORCODE(exc_alignment_check)
> >   {
> >   	char *str = "alignment check";
> > @@ -866,6 +860,39 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
> >   	cond_local_irq_disable(regs);
> >   }
> > +#define SSFSTR "stack segment fault"
> > +
> > +DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment)
> > +{
> > +	if (user_mode(regs))
> > +		goto error_trap;
> > +
> > +	if (cpu_feature_enabled(X86_FEATURE_FRED) &&
> > +	    fixup_exception(regs, X86_TRAP_SS, error_code, 0))
> > +		return;
> > +
> 
> Thanks for making the change for FRED.
> 
> > +	if (cpu_feature_enabled(X86_FEATURE_LASS)) {
> > +		enum kernel_gp_hint hint;
> > +		unsigned long gp_addr;
> > +
> > +		hint = get_kernel_gp_address(regs, &gp_addr);
> > +		if (hint != GP_NO_HINT) {
> > +			printk(SSFSTR ", %s 0x%lx", kernel_gp_hint_help[hint],
> > +			       gp_addr);
> > +		}
> > +
> > +		if (hint != GP_NON_CANONICAL)
> > +			gp_addr = 0;
> 
> Nit: GP/gp don't seem fit here, maybe we need a more generic name?
> 
> Sorry I don't have a recommendation.

Naming is hard.

Maybe get_kernel_exc_address()/kernel_exc_hint_help/EXC_NO_HINT/... ?

> > +
> > +		die_addr(SSFSTR, regs, error_code, gp_addr);
> > +		return;
> > +	}
> > +
> > +error_trap:
> > +	do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS,
> > +		0, NULL);
> 
> The indentation has changed; I believe the original formatting is
> preferable.
> 
> > +}
> > +
> >   static bool do_int3(struct pt_regs *regs)
> >   {
> >   	int res;
> 
> Just minor comments, so
> 
> Reviewed-by: Xin Li (Intel) <xin@zytor.com>

Thanks.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCHv7 13/16] x86/traps: Handle LASS thrown #SS

[David Laight]

On Fri, 27 Jun 2025 13:31:44 +0300
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:

> On Thu, Jun 26, 2025 at 10:57:47AM -0700, Xin Li wrote:
> > On 6/25/2025 5:51 AM, Kirill A. Shutemov wrote:  
> > > LASS throws a #GP for any violations except for stack register accesses,
> > > in which case it throws a #SS instead. Handle this similarly to how other
> > > LASS violations are handled.
> > > 
> > > In case of FRED, before handling #SS as LASS violation, kernel has to
> > > check if there's a fixup for the exception. It can address #SS due to
> > > invalid user context on ERETU[1]. See 5105e7687ad3 ("x86/fred: Fixup  
> > 
> > Forgot to put the link to [1]?  Maybe just remove "[1]"?  
> 
> I will add the link. It is important context.

Will the link still be valid in 5 years time when someone
is looking back at the changes?

	David

Re: [PATCHv7 13/16] x86/traps: Handle LASS thrown #SS

[Kirill A. Shutemov]

On Mon, Jun 30, 2025 at 09:30:27AM +0100, David Laight wrote:
> On Fri, 27 Jun 2025 13:31:44 +0300
> "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> 
> > On Thu, Jun 26, 2025 at 10:57:47AM -0700, Xin Li wrote:
> > > On 6/25/2025 5:51 AM, Kirill A. Shutemov wrote:  
> > > > LASS throws a #GP for any violations except for stack register accesses,
> > > > in which case it throws a #SS instead. Handle this similarly to how other
> > > > LASS violations are handled.
> > > > 
> > > > In case of FRED, before handling #SS as LASS violation, kernel has to
> > > > check if there's a fixup for the exception. It can address #SS due to
> > > > invalid user context on ERETU[1]. See 5105e7687ad3 ("x86/fred: Fixup  
> > > 
> > > Forgot to put the link to [1]?  Maybe just remove "[1]"?  
> > 
> > I will add the link. It is important context.
> 
> Will the link still be valid in 5 years time when someone
> is looking back at the changes?

Re-reading the commit message I wrote, it is obvious that I reconsidered
putting the link and referenced commit instead.

I will drop [1];

-- 
  Kiryl Shutsemau / Kirill A. Shutemov