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 18:49:05 +0100
From:   Willy Tarreau <w@....eu>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org, tglx@...utronix.de, gnomes@...rguk.ukuu.org.uk,
        torvalds@...ux-foundation.org, Ingo Molnar <mingo@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH RFC 3/4] x86/pti: don't mark the user PGD with _PAGE_NX.

On Mon, Jan 08, 2018 at 06:30:32PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 09:23:49AM -0800, Dave Hansen wrote:
> > On 01/08/2018 09:17 AM, Willy Tarreau wrote:
> > >> I think the prctl() should apply to an entire process, not to a thread.
> > > 
> > > As I mentionned in another mail, I didn't know how to do it, even less
> > > how to do it fast enough so that we didn't add more cycles to the syscall
> > > code.
> > 
> > You can _implement_ it with a task thread if you want.  Just spray it
> > across all threads at the prctl()-time instead of a single thread.
> > It'll take a wee bit of locking.
> > 
> > I just don't think the API should apply to a single thread.
> 
> It is surprisingly hard to find all tasks that share an mm. Finding all
> threads in a threadgroup is easy, but we have CLONE_THREAD and CLONE_VM
> as separate bits.
> 
> In any case, aside from that, setting this remotely is indeed
> 'intersting'.

Then couldn't we instead detect that there's more than one thread in
the process and refuse to apply prctl() to prevent the behaviour from
becoming inconsistent ? This would seem reasonable after all, we want
to do this very early upon startup, it probably doesn't make sense to
change one's mind after threads have been created (or maybe only to
re-enable protection on some of them ?).

Willy