Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751663AbbKGHJ2 (ORCPT ); Sat, 7 Nov 2015 02:09:28 -0500 Received: from mail-wi0-f176.google.com ([209.85.212.176]:38879 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750966AbbKGHJ0 (ORCPT ); Sat, 7 Nov 2015 02:09:26 -0500 Date: Sat, 7 Nov 2015 08:09:22 +0100 From: Ingo Molnar To: Matt Fleming Cc: Linus Torvalds , Stephen Smalley , Dave Jones , Linux Kernel Mailing List , Thomas Gleixner , "H. Peter Anvin" , Borislav Petkov , Andrew Morton , Andy Lutomirski , Denys Vlasenko , Kees Cook , linux-efi@vger.kernel.org, Ard Biesheuvel Subject: Re: [GIT PULL] x86/mm changes for v4.4 Message-ID: <20151107070922.GC6235@gmail.com> References: <20151103111649.GA3477@gmail.com> <20151104233907.GA25925@codemonkey.org.uk> <20151105021710.GA22941@codemonkey.org.uk> <20151106065549.GA2031@gmail.com> <20151106123912.GC2651@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151106123912.GC2651@codeblueprint.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3994 Lines: 80 * Matt Fleming wrote: > On Fri, 06 Nov, at 07:55:50AM, Ingo Molnar wrote: > > > > 3) We should fix the EFI permission problem without relying on the firmware: it > > appears we could just mark everything R-X optimistically, and if a write fault > > happens (it's pretty rare in fact, only triggers when we write to an EFI > > variable and so), we can mark the faulting page RW- on the fly, because it > > appears that writable EFI sections, while not enumerated very well in 'old' > > firmware, are still supposed to be page granular. (Even 'new' firmware I > > wouldn't automatically trust to get the enumeration right...) > > Sorry, this isn't true. I misled you with one of my earlier posts on > this topic. Let me try and clear things up... > > Writing to EFI regions has to do with every invocation of the EFI > runtime services - it's not limited to when you read/write/delete EFI > variables. In fact, EFI variables really have nothing to do with this > discussion, they're a completely opaque concept to the OS, we have no > idea how the firmware implements them. Everything is done via the EFI > boot/runtime services. > > The firmware itself will attempt to write to EFI regions when we > invoke the EFI services because that's where the PE/COFF ".data" and > ".bss" sections live along with the heap. There's even some relocation > fixups that occur as SetVirtualAddressMap() time so it'll write to > ".text" too. > > Now, the above PE/COFF sections are usually (always?) contained within > EFI regions of type EfiRuntimeServicesCode. We know this is true > because the firmware folks have told us so, and because stopping that > is the motivation behind the new EFI_PROPERTIES_TABLE feature in UEFI > V2.5. > > The data sections within the region are also *not* guaranteed to be > page granular because work was required in Tianocore for emitting > sections with 4k alignment as part of the EFI_PROPERTIES_TABLE > support. > > Ultimately, what this means is that if you were to attempt to > dynamically fixup those regions that required write permission, you'd > have to modify the mappings for the majority of the EFI regions > anyway. And if you're blindly allowing write permission as a fixup, > there's not much security to be had. I think you misunderstood my suggestion: the 'fixup' would be changing it from R-X to RW-, i.e. it would add 'write' permission but remove 'execute' permission. Note that there would be no 'RWX' permission at any given moment - which is the dangerous combination. > > If that 'supposed to be' turns out to be 'not true' (not unheard of in > > firmware land), then plan B would be to mark pages that generate write faults > > RWX as well, to not break functionality. (This 'mark it RWX' is not something > > that exploits would have easy access to, and we could also generate a warning > > [after the EFI call has finished] if it ever triggers.) > > > > Admittedly this approach might not be without its own complications, but it > > looks reasonably simple (I don't think we need per EFI call page tables, > > etc.), and does not assume much about the firmware being able to enumerate its > > permissions properly. Were we to merge EFI support today I'd have insisted on > > trying such an approach from day 1 on. > > We already have separate EFI page tables, though with the caveat that > we share some of swapper_pg_dir's PGD entries. The best solution would > be to stop sharing entries and isolate the EFI mappings from every > other page table structure, so that they're only used during the EFI > service calls. Absolutely. Can you try to fix this for v4.3? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/