Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 10 Jan 2018 12:04:25 -0800 | Subject | Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set |
| |
On Wed, Jan 10, 2018 at 11:50 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Wed, Jan 10, 2018 at 11:21 AM, Andy Lutomirski <luto@kernel.org> wrote: >> >> I really dislike state that isn't cleared on execve(). I'm assuming >> that this is so you can run time pwn_me_without_pti whatever? Surely >> LD_PRELOAD can do this, too? > > Andy, what the hell is wrong with you? > > You are actively trying to screw this whole interface up, aren't you? > > LD_PRELOAD cannot work for a wrapper, for the simple reason that it > runs in the same context as the process. So if you want to say "I want > to run this process without PTI", but you don't want to run the > process with elevated privileges, LD_PRELOAD doesn't work.
Oh, right, duh. Brain was off.
> The "let's do it per thread" made no sense either, since that's > fundamentally not how page tables work, and it's complete broken shit.
I still disagree with you here. The whole concept of per-thread or per-mm or per-whatever PTI disablement is if the admin for some reason trusts some piece of code not to try to exploit Meltdown. But just imagine a program like a web browser. The browser will do some performance critical stuff (networking) and some absolutely-no-fucking-way-would-I-turn-off-PTI stuff (running scripts). So per-thread seems totally sensible to me. No one sane would ever do this for a web browser, but I can easily imagine it for something like a web *server* or even a database server.
Just logically, too, per-thread is the obvious semantics. Whether we rewrite CR3 when we go to usermode is a thing affecting that thread. The only reason the mm has anything to do with it is the NX trick.
| |