linux-kernel - Re: [PATCH v11 4/9] x86/alternatives: Disable LASS when patching kernel code

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: <6ab6e4d3-0caa-41e6-8231-2f3f45949876@intel.com>
Date: Wed, 12 Nov 2025 08:18:20 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Ard Biesheuvel <ardb@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
CC: Dave Hansen <dave.hansen@...el.com>, <x86@...nel.org>, Borislav Petkov
	<bp@...en8.de>, Jonathan Corbet <corbet@....net>, Andy Lutomirski
	<luto@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra
	<peterz@...radead.org>, "Kirill A . Shutemov" <kas@...nel.org>, Xin Li
	<xin@...or.com>, David Woodhouse <dwmw@...zon.co.uk>, Sean Christopherson
	<seanjc@...gle.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, "Vegard
 Nossum" <vegard.nossum@...cle.com>, Andrew Cooper
	<andrew.cooper3@...rix.com>, Randy Dunlap <rdunlap@...radead.org>, Geert
 Uytterhoeven <geert@...ux-m68k.org>, Kees Cook <kees@...nel.org>, Tony Luck
	<tony.luck@...el.com>, Alexander Shishkin
	<alexander.shishkin@...ux.intel.com>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-efi@...r.kernel.org>, Dave Hansen
	<dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, "Ingo
 Molnar" <mingo@...hat.com>
Subject: Re: [PATCH v11 4/9] x86/alternatives: Disable LASS when patching
 kernel code

On 11/12/2025 7:28 AM, Ard Biesheuvel wrote:

>>> d) calling SetVirtualAddressMap() does not result in all 1:1
>>> references being converted to the new mapping.
>>>
>>>
>>> To address d), the x86_64 implementation of efi_map_region() indeed
>>> maps an 1:1 alias of each remapped runtime regions, so that stray
>>> accesses don't fault. But the code addresses are all remapped, and so
>>> the firmware routines are always invoked via their remapped aliases in
>>> the kernel VA space. Not calling SetVirtualAddressMap() at all, or
>>> calling it with a 1:1 mapping is not feasible, essentially because
>>> Windows doesn't do that, and that is the only thing that is tested on
>>> all x86 PCs by the respective OEMs.
>>>
>>> Given that remapping the code is dealt with by the firmware's PE/COFF
>>> loader, whereas remapping [dynamically allocated] data requires effort
>>> on the part of the programmer, I'd hazard a guess that 99.9% of those
>>> bugs do not involve attempts to execute via the lower mapping, but
>>> stray references to data objects that were not remapped properly.
>>>
>>> So we might consider
>>> a) remapping those 1:1 aliases NX, so we don't have those patches of
>>> RWX memory around
>>> b) keeping LASS enabled during ordinary EFI runtime calls, as you suggest.
>>
>> Unless someone has a code pointer in their code.
> 
> That is a good point, especially because the EFI universe is
> constructed out of GUIDs and so-called protocols, which are just
> structs with function pointers.
> 
> However, EFI protocols are only supported at boot time, and the
> runtime execution context is much more restricted. So I'd still expect
> the code pointer case to be much less likely.

But, that still leaves the stray data accesses. We would still need to
disable the LASS data access enforcement by toggling RFLAGS.AC during
the runtime calls.

Can we rely on EFI to not mess up RFLAGS and keep the AC bit intact?