LASS is an Intel x86-64 only feature. Add CONFIG
option X86_LASS and flag DISABLE_LASS to choose
opt-in/out the feature from kernel binary.
CONFIG_X86_LASS is enabled by default because it
is a security feature which should have little
to no overhead or side effects. If any issues are
found with specific use cases, the CONFIG option
makes it easy to disable.
Signed-off-by: Yian Chen <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
---
arch/x86/Kconfig | 10 ++++++++++
arch/x86/include/asm/disabled-features.h | 8 +++++++-
tools/arch/x86/include/asm/disabled-features.h | 8 +++++++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3604074a878b..38b1497afd75 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1826,6 +1826,16 @@ config ARCH_USES_PG_UNCACHED
def_bool y
depends on X86_PAT
+config X86_LASS
+ def_bool y
+ prompt "Linear Address Space Separation"
+ depends on X86_64 && CPU_SUP_INTEL
+ help
+ Linear Address Space Separation (LASS) is a processor
+ feature that mitigates address space layout probes.
+
+ if unsure, say Y.
+
config X86_UMIP
def_bool y
prompt "User Mode Instruction Prevention" if EXPERT
diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h
index c44b56f7ffba..0cad37d59e0f 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -16,6 +16,12 @@
# define DISABLE_UMIP (1<<(X86_FEATURE_UMIP & 31))
#endif
+#ifdef CONFIG_X86_LASS
+# define DISABLE_LASS 0
+#else
+# define DISABLE_LASS (1<<(X86_FEATURE_LASS & 31))
+#endif
+
#ifdef CONFIG_X86_64
# define DISABLE_VME (1<<(X86_FEATURE_VME & 31))
# define DISABLE_K6_MTRR (1<<(X86_FEATURE_K6_MTRR & 31))
@@ -115,7 +121,7 @@
#define DISABLED_MASK10 0
#define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \
DISABLE_CALL_DEPTH_TRACKING)
-#define DISABLED_MASK12 0
+#define DISABLED_MASK12 (DISABLE_LASS)
#define DISABLED_MASK13 0
#define DISABLED_MASK14 0
#define DISABLED_MASK15 0
diff --git a/tools/arch/x86/include/asm/disabled-features.h b/tools/arch/x86/include/asm/disabled-features.h
index c44b56f7ffba..0cad37d59e0f 100644
--- a/tools/arch/x86/include/asm/disabled-features.h
+++ b/tools/arch/x86/include/asm/disabled-features.h
@@ -16,6 +16,12 @@
# define DISABLE_UMIP (1<<(X86_FEATURE_UMIP & 31))
#endif
+#ifdef CONFIG_X86_LASS
+# define DISABLE_LASS 0
+#else
+# define DISABLE_LASS (1<<(X86_FEATURE_LASS & 31))
+#endif
+
#ifdef CONFIG_X86_64
# define DISABLE_VME (1<<(X86_FEATURE_VME & 31))
# define DISABLE_K6_MTRR (1<<(X86_FEATURE_K6_MTRR & 31))
@@ -115,7 +121,7 @@
#define DISABLED_MASK10 0
#define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \
DISABLE_CALL_DEPTH_TRACKING)
-#define DISABLED_MASK12 0
+#define DISABLED_MASK12 (DISABLE_LASS)
#define DISABLED_MASK13 0
#define DISABLED_MASK14 0
#define DISABLED_MASK15 0
--
2.34.1
The subject can be better stated as:
x86/Kconfig: Add config option for LASS
On 1/9/2023 9:51 PM, Yian Chen wrote:
> LASS is an Intel x86-64 only feature.
> Add CONFIG
> option X86_LASS and flag DISABLE_LASS to choose
> opt-in/out the feature from kernel binary.
> The second sentence is unnecessary.
> CONFIG_X86_LASS is enabled by default because it
> is a security feature which should have little
> to no overhead or side effects.
Doesn't it have a side effect that it modifies default vsyscall behavior?
I am guessing the impact of the vsyscall change would be minimal.
However, should LASS be disabled by default at least initially to
minimize the impact on userspace?
A follow-up patch can then enable this by default once the overall
impact is clearly known.
> If any issues are
> found with specific use cases, the CONFIG option
> makes it easy to disable.
>This sentence is unnecessary.
>
> +config X86_LASS
> + def_bool y
> + prompt "Linear Address Space Separation"
> + depends on X86_64 && CPU_SUP_INTEL
> + help
> + Linear Address Space Separation (LASS) is a processor
> + feature that mitigates address space layout probes.
> +
Let's try to be consistent about what LASS is expected to do. This
definition is very different from the one in patch 1/7.
Also, we should include some information here on how enabling the LASS
config option can impact vsyscall behavior.
> + if unsure, say Y.
> +
On 1/10/2023 1:05 PM, Sohil Mehta wrote:
> The subject can be better stated as:
>
> x86/Kconfig: Add config option for LASS
>
> On 1/9/2023 9:51 PM, Yian Chen wrote:
>> LASS is an Intel x86-64 only feature.
>
>> Add CONFIG
>> option X86_LASS and flag DISABLE_LASS to choose
>> opt-in/out the feature from kernel binary.
>> The second sentence is unnecessary.
>
Sure, It makes sense to remove unnecessary sentence here.
>> CONFIG_X86_LASS is enabled by default because it
>> is a security feature which should have little
>> to no overhead or side effects.
>
> Doesn't it have a side effect that it modifies default vsyscall behavior?
>
> I am guessing the impact of the vsyscall change would be minimal.
> However, should LASS be disabled by default at least initially to
> minimize the impact on userspace?
>
> A follow-up patch can then enable this by default once the overall
> impact is clearly known.
>
>> If any issues are
>> found with specific use cases, the CONFIG option
>> makes it easy to disable.
>> This sentence is unnecessary.
>
sure, I will remove this state too.
>> +config X86_LASS
>> + def_bool y
>> + prompt "Linear Address Space Separation"
>> + depends on X86_64 && CPU_SUP_INTEL
>> + help
>> + Linear Address Space Separation (LASS) is a processor
>> + feature that mitigates address space layout probes.
>> +
>
> Let's try to be consistent about what LASS is expected to do. This
> definition is very different from the one in patch 1/7.
>
> Also, we should include some information here on how enabling the LASS
> config option can impact vsyscall behavior.
>
Sure, I will rewrite this help message and explain the impact to legacy
vsyscall as well.
>> + if unsure, say Y.
>> +
>
thanks,
Yian