On Mon, 1 Jul 2024 at 14:47, Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Thu, Jun 20, 2024 at 09:32:05AM +0200, Ard Biesheuvel wrote: > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > 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. > > > > 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. > > > > Cc: Taku Izumi <izumi.taku@xxxxxxxxxxxxxx> > > Cc: Dan Williams <dan.j.williams@xxxxxxxxx> > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > --- > > Documentation/admin-guide/kernel-parameters.txt | 21 --- > > arch/x86/Kconfig | 20 -- > > arch/x86/boot/compressed/kaslr.c | 43 +---- > > arch/x86/include/asm/efi.h | 15 -- > > arch/x86/kernel/setup.c | 1 - > > arch/x86/platform/efi/efi.c | 2 - > > arch/x86/platform/efi/fake_mem.c | 197 -------------------- > > arch/x86/platform/efi/memmap.c | 1 + > > drivers/firmware/efi/libstub/x86-stub.c | 2 +- > > 9 files changed, 11 insertions(+), 291 deletions(-) > > I obviously like this: > > Acked-by: Borislav Petkov (AMD) <bp@xxxxxxxxx> > > I don't see the author or anyone else objecting, I guess queue it? > Thanks. > Or if you feel like you wanna give folks a full cycle, you could queue it for > the next MW... > It's been in -next for ~10 days so I might just send it for the next cycle. We can always revert it if something gets broken.
