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. 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. 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. > > Retrying the instruction in the guest, exiting to userspace, and even > terminating > the VM are all perfectly acceptable behaviors if KVM encounters > something it can't > *correctly* emulate. But clobbering the shadow stack or not > detecting a CFI > violation, even if the guest is misbehaving, is not ok. > [snip] > Yeah, I don't even know what the TRACKER bit does (I don't feel like > reading the > SDM right now), let alone if what KVM does or doesn't do in response > is remotely > correct. > > 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. > > 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.
