Date: Wed, 10 Jan 2018 08:59:01 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Willy Tarreau <w@1wt.eu>
Cc: Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Brian Gerst <brgerst@gmail.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Kees Cook <keescook@chromium.org>
Subject: Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and
 ARCH_SET_NOPTI to enable/disable PTI
Message-ID: <20180110075901.nw4s3oktvnmbumzr@gmail.com>
References: <20180109145157.5ltqbz4o5sqkcggb@pd.tnic>
 <20180109145422.GD12976@1wt.eu>
 <CALCETrU_Qt+0k4GO2qp=9D7h5czp0QkY=D9Y4AUfs9yzpNHswQ@mail.gmail.com>
 <20180109212940.ffvqb6wmehmxre4i@pd.tnic>
 <20180109213227.GA13282@1wt.eu>
 <20180109214602.k7cuxwikg6xshztu@pd.tnic>
 <20180109220605.GE13282@1wt.eu>
 <20180109222036.6h7jjyaayusn4yb5@pd.tnic>
 <20180110073128.sv3fcmfpai4ounvk@gmail.com>
 <20180110073755.GD14066@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180110073755.GD14066@1wt.eu>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org


* Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Jan 10, 2018 at 08:31:28AM +0100, Ingo Molnar wrote:
> > 
> > * Borislav Petkov <bp@alien8.de> wrote:
> > 
> > > Oh, and you've built the kernel with the option to be able to disable
> > > PTI so it's not like you haven't seen it already.
> > 
> > In general in many corporate environments requiring kernel reboots or kernel 
> > rebuilds limits the real-world usability of any kernel feature we offer down to 
> > "non-existent". Saying "build your own kernel or reboot" is excluding a large 
> > subset of our real-world users.
> > 
> > Build and boot options are fine for developers and testing. Otherwise _everything_ 
> > not readily accessible when your distro kernel has booted up is essentially behind 
> > a usability (and corporate policy) wall so steep that it's essentially 
> > non-existent to many users.
> > 
> > So either we make this properly sysctl (and/or prctl) controllable, or just don't 
> > do it at all.
> 
> After having slept over it, I really prefer the sysctl+prctl approach.
> It's much more consistent with the rest of the tunables which act
> similarly. We have mmap_min_addr, mmap_rnd_bits, randomize_va_space, etc
> All of them are here to trade some protections for something else (mostly
> compatibility).
> 
> What I'd like to have would be a sysctl with 3 values :
>   -  0 : default disabled : arch_prctl() fails, this is the default
>   -  1 : forced enabled : arch_prctl() succeeds for CAP_SYS_RAWIO
>   - -1 : permanently disabled : fails and cannot be switched back to enabled.

Btw., I wouldn't call the value of 1 'forced enabled', it's simply enabled.

BTW., we might eventually also want to introduce a 'super flag' for all the 
permanent disabling features, so that sysadmins/distros who want to default to 
restrictive policies can set that and don't have to be aware of new tunables, and 
this also protects against renames, etc.

Thanks,

	Ingo