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 20:54:50 +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 09:41:34PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 08:35:48PM +0100, Matthew Garrett wrote:
> > No, I think that's the wrong thing to do. We should set up the current
> > mappings and the 1:1 mappings, and pass the current mappings through
> > SetVirtualAddressMap(). That matches the behaviour of Windows.
> 
> And when do we use the 1:1 mappings and when the current mappings when
> doing runtime calls?

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...

-- 
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/