Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752262AbeAEQIt (ORCPT + 1 other); Fri, 5 Jan 2018 11:08:49 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:59246 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752038AbeAEQIr (ORCPT ); Fri, 5 Jan 2018 11:08:47 -0500 Date: Fri, 5 Jan 2018 17:08:48 +0100 From: "gregkh@linuxfoundation.org" To: "Woodhouse, David" Cc: "tim.c.chen@linux.intel.com" , "linux-kernel@vger.kernel.org" , "arjan.van.de.ven@intel.com" , "torvalds@linux-foundation.org" , "tglx@linutronix.de" , "ak@linux.intel.com" , "aarcange@redhat.com" , "luto@kernel.org" , "dave.hansen@intel.com" Subject: Re: [PATCH 5/7] x86: Use IBRS for firmware update path Message-ID: <20180105160848.GD17349@kroah.com> References: <8d3710432534b27d224283557c4629cd1aa5b0ea.1515086770.git.tim.c.chen@linux.intel.com> <20180104200515.GC30228@kroah.com> <1515096535.29312.38.camel@amazon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1515096535.29312.38.camel@amazon.co.uk> User-Agent: Mutt/1.9.2 (2017-12-15) 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 08:08:55PM +0000, Woodhouse, David wrote: > On Thu, 2018-01-04 at 21:05 +0100, Greg KH wrote: > > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > > > > > From: David Woodhouse > > > > > > We are impervious to the indirect branch prediction attack with > > > retpoline > > > but firmware won't be, so we still need to set IBRS to protect > > > firmware code execution when calling into firmware at runtime. > > Wait, what? > > > > Maybe it's just the wine from dinner talking, but if the firmware has > > issues, we have bigger things to worry about here, right???It already > > handed over the "chain of trust" to us, so we have already implicitly > > trusted that the firmware was correct here.??So why do we need to do > > anything about firmware calls in this manner? > > In the ideal world, firmware exists to boot the kernel and then it gets > out of the way, never to be thought of again. > > In the Intel world, firmware idiocy permeates everything and we > sometimes end up making calls to it at runtime. > > If an attacker can poison the BTB for an indirect branch in EFI > firmware, then reliably do something which calls EFI runtime calls, > that might lead to an exploit. So if we're using retpoline for the > kernel, then we should be setting IBRS before any firmware calls. Ugh, ok, seems a bit far-fetched to me, but I will not object anymore. Except that the patch doesn't actually build, which means no one has actually tested it at all :( greg k-h