linux-kernel - Re: [PATCH -v2] EFI: Runtime services virtual 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: <20131004094247.GA6796@nazgul.tnic>
Date:	Fri, 4 Oct 2013 11:42:47 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt@...sole-pimps.org>
Cc:	Dave Young <dyoung@...hat.com>, X86 ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...e.de>,
	Matt Fleming <matt@...sole-pimps.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Vivek Goyal <vgoyal@...hat.com>, linux-efi@...r.kernel.org
Subject: Re: [PATCH -v2] EFI: Runtime services virtual mapping

On Wed, Oct 02, 2013 at 11:46:44AM -0700, H. Peter Anvin wrote:
> It's pretty straightforward - just drop the starting address to proper
> alignment after you subtract the size.

Ok, just an observation - it is not necessarily a bad thing but I
thought we should talk about it:

So, when we do the VA space saving mapping, we're basically mapping huge
physical ranges onto a much smaller VA range and adding other mappings
in there pots-factum could turn out to be not straight-forward and
problematic.

To illustrate what I'm trying to say, here's an example from two regions
in OVMF:

[    0.011005] __map_region: VA: 0xfffffffeff800000..0xffffffff00000000 -> PA: 0x800000.. 0x1000000
[    0.017005] __map_region: VA: 0xfffffffeff600000..0xfffffffeff620000 -> PA: 0x7c000000.. 0x7c020000

Now, the physical address range spanned by those regions is:

0x7c020000 - 0x800000 = 0x7b820000 =~ 2G

while the virtual is

0xffffffff00000000 - 0xfffffffeff600000 = 0xa00000 =~ 10M

Now, we obviously cannot map the whole PA space in there, the question
is: do we care?

I mean, we can map it to other VA range but this will totally destroy
the simple math of computing EFI VA addresses with an offset, similar to
PAGE_OFFSET.

OTOH, if we keep Matt's suggestion of mapping the whole EFI address
space window, we don't have that issue. And we've reserved 64G for
EFI and if it needs more, we probably can give it since we're using a
different pagetable anyway.

Opinions?

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