linux-kernel - Re: [PATCH -v2 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]

Date:	Tue, 2 Jul 2013 09:29:50 +0200
From:	Pavel Machek <pavel@....cz>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Borislav Petkov <bp@...en8.de>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Ingo Molnar <mingo@...nel.org>,
	Linux EFI <linux-efi@...r.kernel.org>,
	Matt Fleming <matt@...sole-pimps.org>, X86 ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH -v2 0/4] EFI 1:1 mapping

On Fri 2013-06-21 09:42:35, H. Peter Anvin wrote:
> On 06/21/2013 07:21 AM, Borislav Petkov wrote:
> > On Fri, Jun 21, 2013 at 03:05:30AM -0700, H. Peter Anvin wrote:
> >> If you cap it you are basically imposing a constraint on the firmware
> >> and may not run properly (or at least have to turn off EFI runtime
> >> calls with all that implies.)
> > 
> > I don't want to cap EFI just for the fun of it but rather set a limit
> > so that the next one who wants a chunk of the virtual address space can
> > have a reliable limit from where she/he can start. Otherwise we won't
> > know where EFI reliably ends...
> > 
> 
> We don't... and I don't think there is anything we can do about it.  If
> some messed-up firmware wants to map a terabyte we either refuse and
> don't allow EFI runtime calls on that machine or we accept it.
> 
> Fortunately the space is extremely large and with growing down from a
> known address it is less likely that we'll conflict with something.

Hmm, will not setting up huge areas be slow?

Or we are going to use 2G pages or something?

Or should we make it slow on purpose so that at least server
vendors are discouraged from using big areas? :-)

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/