lkml.org 
[lkml]   [2018]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch
From
Date
On Mon, 2018-01-08 at 16:35 -0800, Linus Torvalds wrote:
> On Mon, Jan 8, 2018 at 3:58 PM, Woodhouse, David <dwmw@amazon.co.uk> wrote:
> >>
> >> Is there really nothing more clever we can do?
> >
> > You get this part in the IBRS/microcode solution too. The IBRS MSR
> > doesn't catch everything; you still need to stuff the RSB in very
> > similar places (and/or use the IBPB MSR in some).
>
> So I was really hoping that in places like context switching etc, we'd
> be able to instead effectively kill off any exploits by clearing
> registers.
>
> That should make it pretty damn hard to then find a matching "gadget"
> that actually does anything interesting/powerful.
>
> Together with Spectre already being pretty hard to take advantage of,
> and the eBPF people making those user-proivided gadgets inaccessible,
> it really should be a pretty powerful fix.

Hm... on a context switch you're reloading the registers that were in
the other saved context. If the attacker does something they know will
go into a deep call stack and then sleep, and they pollute the BTB for
every 'ret' instruction in that stack¹, then the registers at the time
a 'ret' goes AWOL are not necessarily something you can 'clear' at the
time of the context switch.

And yes, a lot of this v2 stuff down past the sys_call_table branch
really *is* pretty damn hard already, especially the 'ret' based ones.

¹ perhaps they do the BTB-pollution in their other CPU-hogging thread
  that runs on the same CPU when the attack thread is sleeping? I'm not
  really trying to actually write an attack here, just thinking out
  loud and being uncertain that you've actually proved there *isn't*
  one :)[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2018-01-14 23:18    [W:0.120 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site