[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0575AF4FD06DD142AD198903C74E1CC87A56B309@ORSMSX103.amr.corp.intel.com>
Date: Fri, 5 Jan 2018 14:42:42 +0000
From: "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
To: David Woodhouse <dwmw2@...radead.org>,
Paul Turner <pjt@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.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
> > So long as the underlying binary satisfies the precondition that it
> > will not underflow its own RSB.
> >
> > Then we if we subsequently guarantee never to _reduce_ the number of
> > entries in its RSB at any point remote to its own execution, then the
> > precondition is preserved and underflow will not occur.
>
> The problem is that underflow can occur not only on a retpoline, but
> also on *any* bare ret.
that is not true though
yes there's NMIs and interrupts but those Paul managed.
the cases where underflow can happen are not infinite or unbound, but a specific set of causes as Paul already mentioned.
Now there is complexity in proving that all that is there, and if you're that paranoid, IBRS is certainly an option and the performance, while not nearly as good as retpoline, is not horrid either on Skylake.
This is why I said I would like to see retpoline be the default, with IBRS an opt-in for the paranoid. I guess David will turn that on ;-)
Powered by blists - more mailing lists