linux-kernel - Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

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:	Fri, 13 Nov 2015 22:22:29 +0000
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H . Peter Anvin" <hpa@...or.com>, Toshi Kani <toshi.kani@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>,
	Dave Jones <davej@...emonkey.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Stephen Smalley <sds@...ho.nsa.gov>
Subject: Re: [PATCH 6/6] Documentation/x86: Update EFI memory region
 description

On Fri, 13 Nov, at 08:42:54AM, Linus Torvalds wrote:
> On Fri, Nov 13, 2015 at 1:29 AM, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> > On Fri, 13 Nov, at 10:22:10AM, Ingo Molnar wrote:
> >
> > You've snipped the patch hunk that gives the address range used,
> 
> I'm actually wondering if we should strive to make the UEFI stuff more
> like a user process, and just map the UEFI mappings in low memory in
> that magic UEFI address space.

We map things in the user address space now but only for the purposes
of having an identity mapping, for the reasons that I mentioned
previously: bust firmware accesses and for the SetVirtaulAddressMap()
call [1]. Importantly, the kernel does not access the identity mapping
directly.

So if we were to repurpose the user address space it would make sense
to just have the identity mapping be the one and only mapping.

However, going through the identity addresses to invoke EFI runtime
services is known to break some Apple Macs. It's probably worth
revisiting this issue, because I don't have any further details.

Having a separate mapping in the user address space that isn't the
identity mapping is also possible of course.

> We won't be able to run those things *as* user space, since I assume
> the code will want to do a lot of kernely things, but shouldn't we aim
> to make it look as much like that as possible? Maybe some day we could
> even strive to run it in some controlled environment (ie user space
> with fixups, virtual machine, whatever), but even if we never get
> there it sounds like a potentially good idea to try to set up the
> mappings to move in that direction..

It would be interesting to see how far we could push this, say, using
SMAP/SMEP to further isolate what kernel pieces the firmware can
touch. It's not about security guarantees since most of the firmware
functionality is implemented in SMM today for x86, but it does go some
way towards providing protection from unintended accesses.

> No big hurry, and maybe there are good reasons not to go that way. The
> first step is indeed just to get rid of the WX mappings in the normal
> kernel page tables.

I think it's worth exploring.

[1] Oh, and also for the EFI mixed mode code (running 64-bit kernels
on 32-bit EFI), but less people tend to care about that ;-)
--
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/