On 1/6/2024 12:21 AM, Sean Christopherson wrote:
On Fri, Jan 05, 2024, Weijiang Yang wrote:
On 1/5/2024 8:54 AM, Sean Christopherson wrote:
On Fri, Jan 05, 2024, Rick P Edgecombe wrote:
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?
KVM_INTERNAL_ERROR_EMULATION. See prepare_emulation_failure_exit().
Or just inject #UD into guest on detecting this case?
No, do not inject #UD or do anything else that deviates from architecturally
defined behavior.
Thanks!
But based on current KVM implementation and patch 24, seems that if CET is exposed
to guest, the emulation code or shadow paging mode couldn't be activated at the same time:
In vmx.c,
hardware_setup(void):
if (!cpu_has_vmx_unrestricted_guest() || !enable_ept)
enable_unrestricted_guest = 0;
in vmx_set_cr0():
[...]
if (enable_unrestricted_guest)
hw_cr0 |= KVM_VM_CR0_ALWAYS_ON_UNRESTRICTED_GUEST;
else {
hw_cr0 |= KVM_VM_CR0_ALWAYS_ON;
if (!enable_ept)
hw_cr0 |= X86_CR0_WP;
if (vmx->rmode.vm86_active && (cr0 & X86_CR0_PE))
enter_pmode(vcpu);
if (!vmx->rmode.vm86_active && !(cr0 & X86_CR0_PE))
enter_rmode(vcpu);
}
[...]
And in patch 24:
+ if (!cpu_has_load_cet_ctrl() || !enable_unrestricted_guest ||
+ !cpu_has_vmx_basic_no_hw_errcode()) {
+ kvm_cpu_cap_clear(X86_FEATURE_SHSTK);
+ kvm_cpu_cap_clear(X86_FEATURE_IBT);
+ }
Not sure if I missed anything.
