linux-kernel - Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180109220605.GE13282@1wt.eu>
Date:   Tue, 9 Jan 2018 23:06:05 +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 10:46:02PM +0100, Borislav Petkov wrote:
> On Tue, Jan 09, 2018 at 10:32:27PM +0100, Willy Tarreau wrote:
> > Requiring a reboot just to fix a performance problem you've discovered
> > the hard way is not the most friendly way to help users I'm afraid.
> 
> That's a very strange argument: if you know you'd need max perf, you
> boot with pti=allow_optout.
> 
> Color me confused.

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
suddenly crawling at the worst possible moment, when everyone is there
to see it dead. Performance is something that's tuned at runtime, always,
not via random reboots. When you have 10 servers running at 100% CPU,
the last thing you're thinking about is to remove one of them so that
the 9 remaining ones are at 110% while you reboot :-/

Willy