Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932996AbbLOAHj (ORCPT ); Mon, 14 Dec 2015 19:07:39 -0500 Received: from mail-ob0-f174.google.com ([209.85.214.174]:36296 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932540AbbLOAHh (ORCPT ); Mon, 14 Dec 2015 19:07:37 -0500 MIME-Version: 1.0 In-Reply-To: <19122B57-8052-4A92-801E-03CC84E66F06@zytor.com> References: <20151204164057.GE2514@codeblueprint.co.uk> <17EC94B0A072C34B8DCF0D30AD16044A0288EFC7@BPXM09GP.gisp.nec.co.jp> <20151208122557.GA2518@codeblueprint.co.uk> <20151208141946.GD27180@pd.tnic> <19122B57-8052-4A92-801E-03CC84E66F06@zytor.com> From: Andy Lutomirski Date: Mon, 14 Dec 2015 16:07:17 -0800 Message-ID: Subject: Re: [PATCH 1/2] x86: Fix kernel panic when booting with XD disabled in uEFI firmware To: "H. Peter Anvin" Cc: Kees Cook , Borislav Petkov , Matt Fleming , Kosuke Tatsukawa , Thomas Gleixner , Ingo Molnar , "x86@kernel.org" , "linux-efi@vger.kernel.org" , "linux-kernel@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 Content-Length: 2504 Lines: 62 On Tue, Dec 8, 2015 at 12:39 PM, H. Peter Anvin wrote: > On December 8, 2015 12:30:06 PM PST, Kees Cook wrote: >>On Tue, Dec 8, 2015 at 6:19 AM, Borislav Petkov wrote: >>> On Tue, Dec 08, 2015 at 12:25:57PM +0000, Matt Fleming wrote: >>>> On Mon, 07 Dec, at 11:10:43PM, Kosuke Tatsukawa wrote: >>>> > >>>> > Thank you pointing that out. >>>> > >>>> > linux-4.4-rc3 booted without a problem on a real server even with >>XD >>>> > turned off by the firmware. I didn't notice this before because I >>was >>> >>> The aforementioned patch reenables NX. >>> >>>> Borislav, what do you think about stripping PAGE_NX from >>'page_flags' >>>> in kernel_map_pages_in_pgd() if NX isn't supported, rather than >>>> returning EINVAL? At least that way EFI runtime services would still >>>> work. >>> >>> I guess we can - I mean, I don't see what can go wrong more when >>> allowing the kernel to execute even NX UEFI regions. Maybe easier >>> generation of "gadgets" in the ROP sense ... >>> >>> On a related node, I'm very sceptical of the existence of this >>"noexec" >>> chicken bit, if you ask me. It is a really bad idea, security-wise, >>to >>> disable NX. Is there even a valid use case to disable NX? >>> >>> Because if not, I'd vote for removing that chicken bit or at least >>> taining the kernel with >>> >>> add_taint(TAINT_USER_MORON, ... ); >> >>If we add this for not-nx, I would like to add it for not-rodata too. >> >>> Kees, has this NX disabling practice come up in the past, per >>chance... ? >> >>I've never seen anyone actually use it. I was asked to include it out >>of fear of some kind of rogue imagined CPU configuration that mixed NX >>and non-NX capable CPUs in a single machine where the forced NX >>re-enablement code would cause problems. As you might imagine, I'm not >>aware of this case ever being an issue. ;) >> >>-Kees > > Actually I think of it much more as a debug option - being able to mimic NX-unaware hardware and to track down problems in the field. Does that really work? We don't respect noexec when setting up EFER. in any case, we should get plenty of coverage. Non-PAE kernels are effectively running on non NX-supporting hardware no matter what. --Andy -- 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/