From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752075AbbJLPud (ORCPT ); Mon, 12 Oct 2015 11:50:33 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:38584 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbbJLPub (ORCPT ); Mon, 12 Oct 2015 11:50:31 -0400 Date: Mon, 12 Oct 2015 16:50:28 +0100 From: Matt Fleming To: Ard Biesheuvel Cc: Ingo Molnar , Borislav Petkov , 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" Subject: Re: [PATCH v2] x86/mm: warn on W+x mappings Message-ID: <20151012155028.GH2579@codeblueprint.co.uk> References: <5612CBE8.2010504@tycho.nsa.gov> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 12 Oct, at 05:34:53PM, Ard Biesheuvel wrote: > > On arm64, we only map in all of the UEFI runtime services regions > during the time any of these services are being invoked. I think this > should be mostly feasible on x86 as well, although it would involve > yet another rewrite of the EFI region mapping code, and most likely a > long list of quirks for platforms that are not able to deal with it > correctly for one reason or the other (but that all come down to: 'if > you are not doing it like Windows does it, you must be doing it > wrong'). Actually, we use separate page tables for mapping the EFI runtime services on x86 right now. These tables are only used when making runtime calls, just like on arm64. So we've got a little bit of isolation right now. > That would make the 'secure' way of mapping things an opt-in > feature, which is generally not desirable for security features > (since it will rarely be used in the real world then). I'd like to think that we're coming to EFI_PROPERTIES_TABLE early enough that we can work out all the kinks, get things working out of the box in upstream tianocore, and have it be the standard way to expose memory regions. At least that's my hope. > So enabling the Properties Table memprotect feature as soon as the > spec defines it in a meaningful way is probably a better way to go, > and our current involvement is focused on defining it such that it can > be enabled by default by firmwares rather than ending up an obscure > switch in the BIOS screen that only the paranoid ever turn on. Indeed. -- Matt Fleming, Intel Open Source Technology Center