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 <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
---
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 <[email protected]>
> Reviewed-by: Tony Luck <[email protected]>
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 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 <[email protected]>
>> Reviewed-by: Tony Luck <[email protected]>
>
Thanks,
Yian
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