linux-kernel - Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1515458545.4423.76.camel@infradead.org>
Date:   Tue, 09 Jan 2018 00:42:25 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "riel@...hat.com" <riel@...hat.com>,
        "keescook@...gle.com" <keescook@...gle.com>,
        "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "pjt@...gle.com" <pjt@...gle.com>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "luto@...capital.net" <luto@...capital.net>,
        "jikos@...nel.org" <jikos@...nel.org>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>
Subject: Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows
 on context switch

On Mon, 2018-01-08 at 16:35 -0800, Linus Torvalds wrote:
> On Mon, Jan 8, 2018 at 3:58 PM, Woodhouse, David <dwmw@...zon.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 :)
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)