linux-kernel - Re: [RFC PATCH v3 0/8] Per process PTI activation

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:   Wed, 10 Jan 2018 11:35:14 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Willy Tarreau <w@....eu>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Kees Cook <keescook@...omium.org>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC PATCH v3 0/8] Per process PTI activation

On Wed, Jan 10, 2018 at 11:28 AM, Willy Tarreau <w@....eu> wrote:
>
> There are now two prctls :
>   - ARCH_DISABLE_PTI_NOW to disable PTI for the current process. It
>     checks that mm_users <= 1 before proceeding, and only acts if
>     pti_adjust == 1. It's cleared on execve().
>
>   - ARCH_DISABLE_PTI_NEXT to disable PTI after the next execve(). It
>     doesn't change the current process' state and will only set
>     ARCH_DISABLE_PTI_NOW after the next execve() and be cleared. It's
>     made for wrappers.

So I really hate these interfaces. It's fundamentally only good for
long-lived processes.

What if you trust a session, not a single process?

> What remains to be done :
>   - _PAGE_NX is still commented out for now. I'll need some help here
>     if we have to catch a page fault to deal with it. Ingo apparently
>     suggested that probably it doesn't bring any value anymore on modern
>     systems with SMEP.

I still think that the whole "go by thread" is fundamentally complete garbage.

I know Andy asked for it, and I know he's usually right, but he's on
drugs on this one.

Per-thread PTI does not make sense, and it is WRONG. It means, for
example, that you can't just say "we always just use one page table
for this mm", and not even populate the other one.

So per-thread PTI is garbage and must die. Either the VM is protected
or it is not. It's about the mm, not about the thread. Andy didn't
give any sane reasons why it should be per-thread.

Worst comes to worst, and we end up having somebody who really really
has a good reason for it and can articulate it and explain why they
want it, and we can then revisit things. But no. Not in some initial
implementation. That's crazy.

                   Linus