linux-kernel - Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

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:	Thu, 6 Jun 2013 21:18:28 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Matt Fleming <matt@...sole-pimps.org>,
	Linux EFI <linux-efi@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>, X86-ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH 3/4] x86, efi: Add an efi= kernel command line parameter

On Thu, Jun 06, 2013 at 10:07:05PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 08:54:50PM +0100, Matthew Garrett wrote:
> > We want both to be available when we're making the call, but I think
> > we should probably enter via the high addresses. The only reason we're
> > doing this at all is that some systems don't update all of their
> > pointers from physical mode, and we'd prefer them to work rather than
> > fault...
> 
> Actually, we do the 1:1 thing so that EFI runtime works in a kexec
> kernel too. Which won't work if we use the high addresses.

kexec seems like a lower priority than compatibility. Perhaps keep the 
efi argument for people who want to use kexec? hpa suggested allocating 
a fixed high area for UEFI mappings, which would also solve this.

> However, if we can use the 1:1 map *after* SetVirtualAddressMap() has
> been called with the high mappings, then my issue is solved - we drop
> to using 1:1 in the kexec kernel only. But I don't think that is the
> case...

Yeah, calling SetVirtualAddressMap() with high addresses is going to 
result in the firmware having a bunch of pointers to high addresses.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/