Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751389AbeAEG4m (ORCPT + 1 other); Fri, 5 Jan 2018 01:56:42 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:38336 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbeAEG4l (ORCPT ); Fri, 5 Jan 2018 01:56:41 -0500 Date: Fri, 5 Jan 2018 07:49:46 +0100 From: Willy Tarreau To: Thomas Gleixner Cc: Jon Masters , "Woodhouse, David" , Paolo Bonzini , Alan Cox , Linus Torvalds , Andi Kleen , Greg Kroah-Hartman , Tim Chen , Linux Kernel Mailing List , Dave Hansen , Jeff Law , Nick Clifton Subject: Re: Avoid speculative indirect calls in kernel Message-ID: <20180105064946.GA4007@1wt.eu> References: <20180103230934.15788-1-andi@firstfloor.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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. If the binary or process cannot be trusted, the product is dead anyway. It doesn't mean the binary is safe. It just means that for the product there's nothing worse than its compromission or failure. And when it suffers from the performance impact of workarounds supposed to protect the whole device against this process' possible abuses, you easily see how the situation becomes ridiculous. We need to still think about performance a lot. There's already an ongoing trend of kernel bypass mechanisms in the wild for performance reasons, and the new increase of syscall costs will necessarily amplify this willingness to avoid the kernel. I personally don't want to see the kernel being reduced to booting and executing SSH to manage the machines. Willy