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/[email protected]/
Cc: [email protected] # v6.4+
Signed-off-by: Pawan Gupta <[email protected]>
---
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.1
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/[email protected]/
>
> Cc: [email protected] # v6.4+
> Signed-off-by: Pawan Gupta <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
--
Kiryl Shutsemau / Kirill A. Shutemov
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.
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 07:58:28AM +0300, [email protected] 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/[email protected]/
> >
> > Cc: [email protected] # v6.4+
> > Signed-off-by: Pawan Gupta <[email protected]>
>
> Acked-by: Kirill A. Shutemov <[email protected]>
Thanks.
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 <[email protected]>
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 <[email protected]>
Thanks