Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752921AbeADLye (ORCPT + 1 other); Thu, 4 Jan 2018 06:54:34 -0500 Received: from www.llwyncelyn.cymru ([82.70.14.225]:44376 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752783AbeADLyd (ORCPT ); Thu, 4 Jan 2018 06:54:33 -0500 Date: Thu, 4 Jan 2018 11:54:07 +0000 From: Alan Cox To: Pavel Machek Cc: Linus Torvalds , Andi Kleen , tglx@linuxtronix.de, Greg Kroah-Hartman , dwmw@amazon.co.uk, Tim Chen , Linux Kernel Mailing List , Dave Hansen Subject: Re: Avoid speculative indirect calls in kernel Message-ID: <20180104115407.51e1c032@alans-desktop> In-Reply-To: <20180104112614.GA1702@amd> References: <20180103230934.15788-1-andi@firstfloor.org> <20180104112614.GA1702@amd> 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 Thu, 4 Jan 2018 12:26:14 +0100 Pavel Machek wrote: > On Wed 2018-01-03 15:51:35, Linus Torvalds wrote: > > On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen wrote: > > > This is a fix for Variant 2 in > > > https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html > > > > > > Any speculative indirect calls in the kernel can be tricked > > > to execute any kernel code, which may allow side channel > > > attacks that can leak arbitrary kernel data. > > > > Why is this all done without any configuration options? > > > > A *competent* CPU engineer would fix this by making sure speculation > > doesn't happen across protection domains. Maybe even a L1 I$ that is > > keyed by CPL. > > Would that be enough? For the entire system - no. To start with the current most dangerous attack is the javascript one. And that is an attack by a process on itself. Likewise simply keying L1I by CPL wouldn't stop ring 3 processes attacking one another or deal with virtual machines properly. For some of those cases (notably the JIT ones) it's quite probable that there isn't enough information for the processor to even infer what is needed. Alan