linux-kernel - Re: [PATCH RFC 3/4] x86/pti: don't mark the user PGD with _PAGE

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Jan 2018 15:09:00 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Dave Hansen <dave.hansen@...el.com>, Willy Tarreau <w@....eu>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RFC 3/4] x86/pti: don't mark the user PGD with _PAGE_NX.

On Mon, Jan 8, 2018 at 3:05 PM, Andy Lutomirski <luto@...nel.org> wrote:
> On 01/08/2018 09:03 AM, Dave Hansen wrote:
>>
>> On 01/08/2018 08:12 AM, Willy Tarreau wrote:
>>>
>>> Since we're going to keep running on the same PGD when returning to
>>> userspace for certain performance-critical tasks, we'll need the user
>>> pages to be executable. So this code disables the extra protection
>>> that was added consisting in marking user pages _PAGE_NX so that this
>>> pgd remains usable for userspace.
>>>
>>> Note: it isn't necessarily the best approach, but one way or another
>>>        if we want to be able to return to userspace from the kernel,
>>>        we'll have to have this executable anyway. Another approach
>>>        might consist in using another pgd for userland+kernel but
>>>        the current core really looks like an extra careful measure
>>>        to catch early bugs if any.
>>
>>
>> I don't like this.
>>
>> I think the prctl() should apply to an entire process, not to a thread.
>> If it applies to a process, you can unpoison the PGD.  I even had code
>> to do this in an earlier version of the (whole system) runtime PTI
>> on/off stuff.
>>
>> Why are you even posting half-baked hacks like this now?  Is there
>> something super-pressing about this set that we need to lock in a new
>> ABI now?
>>
>
> I vote per-thread.
>
> Anyway, we can easily sync the NX-clearing: just catch the spurious page
> fault and clear the bit.  Avoiding infinite loops will need a bit of
> thought, but it's surely doable.
>
> Or we set a per-mm flag saying "no NX", then do synchronize_sched() or
> similar if we were the first to set it (or take the pagetable lock), then
> clear all the NX bits.  Again, needs some care, but doable.
>
> FWIW, the NX trick quite nicely emulates SMEP on non-SMEP hardware, which is
> fantastic for Spectre resistance and general hardening. Turning it off
> totally defeats that, which hurts a bit.
>
> Also, Kees should be CC'd here.

Please please keep the NX. As mentioned, this gets us emulated SMEP
for "free" with PTI, which Linux has needed for years.

-Kees

-- 
Kees Cook
Pixel Security