Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757706AbeAIWlB (ORCPT + 1 other); Tue, 9 Jan 2018 17:41:01 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:39263 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753584AbeAIWlA (ORCPT ); Tue, 9 Jan 2018 17:41:00 -0500 Date: Tue, 9 Jan 2018 23:40:09 +0100 From: Willy Tarreau To: Borislav Petkov Cc: Andy Lutomirski , LKML , X86 ML , Brian Gerst , Dave Hansen , Ingo Molnar , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Josh Poimboeuf , "H. Peter Anvin" , Kees Cook Subject: Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI Message-ID: <20180109224009.GA13326@1wt.eu> References: <20180109141713.ngqrf6weyiy2q3in@pd.tnic> <20180109143653.GA12976@1wt.eu> <20180109145157.5ltqbz4o5sqkcggb@pd.tnic> <20180109145422.GD12976@1wt.eu> <20180109212940.ffvqb6wmehmxre4i@pd.tnic> <20180109213227.GA13282@1wt.eu> <20180109214602.k7cuxwikg6xshztu@pd.tnic> <20180109220605.GE13282@1wt.eu> <20180109222036.6h7jjyaayusn4yb5@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180109222036.6h7jjyaayusn4yb5@pd.tnic> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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