From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932339AbbJUJmy (ORCPT ); Wed, 21 Oct 2015 05:42:54 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:33499 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932322AbbJUJmr (ORCPT ); Wed, 21 Oct 2015 05:42:47 -0400 Date: Wed, 21 Oct 2015 11:42:42 +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: <20151021094242.GA12155@gmail.com> References: <20151006073205.GA11115@gmail.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151014210257.GF2782@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 * 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-'. 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? Thanks, Ingo