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 <yian.chen@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
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.1The 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
© 2016 - 2025 Red Hat, Inc.