Messages in this thread | | | Subject | Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs | From | David Woodhouse <> | Date | Tue, 13 Feb 2018 10:53:54 +0000 |
| |
On Tue, 2018-02-13 at 11:41 +0100, Paolo Bonzini wrote: > You have my vote. :) Really, IBRS_ALL makes no sense and it would be > nice to know _why_ Intel is pushing something that makes no sense.
No, IBRS_ALL *does* make sense. It's not a complete fix, but it's as much of a fix as they should shoe-horn into the generation of CPUs which are currently going to the fabs.
With IBRS_ALL they presumably add tags to the predictions with the VMX mode and ring, to give complete protection against predictions being used in a more privileged mode. That saves us from having to do retpoline, or the horrid old IBRS-as-barrier crap. Or any of the other as-yet-incomplete Skylake hacks.
But we *do* still need the IBPB on context/VM switch. Because they *haven't* yet managed to tag with VMID/PCID and/or do appropriate flushing (on VMPTRLD, CR3 load, etc.). That will have to wait until hardware which is even further out. But it's a bone of contention that they haven't even defined the bit which will *advertise* this future behaviour.
As it stands though, as a stop-gap solution IBRS_ALL isn't completely senseless.
It *is* a shame that they didn't make the IBRS bit in SPEC_CTRL a no-op on CPUs with IBRS_ALL, but there are apparently technical reasons for that on a certain subset of CPUs.
Again, having relatively simple patches to KVM which to tolerate the IBRS bit *not* being a no-op is what makes the difference between us accepting that, and demanding a new 'IBRS_ALL_UNCONDITIONAL' bit for the CPUs which *aren't* in that "certain subset".
[unhandled content-type:application/x-pkcs7-signature] | |