LASS (Linear Address Space Separation) is a CPU feature to
prevent speculative address access in user/kernel mode.

LASS partitions 64-bit virtual address space into two
halves, lower address (LA[63]=0) and upper address
(LA[63]=1). It stops any data access or code execution
    1. from upper half address space to any lower half address
    2, from lower half address space to any upper half address
and generates #GP fault for a violation.

In Linux, this means LASS does not allow both kernel code
to access any user space address and user code to access
any kernel space address.

Signed-off-by: Yian Chen <yian.chen@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/include/asm/cpufeatures.h          | 1 +
 arch/x86/include/uapi/asm/processor-flags.h | 2 ++
 tools/arch/x86/include/asm/cpufeatures.h    | 1 +
 3 files changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 61012476d66e..03b375db026b 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -311,6 +311,7 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */
 #define X86_FEATURE_AVX_VNNI		(12*32+ 4) /* AVX VNNI instructions */
 #define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* AVX512 BFLOAT16 instructions */
+#define X86_FEATURE_LASS		(12*32+ 6) /* Linear address space separation */
 #define X86_FEATURE_CMPCCXADD           (12*32+ 7) /* "" CMPccXADD instructions */
 #define X86_FEATURE_AMX_FP16		(12*32+21) /* "" AMX fp16 Support */
 #define X86_FEATURE_AVX_IFMA            (12*32+23) /* "" Support for VPMADD52[H,L]UQ */
diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include/uapi/asm/processor-flags.h
index c47cc7f2feeb..fd84ea8240fc 100644
--- a/arch/x86/include/uapi/asm/processor-flags.h
+++ b/arch/x86/include/uapi/asm/processor-flags.h
@@ -132,6 +132,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 LASS support */
+#define X86_CR4_LASS		_BITUL(X86_CR4_LASS_BIT)
 
 /*
  * x86-64 Task Priority Register, CR8
diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/include/asm/cpufeatures.h
index 61012476d66e..03b375db026b 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -311,6 +311,7 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */
 #define X86_FEATURE_AVX_VNNI		(12*32+ 4) /* AVX VNNI instructions */
 #define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* AVX512 BFLOAT16 instructions */
+#define X86_FEATURE_LASS		(12*32+ 6) /* Linear address space separation */
 #define X86_FEATURE_CMPCCXADD           (12*32+ 7) /* "" CMPccXADD instructions */
 #define X86_FEATURE_AMX_FP16		(12*32+21) /* "" AMX fp16 Support */
 #define X86_FEATURE_AVX_IFMA            (12*32+23) /* "" Support for VPMADD52[H,L]UQ */
-- 
2.34.1

On 1/9/2023 9:51 PM, Yian Chen wrote:
> LASS (Linear Address Space Separation) is a CPU feature to
> prevent speculative address access in user/kernel mode.
> 

Would it be better to say?

LASS (Linear Address Space Separation) is a security feature that 
intends to prevent unintentional speculative address access across 
user/kernel mode.


> LASS partitions 64-bit virtual address space into two
> halves, lower address (LA[63]=0) and upper address
> (LA[63]=1). It stops any data access or code execution
>      1. from upper half address space to any lower half address
>      2, from lower half address space to any upper half address
> and generates #GP fault for a violation.
> 

I am not sure if this is the best way to say it. The kernel already 
partitions the address space this way. LASS takes what is already the 
typical OS implementation and bakes it into the hardware architecture.

> In Linux, this means LASS does not allow both kernel code
> to access any user space address and user code to access
> any kernel space address.
> 

There is clearly an overlap between the protections provided by paging 
and with SMAP and SMEP. It would be useful to paraphrase some of the 
information mentioned in the spec regarding how LASS differs from them.

"With these mode-based protections, paging can prevent malicious 
software from directly reading or writing memory inappropriately. To 
enforce these protections, the processor must traverse the hierarchy of 
paging structures in memory. Unprivileged software can use timing 
information resulting from this traversal to determine details about the 
paging structures, and these details may be used to determine the layout 
of supervisor memory.

Linear-address space separation (LASS) is an independent mechanism that 
enforces the same mode-based protections as paging but without 
traversing the paging structures. Because the protections enforced by 
LASS are applied before paging, “probes” by malicious software will 
provide no paging-based timing information."

> Signed-off-by: Yian Chen <yian.chen@intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>

On 1/10/2023 12:14 PM, Sohil Mehta wrote:
> On 1/9/2023 9:51 PM, Yian Chen wrote:
>> LASS (Linear Address Space Separation) is a CPU feature to
>> prevent speculative address access in user/kernel mode.
>>
> 
> Would it be better to say?
> 
> LASS (Linear Address Space Separation) is a security feature that 
> intends to prevent unintentional speculative address access across 
> user/kernel mode.
> 
>
Sure, I will revise the statement precisely.

