linux-kernel - Re: [PATCH RFC 2/4] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET

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]

Message-ID: <20180108174636.76ioxk6yem73yh7i@gmail.com>
Date:   Mon, 8 Jan 2018 18:46:36 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org,
        x86@...nel.org, gnomes@...rguk.ukuu.org.uk,
        torvalds@...ux-foundation.org, Dave Hansen <dave@...1.net>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH RFC 2/4] x86/arch_prctl: add ARCH_GET_NOPTI and
 ARCH_SET_NOPTI to enable/disable PTI

* Thomas Gleixner <tglx@...utronix.de> wrote:

> On Mon, 8 Jan 2018, Ingo Molnar wrote:
> > * Thomas Gleixner <tglx@...utronix.de> wrote:
> > > Per task is really an odd choice. That should be per process I think, but
> > > that of course needs synchronization of some form. Aside of that we need to
> > > think about fork().
> > 
> > So per task (thread) is the most natural approach to low level asm flaggery.
> 
> Well, yes and no. PTI is a property of the mm/pgdir and that's process
> wide.

Yes and no: the contents of CR3 is a property of the _thread_ (CPU), so we do have 
the implementational degree of freedom of executing user-space with either the 
user+kernel PGD or the user-only PGD.

The question I'm asking is whether it makes sense to offer this - the 
_possibility_ is clearly there unless I'm missing something.

> > Making it per thread also makes some sense conceptually: in a complex 
> > multi-threaded runtime implementation some threads might never execute
> > 'untrusted' code, some might. No need to penalize the 'server' threads.
> 
> If one thread runs untrusted code then your 'trusted' thread is not longer
> trusted either as they share everything.

I think you are missing the wider context here: a number of runtime environments 
(browsers, JIT compilers, etc.) are able to run "untrusted code" while still 
applying heavy sandboxing constraints.

In some of those runtime models it's very much possible to have untrusted code in 
the same address space as trusted code. BPF is an example for such a runtime 
model: we can run user-defined BPF JIT-ed code in kernel context.

Thanks,

	Ingo