On 1/5/2024 8:54 AM, Sean Christopherson wrote:
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.
My fault, I just thought of the normal execution instead of the subverting cases :-)
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'd choose to stop emulating the CET sensitive instructions while CET is enabled in guest
as re-enter guest after emulation would raise some kind of risk, but I don't know how to
stop the emulation decently.
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.
What kind of error is proper if KVM has to punt to userspace? Or just inject #UD into guest
on detecting this case?
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.
