[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0575AF4FD06DD142AD198903C74E1CC87A56A873@ORSMSX103.amr.corp.intel.com>
Date: Thu, 4 Jan 2018 21:22:34 +0000
From: "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
David Woodhouse <dwmw2@...radead.org>
CC: Tim Chen <tim.c.chen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...nel.org>,
Greg KH <gregkh@...uxfoundation.org>,
"Hansen, Dave" <dave.hansen@...el.com>,
"Andrea Arcangeli" <aarcange@...hat.com>,
Andi Kleen <ak@...ux.intel.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/7] IBRS patch series
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse <dwmw2@...radead.org>
> wrote:
> >
> > On Skylake the target for a 'ret' instruction may also come from the
> > BTB. So if you ever let the RSB (which remembers where the 'call's came
> > from get empty, you end up vulnerable.
>
> That sounds like it could cause mispredicts, but it doesn't sound _exploitable_.
>
> Sure, interrupts in between the call instruction and the 'ret' could
> overflow the return stack. And we could migrate to another CPU. And so
> apparently SMM clears the return stack too.
>
> ... but again, none of them sound even remotely _exploitable_.
>
this is about a level of paranoia you are comfortable with.
Retpoline on Skylake raises the bar for the issue enormously, but there are a set of corner cases that exist and that are not trivial to prove you dealt with them.
personally I am comfortable with retpoline on Skylake, but I would like to have IBRS as an opt in for the paranoid.
Powered by blists - more mailing lists