Date: Mon, 8 Jan 2018 18:25:10 +0000
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Ingo Molnar <mingo@kernel.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>, Willy Tarreau <w@1wt.eu>,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        torvalds@linux-foundation.org
Subject: Re: [PATCH RFC 3/4] x86/pti: don't mark the user PGD with _PAGE_NX.
Message-ID: <20180108182510.3c6dda34@alans-desktop>
In-Reply-To: <20180108175028.acwe3glhw4rsvdsx@gmail.com>
References: <1515427939-10999-1-git-send-email-w@1wt.eu>
        <1515427939-10999-4-git-send-email-w@1wt.eu>
        <alpine.DEB.2.20.1801081803290.1735@nanos>
        <760b7264-1ae7-bcaa-6d20-f47cc7c7fce1@intel.com>
        <20180108175028.acwe3glhw4rsvdsx@gmail.com>
Organization: Intel Corporation
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

> 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