linux-kernel - Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET

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: <20180110075901.nw4s3oktvnmbumzr@gmail.com>
Date:   Wed, 10 Jan 2018 08:59:01 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Brian Gerst <brgerst@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>
Subject: Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and
 ARCH_SET_NOPTI to enable/disable PTI


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

> On Wed, Jan 10, 2018 at 08:31:28AM +0100, Ingo Molnar wrote:
> > 
> > * Borislav Petkov <bp@...en8.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