From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755521AbbJUSrQ (ORCPT ); Wed, 21 Oct 2015 14:47:16 -0400 Received: from mail-ob0-f182.google.com ([209.85.214.182]:36011 "EHLO mail-ob0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755471AbbJUSrO (ORCPT ); Wed, 21 Oct 2015 14:47:14 -0400 MIME-Version: 1.0 In-Reply-To: <20151021143651.GE3575@pd.tnic> References: <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> <20151021124924.GA19262@gmail.com> <20151021132430.GD3575@pd.tnic> <20151021143651.GE3575@pd.tnic> From: Andy Lutomirski Date: Wed, 21 Oct 2015 11:46:53 -0700 Message-ID: Subject: Re: [PATCH v2] x86/mm: warn on W+x mappings To: Borislav Petkov Cc: Ard Biesheuvel , Ingo Molnar , Matt Fleming , Stephen Smalley , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Kees Cook , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Andy Lutomirski , Denys Vlasenko , Brian Gerst , "linux-efi@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 21, 2015 at 7:36 AM, Borislav Petkov wrote: > On Wed, Oct 21, 2015 at 03:28:56PM +0200, Ard Biesheuvel wrote: >> In theory, yes. In practice, since this is supposed to be a security >> enhancement, we need some kind of ground truth to tell us which pages >> can be legally modified *and* executed, so that we can detect the >> illegal cases. My point was that, since a multitude of PE/COFF images >> can be covered by a single EfiRuntimeServicesCode region, the UEFI >> memory map does not give us enough information to make the distinction >> between a page that sits on the text/data boundary of some PE/COFF >> image and a page that sits wholly in either. > > Well, we're going to simply allow the accesses to in-kernel users which > fault on those ranges, assuming that in-kernel modifiers are legit and > DTRT. Which means, we don't really need to know which pages can be > legally modified - we simply trust the in-kernel users. > > The moment you're able to load an evil kernel module, guarding against > those writes is the last thing you need to worry about... I don't think we can do a whole lot to help against broken UEFI code, but having anything mapped RWX is a nice target for people trying to exploit kernel bugs. Hence my suggestion to clear W except when actually running UEFI code. If the UEFI stuff is mapped in its own PGD entry, we could just RO that entire PGD entry everywhere except the UEFI pgd (and make sure to clear G so that the TLB entries get zapped). --Andy