Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

[David Woodhouse]

On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
> 
> Note on the unhappiness with some of the patches involved: what I do
> *not* want to see is the "on every kernel entry" kind of garbage.
> 
> So my unhappiness with the intel microcode patches is two-fold:
> 
> Â(a) the interface is nasty and wrong, and I absolutely detest how Intel did it.
> 
> Â(b) the write to random MSR's on every kernel entry/exit is wrong
> 
> but that doesn't mean that I will necessarily end up NAK'ing every
> single IBRS/IBPB patch.
> 
> My concern with (a) is that unlike meltdown, the intel work-around
> isn't forward-looking, and doesn't have a "we fixed it" bit. Instead,
> it has a "we have a nasty workaround that may or may not be horribly
> expensive" bit, and isn't all that well-defined.

The lack of a "we fixed it" bit is certainly problematic.

But as an interim hack for the upcoming hardware, IBRS_ALL isn't so
badly defined. Sure, the reassurances about performance all got ripped
out before the document saw the light of day â quelle surprise? â but
my understanding is that it *will* be fast. It is expected to be fast
enough that we can ALTERNATIVE away the retpolines, set it once and
leave it set.

The reason it isn't just a "we fixed it" bit is because we'll still
need the IBPB on context/vCPU switches.

I suspect they managed to tag BTB entries with VMX mode and ring, but
*not* the full VMID/PCID tagging (and associated automatic flushing)
that they'd need to truly say "we fixed it".

I seriously hope they're working on a complete fix for the subsequent
generation, and just neglected to mention it in their public
documentation that far in advance.

> My dislike of (b) comes from "we have retpoline and various wondrous
> RSB filling crud already, we're smarter than that". So it's not that I
> refuse any IBRS/IBPB use, I refuse the stupid and _mindless_ kind of
> use.

Well... for Skylake we probably need something like Ingo's cunning plan
to abuse function tracing to count call depth. I won't be utterly
shocked if, by the time we have all that pulled together, it ends up
being fairly much as fugly as the IBRS version â for less complete
protection. But we'll see. :)

It may also be that some of the last remaining holes can be declared
just too unlikely for us to jump through fugly hoops for. In fact that
*has* to be our answer for the SMI issue if we're not using IBRS on
Skylake, so now it's just a question of degree â how many of the
*other* theoretical holes are we happy to do the same thing for?

That's a genuine question, not a rhetorical device arguing for IBRS. I
just haven't seen a clear analysis, other than some hand-waving, of how
feasible some of those attack vectors really are. I'd like to.

Attachment: smime.p7s
Description: S/MIME cryptographic signature