On Fri, Jan 05, 2024, Rick P Edgecombe wrote:
On Thu, 2024-01-04 at 16:22 -0800, Sean Christopherson wrote:Heh, wrong "you". That "you" was directed at Weijiang, who I *think* is saying
No, the days of KVM making shit up from are done. IIUC, you're advocatingNope, not advocating that at all.
that it's ok for KVM to induce a #CP that architecturally should not
happen. That is not acceptable, full stop.
that clobbering the shadow stack by emulating CALL+RET and thus inducing a bogus
#CP in the guest is ok.
I'm noticing that in this series KVM has special emulator behavior thatYes, it's a problem. But IIUC, as is KVM would also induce bogus #CPs (which is
doesn't match the HW when CET is enabled. That it *skips* emitting #CPs (and
other CET behaviors SW depends on), and wondering if it is a problem.
probably less of a problem in practice, but still not acceptable).
I'm worried that there is some way attackers will induce the host toYep. The best behavior for this is likely KVM's existing behavior, i.e. retry
emulate an instruction and skip CET enforcement that the HW would
normally do.
the instruction in the guest, and if that doesn't work, kick out to userspace and
let userspace try to sort things out.
If KVM can't emulate something, it either retries the instruction (with someFor CALL/RET (and presumably any branch instructions with IBT?) otherRight, that is what I was wondering might be the normal solution for
instructions that are directly affected by CET, the simplest thing would
probably be to disable those in KVM's emulator if shadow stacks and/or IBT
are enabled, and let KVM's failure paths take it from there.
situations like this.
decent logic to guard against infinite retries) or punts to userspace.
Or if the platform owner likes to play with fire and doesn't enable
KVM_CAP_EXIT_ON_EMULATION_FAILURE, KVM will inject a #UD (and still exit to
userspace if the emulation happened at CPL0). And yes, that #UD is 100% KVM
making shit up, and yes, it has caused problems and confusion. :-)
Yeah. As Jim alluded to, I think it's probably time to admit that emulatingThen, *if* a use case comes along where the guest is utilizing CET andI think it will not be very easy.
"needs" KVM to emulate affected instructions, we can add the necessary
support the emulator.
Alternatively, if teaching KVM's emulator to play nice with shadow stacks
and IBT is easy-ish, just do that.
instructions for modern CPUs is a fools errand and KVM should simply stop trying.