linux-kernel - Re: [PATCH 1/2] x86: Fix kernel panic when booting with XD disabled in uEFI firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALCETrVv=rUS-6HmUxVEOHFnqVRi75BTaGuMWSYogcuLORWA7Q@mail.gmail.com>
Date:	Mon, 14 Dec 2015 16:07:17 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Kees Cook <keescook@...omium.org>, Borislav Petkov <bp@...en8.de>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Kosuke Tatsukawa <tatsu@...jp.nec.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] x86: Fix kernel panic when booting with XD disabled
 in uEFI firmware

On Tue, Dec 8, 2015 at 12:39 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On December 8, 2015 12:30:06 PM PST, Kees Cook <keescook@...omium.org> wrote:
>>On Tue, Dec 8, 2015 at 6:19 AM, Borislav Petkov <bp@...en8.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/