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:	Tue, 14 Jun 2016 17:34:49 -0500
From:	Joseph Thelen <jthelen@....com>
To:	Matt Fleming <matt@...eblueprint.co.uk>
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>,
	Joseph Thelen <jthelen@....com>
Subject: Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

On Wed, Jun 08, 2016 at 01:36:23PM +0100, Matt Fleming wrote:
> (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.

We're still reasonably confident we'll need something like this. Although,
after looking into the stuff you mention, it seems that it should perhaps
be a bit more sophisticated than just checking if we're on a UV system.

We'll get back to you after digging into this a bit more and coming
up with some more specific reasons for the change.

Thanks,

Joseph Thelen