Messages in this thread | | | Date | Wed, 10 Jan 2018 08:59:01 +0100 | From | Ingo Molnar <> | 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@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
| |