Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751344AbeAEHOD (ORCPT + 1 other); Fri, 5 Jan 2018 02:14:03 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:38346 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbeAEHOC (ORCPT ); Fri, 5 Jan 2018 02:14:02 -0500 Date: Fri, 5 Jan 2018 08:13:33 +0100 From: Willy Tarreau To: Dave Hansen Cc: Thomas Gleixner , Jon Masters , "Woodhouse, David" , Paolo Bonzini , Alan Cox , Linus Torvalds , Andi Kleen , Greg Kroah-Hartman , Tim Chen , Linux Kernel Mailing List , Jeff Law , Nick Clifton Subject: Re: Avoid speculative indirect calls in kernel Message-ID: <20180105071333.GA4029@1wt.eu> References: <20180104015920.1ad7b9d3@alans-desktop> <1515054014.12987.75.camel@amazon.co.uk> <403e65be-cfd1-fd08-0401-2e26470b63d4@redhat.com> <4dde456c-fd15-e768-8876-5844c8b7c455@redhat.com> <20180105064946.GA4007@1wt.eu> <44f1b753-47d3-82e3-9401-256b4beadd4f@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44f1b753-47d3-82e3-9401-256b4beadd4f@intel.com> 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 Thu, Jan 04, 2018 at 10:57:19PM -0800, Dave Hansen wrote: > On 01/04/2018 10:49 PM, Willy Tarreau wrote: > > On Fri, Jan 05, 2018 at 01:54:13AM +0100, Thomas Gleixner wrote: > >> On Thu, 4 Jan 2018, Jon Masters wrote: > >>> P.S. I've an internal document where I've been tracking "nice to haves" > >>> for later, and one of them is whether it makes sense to tag binaries as > >>> "trusted" (e.g. extended attribute, label, whatever). It was something I > >>> wanted to bring up at some point as potentially worth considering. > >> Scratch that. There is no such thing as a trusted binary. > > I disagree with you on this Thomas. "trusted" means "we agree to share the > > risk this binary takes because it's critical to our service". When you > > build a load balancing appliance on which 100% of the service is assured > > by a single executable and the rest is just config management, you'd better > > trust that process. > > So you want to run this "one binary" as fast as possible and without > mitigations in place? But, you want mitigations *available* on that > system at the same time? For what? If there's only one binary, why not > just disable the mitigations entirely? I'm not fond of running the mitigations, but given that a few sysops can connect to the machine to collect stats or counters, I think it would be better to ensure these people can't happily play with the exploits to dump stuff they shouldn't have access to. It's even easier to understand on a database or key-value server for example, where you may expect the highest performance the CPU can bring for a specific process and the rest can be mitigated and will never ever notice any performance impact at all. That's why I was saying in another thread that it would be nice over the long term if we could 1) make the mitigation dynamic, and 2) make it possible for an admin to disable it for certain processes/programs. Don't get me wrong, I'm perfectly aware that it's far from being simple and for now we need to get a reliable mitigation. I'm just saying that the performance impact is a huge loss for certain use cases and that once things settle down we should start to work on ways to recover what was lost. Regards, Willy