linux-kernel - Re: [PATCH 0/3] x86: Extend LASS support to EFI configurations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXFicnmVUeoRsMNbBgDN20fCN+R01H9shcgOJMD2Nzn8Cg@mail.gmail.com>
Date: Thu, 4 Dec 2025 13:47:28 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Sohil Mehta <sohil.mehta@...el.com>
Cc: x86@...nel.org, Dave Hansen <dave.hansen@...ux.intel.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	"H . Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Kiryl Shutsemau <kas@...nel.org>, Rick Edgecombe <rick.p.edgecombe@...el.com>, 
	Andrew Cooper <andrew.cooper3@...rix.com>, Tony Luck <tony.luck@...el.com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, linux-kernel@...r.kernel.org, 
	linux-efi@...r.kernel.org
Subject: Re: [PATCH 0/3] x86: Extend LASS support to EFI configurations

Hello Sohil,

On Thu, 4 Dec 2025 at 08:23, Sohil Mehta <sohil.mehta@...el.com> wrote:
>
> Linear Address Space Separation (LASS) is currently disabled [1] when
> support for vsyscall emulation or EFI is compiled in. This series
> extends LASS support to EFI-enabled configurations.
>
> Issues with EFI
> ---------------
> EFI boot and runtime services are incompatible with LASS because they
> end up accessing addresses with bit 63 cleared, which is blocked by LASS.
>
>   1) The most obvious one is the SetVirtualAddressMap() runtime service,
>   which is expected to be called in EFI physical mode [2].
>
>   2) Boot services code and data are referenced long after
>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
>   accesses boot services memory even after SetVirtualAddressMap().
>

These accesses use the kernel direct map, so I don't think they come
into play here.

>   3) Some runtime services fail to switch to virtual mode properly and
>   continue referencing physical addresses [3]. The kernel maintains a
>   1:1 mapping of all runtime services code and data regions to avoid
>   breaking such firmware.
>

In [3], I mainly elaborated on why it is still necessary to call
SetVirtualAddressMap(), and why it needs to be called with a mapping
in the upper address range.

For this particular call, there is no choice but to disarm LASS, given
that the lower mapping is still active at this point.

However, that does not imply that we have to assume that systems that
support LASS (which are fairly recent AIUI) are buggy in the same way,
i.e., that they access addresses in the 1:1 region after
SetVirtualAddressMap() completes.

In fact, we might attempt to use the availability of LASS as a
preliminary cutoff point for disabling this hack entirely, and only
backpedal if we get actual reports where this is still a problem. Note
that even if it is true that many PC vendors typically only test their
systems with Windows, its security posture has improved considerably
in recent years, and I wouldn't be surprised if such firmware bugs now
cause problems with Windows as well.