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: <CAMj1kXEHpezZS_jNoLQoTSKXZ0P8DxQFHNKRS2kkTC-G4MfG0w@mail.gmail.com>
Date: Mon, 1 Jul 2024 15:27:15 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-efi@...r.kernel.org, x86@...nel.org, 
	linux-kernel@...r.kernel.org, dyoung@...hat.com, 
	Dan Williams <dan.j.williams@...el.com>
Subject: Re: [RFC PATCH] x86/efi: Drop support for fake EFI memory maps

On Mon, 1 Jul 2024 at 14:47, Borislav Petkov <bp@...en8.de> wrote:
>
> On Thu, Jun 20, 2024 at 09:32:05AM +0200, 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.
> >
> > 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@...fujitsu.com>
> > Cc: Dan Williams <dan.j.williams@...el.com>
> > Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> > ---
> >  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@...en8.de>
>
> 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.