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]

Message-ID: <20180108182510.3c6dda34@alans-desktop>
Date:   Mon, 8 Jan 2018 18:25:10 +0000
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>, Willy Tarreau <w@....eu>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        torvalds@...ux-foundation.org
Subject: Re: [PATCH RFC 3/4] x86/pti: don't mark the user PGD with _PAGE_NX.

> The simplest model is indeed child inheritance tree propagation - plus perhaps the 
> ability for a thread to change its *own* PTI status, which obviously doesn't 
> create any deep "process lookup" or cross-CPU complications.
> 
> ( Note that here I only mean "simple to implement" - we might decide to not offer
>   the ABI. )

I still think cgroups are the best model for this. In particular it
naturally fits things like containers, or network facing apps that fork
helpers.

Secondly when you are looking at barrier semantics between client/client
a cgroup is much more natural as a way to group processes together who
don't need to be protected from each other as they are trusting each
other. (Or we could just harcode this based upon ptraceability ?)

Alan