Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751601AbeAEEMD (ORCPT + 1 other); Thu, 4 Jan 2018 23:12:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51018 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbeAEEMB (ORCPT ); Thu, 4 Jan 2018 23:12:01 -0500 Subject: Re: Avoid speculative indirect calls in kernel To: Thomas Gleixner 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> Cc: "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 From: Jon Masters Message-ID: <9976a670-a023-ea1f-3f13-ee5253092533@redhat.com> Date: Thu, 4 Jan 2018 23:11:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 05 Jan 2018 04:12:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 01/04/2018 07:54 PM, 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 agree with your sentiment, but for those mitigations that carry a significant performance overhead (for example IBRS at the moment, and on some other architectures where we might not end up with retpolines) there /could/ be some value in leaving them on by default but allowing a sysadmin to decide to trust a given application/container and accept the risk. Sure, it's selectively weakened security, I get that. I am not necessarily advocating this, just suggesting it be discussed. [ I also totally get that you can extend variant 2 to have any application that interacts with another abuse it (even over a pipe or a socket, etc. provided they share the same cache and take untrusted data that can lead to some kind of load within a speculation window), and there are a ton of ways to still cause an attack in that case. ] Jon. -- Computer Architect | Sent from my Fedora powered laptop