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: <20180110073755.GD14066@1wt.eu>
Date:   Wed, 10 Jan 2018 08:37:55 +0100
From:   Willy Tarreau <w@....eu>
To:     Ingo Molnar <mingo@...nel.org>
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

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.

This way the admin always has the last choice, it's possible to globally
disable it without having to fear that someone would enable it again if
desired, and it's possible to try if it helps without rebooting in
emergency situations.

Willy