Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754162AbeAKGnn (ORCPT + 1 other); Thu, 11 Jan 2018 01:43:43 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:39556 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753896AbeAKGnm (ORCPT ); Thu, 11 Jan 2018 01:43:42 -0500 Date: Thu, 11 Jan 2018 07:42:59 +0100 From: Willy Tarreau To: Linus Torvalds Cc: Andy Lutomirski , Peter Zijlstra , LKML , X86 ML , Borislav Petkov , Brian Gerst , Dave Hansen , Ingo Molnar , Thomas Gleixner , Josh Poimboeuf , "H. Peter Anvin" , Greg Kroah-Hartman , Kees Cook Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set Message-ID: <20180111064259.GC14920@1wt.eu> References: <1515502580-12261-1-git-send-email-w@1wt.eu> <1515502580-12261-7-git-send-email-w@1wt.eu> <20180110082207.GX29822@worktop.programming.kicks-ass.net> <20180110091102.GH14066@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jan 10, 2018 at 11:50:46AM -0800, Linus Torvalds wrote: > And the whole "NOW" vs "NEXT" is complete garbage. The obvious sane > no-PTI interface is that it > > (a) inherits on fork/exec, so that you don't have to worry about how > something is implemented (think "I want to run this kernel build > without the PTI overhead", but also "I want to run this system daemon > without PTI"). > > (b) actual domain changes clear it (ie suid, whatever). > > that make it useful for random uses of "I trust service XYZ". OK. Do you want to see something *only* based on a wrapper (i.e. works only after execve) or can we let the application apply the change to itself ? I would also like to let applications re-enable the protection for processes they're going to exec and not necessarily trust. > So I'm NAK'ing this whole series on the grounds that it has several > completely insane semantics and really need to be clarified, and where > actual usage needs to be thought about a lot more. In fact we were trying to limit the risk of propagating the protection removal too far, and leave it only on the sensitive process which really requires it. But your example of "running the kernel build without PTI" makes sense from a user's perspective, and it completely contradicts our initial assumptions. After all I don't think the NOW vs NEXT is so fundamentally broken. We could think about having one option for the current process only (which is cleared by execve) so that applications can apply it to themselves only without having to wonder about clearing it, and another one which is only for wrappers and which passes execve(). For now I considered that we could stop at the first execve, but if I just remove the clearing of the NEXT flag, it matches your requirement for the kernel build. After this it's just a matter of naming and placing them on the mm rather than thread. Willy