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 <[email protected]> > > > > > > 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
