From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754740AbbJUMtb (ORCPT ); Wed, 21 Oct 2015 08:49:31 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:33020 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752971AbbJUMt3 (ORCPT ); Wed, 21 Oct 2015 08:49:29 -0400 Date: Wed, 21 Oct 2015 14:49:24 +0200 From: Ingo Molnar To: Matt Fleming Cc: Borislav Petkov , Stephen Smalley , x86@kernel.org, linux-kernel@vger.kernel.org, keescook@chromium.org, Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Andy Lutomirski , Denys Vlasenko , Brian Gerst , linux-efi@vger.kernel.org, Ard Biesheuvel Subject: Re: [PATCH v2] x86/mm: warn on W+x mappings Message-ID: <20151021124924.GA19262@gmail.com> References: <5613EAD5.2070405@tycho.nsa.gov> <20151012113605.GB7384@pd.tnic> <20151012124113.GD2579@codeblueprint.co.uk> <20151012124936.GA6260@gmail.com> <20151012125548.GE2579@codeblueprint.co.uk> <20151012141754.GA6621@gmail.com> <20151012144928.GF2579@codeblueprint.co.uk> <20151014151807.GA27013@gmail.com> <20151014210257.GF2782@codeblueprint.co.uk> <20151021094242.GA12155@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151021094242.GA12155@gmail.com> 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 * Ingo Molnar wrote: > > * Matt Fleming wrote: > > > > > Right, we could do that, but then we wouldn't be able to support > > > > creation/updating variables at runtime, such as when you install a > > > > distribution for the first time, or want to boot a new kernel filename > > > > directly from the firmware without a boot loader (and need to modify the > > > > BootXXXX variables). > > > > > > Do we know the precise position and address range of these variables? > > > > > > We could map them writable (but not executable), and the rest executable (but > > > not writable). > > > > The variables are stored in NVRAM, which we don't map into the kernel virtual > > address space. [...] > > Just curious: is there firmware that memory maps those variables privately? > > > [...] We have to initiate the transaction of writing to the variables by > > executing EFI runtime services. > > > > We obviously have buffers that we pass to the BIOS that contain variable data, > > but these should be NX anyway because they're regular kernel allocations. > > > > > That raises the question whether the same physical page ever mixes variables > > > and actual code - but the hope would be that it's suffiently page granular for > > > this to work. > > > > I don't think that would ever happen. > > Ok, that's promising, so how about this then to solve the security weakness the > new warning unearthed: map the whole EFI range as 'r-x (NX)', but detect writes > from the page fault handler and transparently allow them to flip over the range > to 'rw-'. So I meant to say 'page' instead of 'range'. I.e. this dynamic mechanism would flip pages over to 'rw-', as write faults occur from EFI code that writes to them. We don't need to know which regions are writable data, and which regions are executable-code/readonly-data. The following aspect would guarantee safety: > Note that for security reasons we don't allow a subsequent flipping back to NX > if there's an NX fault on the same page, i.e. this new mechanism is a monotonic > one-way process that should dynamically 'map out' data pages versus executable > pages. > > It should also be pretty robust, assuming we can take page faults while EFI code > is executing and is trying to modify EFI data: is that the case? and this is why I asked whether boundaries between 'Code' and 'Writable data' sections are page granular - which they do appear to be. (i.e. there are no singular pages that are both writable data and code at once.) Thanks, Ingo