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

[Linus Torvalds]

On Wed, Jan 10, 2018 at 11:28 AM, Willy Tarreau <w@xxxxxx> 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