>> LASS partitions 64-bit virtual address space into two
>> halves, lower address (LA[63]=0) and upper address
>> (LA[63]=1). It stops any data access or code execution
>>      1. from upper half address space to any lower half address
>>      2, from lower half address space to any upper half address
>> and generates #GP fault for a violation.
>>
> 
> I am not sure if this is the best way to say it. The kernel already 
> partitions the address space this way. LASS takes what is already the 
> typical OS implementation and bakes it into the hardware architecture.
> 
Yes, LASS by design matches the addressing usage in OS. I will try to 
include this in the statement.
>> In Linux, this means LASS does not allow both kernel code
>> to access any user space address and user code to access
>> any kernel space address.
>>
> 
> There is clearly an overlap between the protections provided by paging 
> and with SMAP and SMEP. It would be useful to paraphrase some of the 
> information mentioned in the spec regarding how LASS differs from them.
> 
Yes, I will differentiate between LASS and SMAP more clearly.

> "With these mode-based protections, paging can prevent malicious 
> software from directly reading or writing memory inappropriately. To 
> enforce these protections, the processor must traverse the hierarchy of 
> paging structures in memory. Unprivileged software can use timing 
> information resulting from this traversal to determine details about the 
> paging structures, and these details may be used to determine the layout 
> of supervisor memory.
> 
> Linear-address space separation (LASS) is an independent mechanism that 
> enforces the same mode-based protections as paging but without 
> traversing the paging structures. Because the protections enforced by 
> LASS are applied before paging, “probes” by malicious software will 
> provide no paging-based timing information."
> 
Yes, I will also state the advantage of LASS.

>> Signed-off-by: Yian Chen <yian.chen@intel.com>
>> Reviewed-by: Tony Luck <tony.luck@intel.com>
> 

Thanks,
Yian

On 1/10/23 12:14, Sohil Mehta wrote:
> On 1/9/2023 9:51 PM, Yian Chen wrote:
>> LASS (Linear Address Space Separation) is a CPU feature to
>> prevent speculative address access in user/kernel mode.
> 
> Would it be better to say?
> 
> LASS (Linear Address Space Separation) is a security feature that
> intends to prevent unintentional speculative address access across
> user/kernel mode.

It's more than that, though.  The spec actually says this pretty nicely:

> Linear-address space separation (LASS) is an independent mechanism
> that enforces the same mode-based protections as paging but without
> traversing the paging structures. Because the protections enforced by
> LASS are applied before paging, “probes” by malicious software will
> provide no paging-based timing information

So, it's not _just_ that it can prevent some speculative accesses.  It
completely short-circuits paging itself and *ALL* of the baggage that
goes along with paging.

The TLB, mid-level caches, the page walker itself, the data cache
impact...  all of it.  Gone.

*THAT* is the important part here, IMNHO.

On 1/10/2023 4:13 PM, Dave Hansen wrote:
> On 1/10/23 12:14, Sohil Mehta wrote:
>> On 1/9/2023 9:51 PM, Yian Chen wrote:
>>> LASS (Linear Address Space Separation) is a CPU feature to
>>> prevent speculative address access in user/kernel mode.
>>
>> Would it be better to say?
>>
>> LASS (Linear Address Space Separation) is a security feature that
>> intends to prevent unintentional speculative address access across
>> user/kernel mode.
> 
> It's more than that, though.  The spec actually says this pretty nicely:
> >> Linear-address space separation (LASS) is an independent mechanism
>> that enforces the same mode-based protections as paging but without
>> traversing the paging structures. Because the protections enforced by
>> LASS are applied before paging, “probes” by malicious software will
>> provide no paging-based timing information
> 
> So, it's not _just_ that it can prevent some speculative accesses.  It
> completely short-circuits paging itself and *ALL* of the baggage that
> goes along with paging.
> 
> The TLB, mid-level caches, the page walker itself, the data cache
> impact...  all of it.  Gone.
> 
> *THAT* is the important part here, IMNHO.
sure, how about if I rewrite the 1st paragraph as follows:

LASS (Linear Address Space Separation) is an independent security 
mechanism that enforces kernel and user mode-base protections, similar 
to Intel SMAP/SMEP in kernel mode, but enhanced without traversing the 
paging structures. Therefore, the protection will not leak paging-based 
timing information and prevent malicious software from probing the info. 
The LASS details have been published in Chapter 11 in
https://cdrdv2.intel.com/v1/dl/getContent/671368

> The LASS details have been published in Chapter 11 in
> https://cdrdv2.intel.com/v1/dl/getContent/671368

Intel is terrible about maintaining web URLs like this. Better to
give this reference as:

  The December 2022 edition of the Intel Architecture
  Instruction Set Extensions and Future Features Programming
  Reference manual.

Maybe also still give the URL in a reply like this, but avoid using
It in a commit message that will be preserved forever.

-Tony

On 1/11/2023 4:06 PM, Luck, Tony wrote:
>> The LASS details have been published in Chapter 11 in
>> https://cdrdv2.intel.com/v1/dl/getContent/671368
> 
> Intel is terrible about maintaining web URLs like this. Better to
> give this reference as:
> 
>    The December 2022 edition of the Intel Architecture
>    Instruction Set Extensions and Future Features Programming
>    Reference manual.
> 
> Maybe also still give the URL in a reply like this, but avoid using
> It in a commit message that will be preserved forever.
> 
Sure, I will add the detail document name and versioning info.

> -Tony
> 

Thanks,
Yian