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".
Description: S/MIME cryptographic signature