From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "Woodhouse, David" <dwmw@amazon.co.uk>
Cc: "tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"arjan.van.de.ven@intel.com" <arjan.van.de.ven@intel.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"aarcange@redhat.com" <aarcange@redhat.com>,
"luto@kernel.org" <luto@kernel.org>,
"dave.hansen@intel.com" <dave.hansen@intel.com>
Subject: Re: [PATCH 5/7] x86: Use IBRS for firmware update path
Date: Fri, 5 Jan 2018 17:08:48 +0100 [thread overview]
Message-ID: <20180105160848.GD17349@kroah.com> (raw)
In-Reply-To: <1515096535.29312.38.camel@amazon.co.uk>
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 <dwmw@amazon.co.uk>
> > >
> > > 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
next prev parent reply other threads:[~2018-01-05 16:08 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 17:56 [PATCH 0/7] IBRS patch series Tim Chen
2018-01-04 17:56 ` [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation Tim Chen
2018-01-04 19:58 ` Greg KH
2018-01-04 20:47 ` Tim Chen
2018-01-05 11:14 ` David Woodhouse
2018-01-05 15:14 ` Tom Lendacky
2018-01-05 17:07 ` Tim Chen
2018-01-05 13:09 ` Thomas Gleixner
2018-01-05 13:44 ` Andrea Arcangeli
2018-01-05 13:51 ` Thomas Gleixner
2018-01-04 17:56 ` [PATCH 2/7] x86/enter: MACROS to set/clear IBRS Tim Chen
2018-01-04 22:16 ` Peter Zijlstra
2018-01-04 22:21 ` Tim Chen
2018-01-04 22:23 ` Dave Hansen
2018-01-05 4:54 ` Andy Lutomirski
2018-01-05 5:05 ` Dave Hansen
2018-01-05 13:19 ` Thomas Gleixner
2018-01-04 17:56 ` [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts Tim Chen
2018-01-04 20:00 ` Greg KH
2018-01-04 20:26 ` Tim Chen
2018-01-04 20:45 ` Dave Hansen
2018-01-04 22:33 ` Peter Zijlstra
2018-01-04 23:12 ` Andrea Arcangeli
2018-01-05 0:08 ` Dave Hansen
2018-01-05 4:51 ` Andy Lutomirski
2018-01-05 5:11 ` Dave Hansen
2018-01-05 12:01 ` Alan Cox
2018-01-05 13:35 ` Thomas Gleixner
2018-01-04 17:56 ` [PATCH 4/7] x86/idle: Disable IBRS entering idle and enable it on wakeup Tim Chen
2018-01-04 22:47 ` Peter Zijlstra
2018-01-04 23:00 ` Andrea Arcangeli
2018-01-04 23:22 ` Tim Chen
2018-01-04 23:42 ` Andrea Arcangeli
2018-01-04 23:45 ` Thomas Gleixner
2018-01-05 0:03 ` Andrea Arcangeli
2018-01-08 8:24 ` Peter Zijlstra
2018-01-04 17:56 ` [PATCH 5/7] x86: Use IBRS for firmware update path Tim Chen
2018-01-04 18:48 ` Alan Cox
2018-01-04 20:05 ` Greg KH
2018-01-04 20:08 ` Woodhouse, David
2018-01-05 16:08 ` gregkh [this message]
2018-01-05 16:37 ` Andrea Arcangeli
2018-01-04 20:21 ` Andrew Cooper
2018-01-04 20:48 ` Andrea Arcangeli
2018-01-04 20:51 ` Yves-Alexis Perez
2018-01-04 21:13 ` Tim Chen
2018-01-04 22:51 ` Peter Zijlstra
2018-01-05 13:40 ` Thomas Gleixner
2018-01-04 17:56 ` [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature Tim Chen
2018-01-04 18:33 ` Borislav Petkov
2018-01-04 18:36 ` Dave Hansen
2018-01-04 18:52 ` Borislav Petkov
2018-01-04 18:57 ` Andrea Arcangeli
2018-01-04 18:59 ` Dave Hansen
2018-01-04 19:06 ` Borislav Petkov
2018-01-05 13:48 ` Thomas Gleixner
2018-01-04 18:38 ` Andrea Arcangeli
2018-01-04 18:54 ` Dave Hansen
2018-01-04 18:56 ` Borislav Petkov
2018-01-04 18:55 ` Borislav Petkov
2018-01-04 18:34 ` Andrea Arcangeli
2018-01-04 19:02 ` Tim Chen
2018-01-04 18:50 ` Alan Cox
2018-01-04 20:16 ` Greg KH
2018-01-04 20:58 ` Tim Chen
2018-01-04 22:54 ` Peter Zijlstra
2018-01-04 23:26 ` Tim Chen
2018-01-04 23:51 ` Andrea Arcangeli
2018-01-04 23:59 ` Borislav Petkov
2018-01-05 0:07 ` Thomas Gleixner
2018-01-05 11:16 ` David Woodhouse
2018-01-06 1:29 ` Tim Chen
2018-01-04 17:56 ` [PATCH 7/7] x86/microcode: Recheck IBRS features on microcode reload Tim Chen
2018-01-04 18:28 ` Borislav Petkov
2018-01-04 18:34 ` Andrea Arcangeli
2018-01-04 18:50 ` Borislav Petkov
2018-01-04 19:10 ` Tim Chen
2018-01-05 13:32 ` Greg KH
2018-01-05 13:37 ` Borislav Petkov
2018-01-05 13:47 ` Greg KH
2018-01-05 15:28 ` Andrea Arcangeli
2018-01-04 19:00 ` [PATCH 0/7] IBRS patch series Linus Torvalds
2018-01-04 19:19 ` David Woodhouse
2018-01-04 19:33 ` Linus Torvalds
2018-01-04 19:39 ` David Woodhouse
2018-01-04 19:40 ` Andrew Cooper
2018-01-04 19:46 ` David Woodhouse
2018-01-04 21:22 ` Van De Ven, Arjan
2018-01-05 11:32 ` Paolo Bonzini
2018-01-05 12:09 ` Paul Turner
2018-01-05 14:45 ` Van De Ven, Arjan
2018-01-05 14:43 ` Andrea Arcangeli
2018-01-05 14:52 ` Van De Ven, Arjan
2018-01-05 15:03 ` Andrea Arcangeli
2018-01-05 14:54 ` Thomas Gleixner
2018-01-05 11:52 ` Paul Turner
2018-01-05 14:28 ` David Woodhouse
2018-01-05 14:42 ` Van De Ven, Arjan
2018-01-05 15:38 ` David Woodhouse
2018-01-05 16:05 ` Andrea Arcangeli
2018-01-05 16:37 ` David Woodhouse
2018-01-05 16:42 ` Andrea Arcangeli
2018-01-05 16:44 ` Van De Ven, Arjan
2018-01-05 16:46 ` David Woodhouse
2018-01-05 5:25 ` Florian Weimer
2018-01-05 11:05 ` David Woodhouse
2018-01-04 19:05 ` Justin Forbes
2018-01-04 19:10 ` Tim Chen
2018-01-04 21:01 ` Yves-Alexis Perez
2018-01-05 13:28 ` Greg KH
2018-01-05 13:47 ` Yves-Alexis Perez
2018-01-05 14:01 ` Greg KH
2018-01-05 14:26 ` Paolo Bonzini
2018-01-05 14:54 ` Yves-Alexis Perez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180105160848.GD17349@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox