On 9/1/2025 3:04 PM, Xin Li wrote:
On 8/31/2025 11:34 PM, Binbin Wu wrote:
We need to inject #UD for !guest_cpu_has(X86_FEATURE_MSR_IMM)
Indeed.
Good catch!
There is a virtualization hole of this feature for the accesses to the
MSRs not
intercepted. IIUIC, there is no other control in VMX for this feature.
If the
feature is supported in hardware, the guest will succeed when it
accesses to the
MSRs not intercepted even when the feature is not exposed to the
guest, but the
guest will get #UD when access to the MSRs intercepted if KVM injects
#UD.
hpa mentioned this when I just started the work. But I managed to forget
it later... Sigh!
But I guess this is the guest's fault by not following the CPUID, KVM
should
still follow the spec?
I think we should still inject #UD when a MSR is intercepted by KVM.
For handle_wrmsr_imm(), it seems we need to check
guest_cpu_cap_has(X86_FEATURE_WRMSRNS) as well, since immediate form of
MSR write is only supported on WRMSRNS instruction.
It leads to another topic, do we need to bother checking the opcode of
the instruction on EXIT_REASON_MSR_WRITE and inject #UD when it is
WRMSRNS instuction and !guest_cpu_cap_has(X86_FEATURE_WRMSRNS)?
WRMSRNS has virtualization hole as well, but KVM at least can emulate
the architectural behavior when the write on MSRs are not pass through.
