linux-kernel - Re: [RFC PATCH] x86/efi: Drop support for fake EFI memory maps

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: <66830ebdb7f0e_5639294f5@dwillia2-xfh.jf.intel.com.notmuch>
Date: Mon, 1 Jul 2024 13:17:01 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Ard Biesheuvel <ardb+git@...gle.com>, <linux-efi@...r.kernel.org>
CC: <x86@...nel.org>, <linux-kernel@...r.kernel.org>, <dyoung@...hat.com>, Dan
 Williams <dan.j.williams@...el.com>, Ard Biesheuvel <ardb@...nel.org>,
	<tony.luck@...el.com>
Subject: Re: [RFC PATCH] x86/efi: Drop support for fake EFI memory maps

[ add Tony who may care about the more-reliable removal ]

Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@...nel.org>
> 
> Between kexec and confidential VM support, handling the EFI memory maps
> correctly on x86 is already proving to be rather difficult (as opposed
> to other EFI architectures which manage to never modify the EFI memory
> map to begin with)
> 
> EFI fake memory map support is essentially a development hack (for
> testing new support for the 'special purpose' and 'more reliable' EFI
> memory attributes) that leaked into production code. The regions marked
> in this manner are not actually recognized as such by the firmware
> itself or the EFI stub (and never have), and marking memory as 'more
> reliable' seems rather futile if the underlying memory is just ordinary
> RAM.
> 
> Marking memory as 'special purpose' in this way is also dubious, but may
> be in use in production code nonetheless. However, the same should be
> achievable by using the memmap= command line option with the ! operator.

Ugh, sorry I missed this earlier. I only now just saw this bubble up in
my inbox from the reply from Boris, but I have concerns with this
removal.

The problem is that what is and is not "special purpose" is a platform
*and* use case policy. BIOS can only make a rough guess at platform
manufacturing time, and certainly does not have use case information.

One of the main reasons to prefer efi_fake_mem over memmap= is all of
the end user hand holding needed to correct broken usage of memmap=

https://nvdimm.wiki.kernel.org/how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system

...if anything I have been wanting to rip out memmap= more than
efi_fake_mem just to cut down on the PEBKAC reports from memmap= users
from the PMEM days. Those reports only died down because Optane died,
but CXL is here now to revive that "fun".

However, that said, maybe the safety properties of
efi_fake_mem=nn@ss:0x40000 can be brought over to memmap=. The main
property that protects end users is that the attribute only applies to
existing EFI Conventional Memory ranges. So unlike memmap= that blindly
replaces the memory map whether it makes sense or not, efi_fake_mem=
would fail gracefully if the attribute was applied to nonsense ranges.

> EFI fake memmap support is not enabled by any of the major distros
> (Debian, Fedora, SUSE, Ubuntu) and does not exist on other
> architectures, so let's drop support for it.

I think part of the problem here is that platform with differentiated
memory, (PMEM, HBM, CXL, etc...) have remained somewhat boutique since
the introduction of this facility. As they become more ubiquitous, as
trends seem to indicate, I think the frustration with BIOS policy may
become more widespread.

So we can remove it and see who screams, but we may want to put a
work-alike safe option in memmap= first just to keep our own sanity.