Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI

From: Ingo Molnar
Date: Wed Jan 10 2018 - 02:59:13 EST



* Willy Tarreau <w@xxxxxx> wrote:

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