arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+)
Intel feature Linear Address Masking (LAM) has a weakness related to
transient execution as described in the SLAM paper[1]. Unless Linear
Address Space Separation (LASS) is enabled this weakness may be
exploitable.
Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST,
or when speculation mitigations have been disabled at compile time,
otherwise keep LAM disabled.
[1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf
[2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/
Cc: stable@vger.kernel.org # v6.4+
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1566748f16c4..794517df8068 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2270,6 +2270,7 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
config ADDRESS_MASKING
bool "Linear Address Masking support"
depends on X86_64
+ depends on COMPILE_TEST || !SPECULATION_MITIGATIONS # wait for LASS
help
Linear Address Masking (LAM) modifies the checking that is applied
to 64-bit linear addresses, allowing software to use of the
base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
--
2.34.1Hi Pawan, On 1/18/2024 6:35 PM, Pawan Gupta wrote: > arch/x86/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 1566748f16c4..794517df8068 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2270,6 +2270,7 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING > config ADDRESS_MASKING > bool "Linear Address Masking support" > depends on X86_64 > + depends on COMPILE_TEST || !SPECULATION_MITIGATIONS # wait for LASS I was wondering if the COMPILE_TEST dependency here is a bit redundant. Having ADDRESS_MASKING depend on just !SPECULATION_MITIGATIONS might be enough to get the LAM code compile tested through various configurations. I don't have a strong preference here. Mainly looking to understand the reasoning. Other than that the patch looks fine to me. Sohil > help > Linear Address Masking (LAM) modifies the checking that is applied > to 64-bit linear addresses, allowing software to use of the
On Fri, Jan 19, 2024 at 09:48:14AM -0800, Sohil Mehta wrote: > Hi Pawan, > > On 1/18/2024 6:35 PM, Pawan Gupta wrote: > > arch/x86/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 1566748f16c4..794517df8068 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -2270,6 +2270,7 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING > > config ADDRESS_MASKING > > bool "Linear Address Masking support" > > depends on X86_64 > > + depends on COMPILE_TEST || !SPECULATION_MITIGATIONS # wait for LASS > > I was wondering if the COMPILE_TEST dependency here is a bit redundant. > > Having ADDRESS_MASKING depend on just !SPECULATION_MITIGATIONS might be > enough to get the LAM code compile tested through various configurations. > > I don't have a strong preference here. Mainly looking to understand the > reasoning. Other than that the patch looks fine to me. The goal is to compile test it whenever possible. As SPECULATION_MITIGATIONS are ON by default, it wont get tested for most configuration.
On 1/19/2024 8:21 AM, Pawan Gupta wrote: > The goal is to compile test it whenever possible. As > SPECULATION_MITIGATIONS are ON by default, it wont get tested for most > configuration. Sure, that would help increase the compile coverage. I wasn't sure how much of a difference it would make. Anyways, the restriction is expected to be short lived until LASS is available. Please feel free to add: Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
On Fri, Jan 19, 2024 at 03:36:22PM -0800, Sohil Mehta wrote: > On 1/19/2024 8:21 AM, Pawan Gupta wrote: > > > The goal is to compile test it whenever possible. As > > SPECULATION_MITIGATIONS are ON by default, it wont get tested for most > > configuration. > > Sure, that would help increase the compile coverage. I wasn't sure how > much of a difference it would make. Anyways, the restriction is expected > to be short lived until LASS is available. True. > Please feel free to add: > Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Thanks
On Thu, Jan 18, 2024 at 06:35:47PM -0800, Pawan Gupta wrote: > Intel feature Linear Address Masking (LAM) has a weakness related to > transient execution as described in the SLAM paper[1]. Unless Linear > Address Space Separation (LASS) is enabled this weakness may be > exploitable. > > Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, > or when speculation mitigations have been disabled at compile time, > otherwise keep LAM disabled. > It worth adding that there's no HW on market that supports LAM, so nobody affected by the issue. > [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf > [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ > > Cc: stable@vger.kernel.org # v6.4+ > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> -- Kiryl Shutsemau / Kirill A. Shutemov
On Fri, Jan 19, 2024 at 07:58:28AM +0300, kirill.shutemov@linux.intel.com wrote: > On Thu, Jan 18, 2024 at 06:35:47PM -0800, Pawan Gupta wrote: > > Intel feature Linear Address Masking (LAM) has a weakness related to > > transient execution as described in the SLAM paper[1]. Unless Linear > > Address Space Separation (LASS) is enabled this weakness may be > > exploitable. > > > > Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, > > or when speculation mitigations have been disabled at compile time, > > otherwise keep LAM disabled. > > > > It worth adding that there's no HW on market that supports LAM, so nobody > affected by the issue. Right. > > [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf > > [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ > > > > Cc: stable@vger.kernel.org # v6.4+ > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> > > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Thanks.
© 2016 - 2025 Red Hat, Inc.