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

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?

Or if you feel like you wanna give folks a full cycle, you could queue it for
the next MW...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