Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751807AbeAEMNB (ORCPT + 1 other); Fri, 5 Jan 2018 07:13:01 -0500 Received: from www.llwyncelyn.cymru ([82.70.14.225]:50314 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751775AbeAEMNA (ORCPT ); Fri, 5 Jan 2018 07:13:00 -0500 Date: Fri, 5 Jan 2018 12:12:41 +0000 From: Alan Cox To: Thomas Gleixner Cc: Jon Masters , "Woodhouse, David" , Paolo Bonzini , 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: <20180105121241.497742f7@alans-desktop> In-Reply-To: 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> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, 5 Jan 2018 01:54:13 +0100 (CET) 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. There is if you are using signing and the like. I'm sure SELiux and friends will grow the ability to set per process policy but that's certainly not a priority. However the question is wrong. 'trusted' is a binary operator not a unary one. The question that matters is If I am executing A and about to switch to B does B trust A because if B trusts A (which in Linuxspeak is 'can A ptrace B') then there's not much point worrying about protection between them because what you are trying to prevent is already expressly permitted. It's even more important if there is a cost to the barrier imposition because not only can you skip it sometimes but your scheduler can schedule considering that cost just as it does cache eviction costs. Alan