On Fri, Jan 05, 2024, Rick P Edgecombe wrote: > On Thu, 2024-01-04 at 16:22 -0800, Sean Christopherson wrote: > > No, the days of KVM making shit up from are done. IIUC, you're advocating > > that it's ok for KVM to induce a #CP that architecturally should not > > happen. That is not acceptable, full stop. > > Nope, not advocating that at all. Heh, wrong "you". That "you" was directed at Weijiang, who I *think* is saying 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 that > 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. Yes, it's a problem. But IIUC, as is KVM would also induce bogus #CPs (which is probably less of a problem in practice, but still not acceptable). > I'm worried that there is some way attackers will induce the host to > emulate an instruction and skip CET enforcement that the HW would > normally do. Yep. The best behavior for this is likely KVM's existing behavior, i.e. retry the instruction in the guest, and if that doesn't work, kick out to userspace and let userspace try to sort things out. > > For CALL/RET (and presumably any branch instructions with IBT?) other > > 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. > > Right, that is what I was wondering might be the normal solution for > situations like this. If KVM can't emulate something, it either retries the instruction (with some 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. :-) > > Then, *if* a use case comes along where the guest is utilizing CET and > > "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. > > I think it will not be very easy. Yeah. As Jim alluded to, I think it's probably time to admit that emulating instructions for modern CPUs is a fools errand and KVM should simply stop trying.
