lkml.org 
[lkml]   [2018]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2018-01-14 23:20    [W:0.084 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site