linux-kernel - Re: [PATCH 0/4] EFI 1:1 mapping

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: <1370277307.2910.39.camel@dabdike>
Date:	Mon, 03 Jun 2013 09:35:07 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Borislav Petkov <bp@...en8.de>,
	Linux EFI <linux-efi@...r.kernel.org>,
	Matt Fleming <matt@...sole-pimps.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 0/4] EFI 1:1 mapping

On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 09:18:06AM -0700, James Bottomley wrote:
> 
> > I don't entirely buy that.  All EFI programs run with the physical
> > address map, therefore every API an EFI program uses is also tested, at
> > boot time only, obviously.
> 
> That seems optimistic. Windows never calls QueryVariableInfo() during 
> boot services, so what makes you think doing so has ever been tested?

It's used by the UEFI shell package ... every system which boots to the
shell automatically tests this.  I know no locked down UEFI system ships
with a shell but almost every system in test has a Shell in some form,
so I think its fairly safe to call it from boot services.

> > However, the ExitBootServices() code seems to be much simpler, so I 
> > don't think it will cause too many bugs.  The UEFI test suites also 
> > seem to try UEFI calls before and after ExitBootServices(), so I think 
> > relying on a 1:1 mapping looks safer to me.
> 
> I have no expectation that the majority of system vendors run the test 
> suite, but I have every expectation that every system vendor runs 
> Windows. We should behave as close to the tested mechanism as possible, 
> ie do what Windows does - and that includes calling 
> SetVirtualAddressMap().

OK, so we basically agree to disagree.  When I looked at the actual
SetVirtualAddressMap() implementation, my heart skipped several beats:
it's a massive set of pointer chasing heuristics which is bound to be
incorrect in some instance, just because its so complex and easy to get
wrong.  Every time it's incorrect, we'll get a physical pointer used in
a virtual space and an oops within the UEFI code.  Conversely, I think
the engineering risk that a particular UEFI call is expecting to have
had SetVirtualAddressMap called is much lower.

However, what about a compromise: why don't we implement 1:1 mapping and
then call SetVirtualAddressMap with the 1:1 map ... in theory the
pointer chases should then be nops (it will be replacing the physical
address with the same virtual address), so everything should just work
and anything the UEFI vendor missed will still work because the physical
address will work also in this scenario.

James

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