On 04/01/18 19:33, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse <dw...@infradead.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_. > > Remember: it's not mispredicts that leak information. It's *exploits" > that use forced very specific mispredicts to leak information. > > There's a big difference there. And I think patch authors should keep > that difference in mind. > > For example, flushing the BTB at kernel entry doesn't mean that later > in-kernel indirect branches don't get predicted, and doesn't even mean > that they don't get mis-predicted. It only means that an exploit can't > pre-populate those things and use them for exploits.
Retpoline as a mitigation strategy swaps indirect branches for returns, to avoid using predictions which come from the BTB, as they can be poisoned by an attacker. The problem with Skylake+ is that an RSB underflow falls back to using a BTB prediction, which allows the attacker to take control of speculation. Also remember that sibling threads share a BTB, so you can't rely on isolated straight-line codepath on the current cpu for safety. (e.g. by issuing an IBPB on every entry to supervisor mode). ~Andrew