Message-ID: <20180109224009.GA13326@1wt.eu>
Date:   Tue, 9 Jan 2018 23:40:09 +0100
From:   Willy Tarreau <w@....eu>
To:     Borislav Petkov <bp@...en8.de>
Cc:     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>,
        Ingo Molnar <mingo@...nel.org>,
        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 Tue, Jan 09, 2018 at 11:20:36PM +0100, Borislav Petkov wrote:
> On Tue, Jan 09, 2018 at 11:06:05PM +0100, Willy Tarreau wrote:
> > That's very simple : you first know you need more perf when you see the
> > name of your boss on your phone asking what's happening with the site
> 
> Ok, lemme try to understand that:
> 
> so you boot with PTI *enabled*, you don't know about the whole PTI
> fiasco and the performance impact it has because you obviously live on
> another planet, your boss calls you and *then* you start looking to
> increase performance and *then* you google and realize, shikes, you need
> to turn off PTI for a specific process. And rebooting is not an option.

Boris, please don't try to make me look like a fool when I'm trying to
explain a common process. The reality is that at many places the system's
load can easily vary 10-fold along a day, week or month. I even know a
place where just two days a year you see on graphs what looks like a wall
because previous values completely disappear. And how do sysadmins size
their infra in these environments ? They use the same sizing as what they
used last time, correcting the error margin. When the graphs are small,
they'll say "OK now that I'm running the patched kernel, the load
increased from 7 to 11%, that's not much, only 4 more percent for the fix"
(because sadly many people add percents). But once this load multiples by
10, it will be too late to figure that the old 70% did not become 74% but
110%. And yes, saying that it's the best moment to reboot so that you have
even less processing power, and you reboot each of your 10 servers only
one at a time waiting for 2 minutes while the RAID controller enumerates
the disks, it will definitely take more than 20 minutes to fix the problem.

I'm not artificially making this up, that's sadly something more common
than you probably expect in environments experiencing huge but predictible
variations.

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

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'm sorry Boris, but I really really disagree with the principle of having
to reboot to fix a performance issue which does not require such a reboot
by design and which is a pure software issue. Worse, the software decided
on purpose to kill the performance to keep you safe against risks that
some people will simply consider totally irrelevant to their use cases.

The other alternative is to continue to run 100% of the time with pti=off,
making it impossible to protect anything on the system. I regret, but quite
frankly if I have the opportunity to protect all processes but one or none
at all, I still consider the first option better overall as it significantly
reduces the surface of attack.

Thanks,
Willy

Powered by blists - more mailing lists