Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754327AbeAHRtc (ORCPT + 1 other); Mon, 8 Jan 2018 12:49:32 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:38968 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751772AbeAHRtb (ORCPT ); Mon, 8 Jan 2018 12:49:31 -0500 Date: Mon, 8 Jan 2018 18:49:05 +0100 From: Willy Tarreau To: Peter Zijlstra Cc: Dave Hansen , linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de, gnomes@lxorguk.ukuu.org.uk, torvalds@linux-foundation.org, Ingo Molnar , Borislav Petkov , Josh Poimboeuf , Andy Lutomirski Subject: Re: [PATCH RFC 3/4] x86/pti: don't mark the user PGD with _PAGE_NX. Message-ID: <20180108174905.GI10913@1wt.eu> References: <1515427939-10999-1-git-send-email-w@1wt.eu> <1515427939-10999-4-git-send-email-w@1wt.eu> <57039ac1-efe2-2f97-386f-dab0b90f64a5@intel.com> <20180108171707.GG10913@1wt.eu> <407b4328-4447-38a5-15c1-0170741e3d14@intel.com> <20180108173032.GD6176@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180108173032.GD6176@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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