Re: [PATCH 0/7] IBRS patch series

[Paul Turner]

On Thu, Jan 4, 2018 at 11:33 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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_.

These are also mitigatable; the retpoline sequence itself will never
result in an RSB underflow.

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.
This does not preclude perturbing the RSB, only that it's contents
contain at least as many (non-exploitable) entries as when execution
was interrupted.
We do not need to actually track how many entries it's currently
using, because returning control to it with a full RSB, guarantees
that number of entries cannot have decreased.

>
> 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.

Or worse, that a co-executing SMT sibling is not continually refilling them.

>
>                Linus