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>]

Hi Boris!

On Wed, Jan 10, 2018 at 03:42:39PM +0100, Borislav Petkov wrote:
> On Tue, Jan 09, 2018 at 11:40:09PM +0100, Willy Tarreau wrote:
> > Boris, please don't try to make me look like a fool when I'm trying to
> > explain a common process.
> 
> I haven't even intended to do that, sorry, maybe you're misunderstanding
> me.

OK no worries :-)

> > No, your distro did. Please keep in mind that you were the one asking me
> > to have this option so that distros can enable it to please their users,
> > or possibly in fact to remove it to please the competitors.
> 
> ... I was asking for this so that I can completely keep the code out of the
> built kernel but from reading this thread, it sounds to me like we'd
> need the full spectrum of options:
> 
> 1. prohibit disabling of PTI
> 2. per-process PTI disabling
> 3. disable PTI on the system
> 
> and then show people how to do that and do that at runtime. Apparently,
> it is important to people to be able to control that.

It suddenly comes to my mind that this sysctl I suggested this morning
could in fact serve both purposes and be easier to understand, with 4
values. But in fact I hardly find a valid reason for disabling it for
the whole system via a sysctl (I could be proven wrong though). For
example, when building a load generator for my lab I can easily build
my kernels without PTI and/or have pti=off on the cmdline, that's fine.

For production, disabling PTI system-wide when I'm supposed to know what
performance critical processes should be exempted doesn't appeal me very
much, especially if it can happen by accident. So in the end I think that
"pti=off" on the cmdline should be the only way to disable it system-wide
as it doesn't represent a reasonable production case. Disabling it per
process should be allowed via a sysctl, which would also be locked disabled
for safety purposes.

I'll go work on something like this to illustrate better, as I'm well
aware that I never explain well what I'm thinking about.

> And also explain what each option means so that they can evaluate
> themselves what they'd prefer.

Clear explanations are an important part of the solution, as we want
it to be safe by default and only let knowledgeable people turn it off
on purpose.

Thanks,
Willy