linux-kernel - Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

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]

Date:	Wed, 8 Jun 2016 13:36:23 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Joseph Thelen <jthelen@....com>
Cc:	linux-kernel@...r.kernel.org, Alex Thorlton <athorlton@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-efi@...r.kernel.org, Linn Crosetto <linn@....com>,
	Peter Jones <pjones@...hat.com>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

(Cc'ing people familiar with e820 map woes)

On Thu, 02 Jun, at 03:50:35PM, Joseph Thelen wrote:
> Currently, the EFI memory map entries are disabled by default and must
> be enabled by passing the kernel boot option:
> 
> add_efi_memmap
> 
> The EFI memory map entries should be enabled on systems with more
> than 128 E820 entries, which includes many UV systems. Check if
> we're on a UV system by chekcing the uv system table.
> Enable the EFI memory map entries if we're on a UV system.
> 
> This change is backward compatible because the EFI memory map entries are
> still disabled by default on non-UV systems, and it maintains the previous
> behavior of the kernel boot option. In addition, it allows the EFI memory
> map entries to be explicitly disabled (will not be automatically enabled)
> by setting the add_efi_memmap boot option to anything that kstringtobool
> will determine to be false.
> 
> Signed-off-by: Joseph Thelen <jthelen@....com>
> Cc: Alex Thorlton <athorlton@....com>
> Cc: Matt Fleming <matt@...eblueprint.co.uk>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: x86@...nel.org
> Cc: linux-efi@...r.kernel.org
> ---
>  arch/x86/platform/efi/efi.c | 43 +++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 39 insertions(+), 4 deletions(-)
 
What's the ultimate goal here? To not require that users specify the
add_efi_memmap kernel parameter in the future? Presumably they do
today?

FYI, a lot of non-UV systems have more than 128 entries and the way we
handle it is by using the SETUP_E820_EXT setup_data entry in
boot_params in the EFI boot stub (I don't think boot loaders use it
because they largely go via the stub anyhow).

So if you've got control over your boot loader, and assuming SGI UV
systems don't boot using the EFI boot stub, you could look at adding
boot loader support for SETUP_E820_EXT to force enable > 128 entries
automatically without any new kernel code.