On Mon, 2024-07-08 at 11:46 -0700, Sean Christopherson wrote: > On Thu, Jul 04, 2024, Maxim Levitsky wrote: > > On Fri, 2024-05-17 at 10:38 -0700, Sean Christopherson wrote: > > > diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h > > > index 23dbb9eb277c..0a8b561b5434 100644 > > > --- a/arch/x86/kvm/cpuid.h > > > +++ b/arch/x86/kvm/cpuid.h > > > @@ -11,6 +11,7 @@ > > > extern u32 kvm_cpu_caps[NR_KVM_CPU_CAPS] __read_mostly; > > > void kvm_set_cpu_caps(void); > > > > > > +void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu); > > > void kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu); > > > void kvm_update_pv_runtime(struct kvm_vcpu *vcpu); > > > struct kvm_cpuid_entry2 *kvm_find_cpuid_entry_index(struct kvm_vcpu *vcpu, > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > > index d750546ec934..7adcf56bd45d 100644 > > > --- a/arch/x86/kvm/x86.c > > > +++ b/arch/x86/kvm/x86.c > > > @@ -12234,6 +12234,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > > > kvm_xen_init_vcpu(vcpu); > > > kvm_vcpu_mtrr_init(vcpu); > > > vcpu_load(vcpu); > > > + kvm_vcpu_after_set_cpuid(vcpu); > > > > This makes me a bit nervous. At this point the vcpu->arch.cpuid_entries is > > NULL, but so is vcpu->arch.cpuid_nent so it sort of works but is one mistake > > away from crash. > > > > Maybe we should add some protection to this, e.g empty zero cpuid or > > something like that. > > Hmm, a crash is actually a good thing. In the post-KVM_SET_CPUID2 case, if KVM > accessed vcpu->arch.cpuid_entries without properly consulting cpuid_nent, the > resulting failure would be a out-of-bounds read. Similarly, a zeroed CPUID array > would effectiely mask any bugs. > > Given that KVM heavily relies on "vcpu" to be zero-allocated, and that changing > cpuid_nent during kvm_arch_vcpu_create() would be an extremely egregious bug, > a crash due to a NULL-pointer dereference should never escape developer testing, > let alone full release testing. > > KVM does the "empty" array thing for IRQ routing (though in that case the array > and the nr_entries are in a single struct), and IMO it's been a huge net negative > because it's led to increased complexity just so that arch code can omit a NULL > check. > Makes sense, let it be. Best regards, Maxim Levitsky
