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: <1370270282.2910.9.camel@dabdike>
Date:	Mon, 03 Jun 2013 07:38:02 -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 15:30 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 07:27:22AM -0700, James Bottomley wrote:
> 
> > That's correct.  I think not calling SetVirtualAddressMap() and just
> > using a 1:1 mapping is far safer (having looked at what tianocore does
> > for SetVirtualAddressMap()).  The chances are that all the UEFI bioses
> > are only tested with windows, so the pointer chases it has to do to
> > switch address maps only work with the operations windows does.
> 
> Windows calls SetVirtualAddressMap(), so the only way these systems have 
> been tested is with SetVirtualAddressMap().

I know, but that's not what I said.

If you look at the implementation, SetVirtualAddressMap() does a massive
pointer chase through the images.  It not only tries to relocate the
text and data, but it also tries to relocate all the users of the data.
Some of these sources of data are boot time and some runtime.  Those
both need to be relocated by a separate pointer chase.  What we saw with
the QueryVariableInfo() problem was that a boot time pointer wasn't
relocated.  That's got to mean that windows only calls QueryVariableInfo
from runtime.

My point is that if we elect to call SetVirtualAddressMap() we'll be
restricted to only making the calls at boot time that windows does
otherwise we'll end up with these unrelocated pointers.  That's a huge
nasty verification burden on us.  Alternatively, if we never call
SetVirtualAddressMap() it seems to me that we just don't have to worry
about pointer relocation issues.  Thus, I think it would be better we
use the 1:1 mapping instead of calling SetVirtualAddressMap().

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/