On Mon, Feb 24, 2025, Sean Christopherson wrote:
> On Mon, Feb 24, 2025, Tom Lendacky wrote:
> > On 2/24/25 16:55, Sean Christopherson wrote:
> > > On Mon, Feb 24, 2025, Tom Lendacky wrote:
> > >> On 2/18/25 19:26, Sean Christopherson wrote:
> > >>> -void pre_sev_run(struct vcpu_svm *svm, int cpu)
> > >>> +int pre_sev_run(struct vcpu_svm *svm, int cpu)
> > >>> {
> > >>> struct svm_cpu_data *sd = per_cpu_ptr(&svm_data, cpu);
> > >>> - unsigned int asid = sev_get_asid(svm->vcpu.kvm);
> > >>> + struct kvm *kvm = svm->vcpu.kvm;
> > >>> + unsigned int asid = sev_get_asid(kvm);
> > >>> +
> > >>> + /*
> > >>> + * Terminate the VM if userspace attempts to run the vCPU with an
> > >>> + * invalid VMSA, e.g. if userspace forces the vCPU to be RUNNABLE after
> > >>> + * an SNP AP Destroy event.
> > >>> + */
> > >>> + if (sev_es_guest(kvm) && !VALID_PAGE(svm->vmcb->control.vmsa_pa)) {
> > >>> + kvm_vm_dead(kvm);
> > >>> + return -EIO;
> > >>> + }
> > >>
> > >> If a VMRUN is performed with the vmsa_pa value set to INVALID_PAGE, the
> > >> VMRUN will fail and KVM will dump the VMCB and exit back to userspace
> > >
> > > I haven't tested, but based on what the APM says, I'm pretty sure this would crash
> > > the host due to a #GP on VMRUN, i.e. due to the resulting kvm_spurious_fault().
> > >
> > > IF (rAX contains an unsupported physical address)
> > > EXCEPTION [#GP]
> >
> > Well that's for the VMCB, the VMSA is pointed to by the VMCB and results
> > in a VMEXIT code of -1 if you don't supply a proper page-aligned,
> > physical address.
>
> Ah, good to know (and somewhat of a relief :-) ).
If anyone else was wondering, the behavior is described in the "VMRUN Page Checks"
table, which "Table 15-4" in the March 2024 version of the APM.
FWIW, knowing that VMRUN is supposed to handle this scenario does make me somewhat
tempted to skip this patch entirely. But I still don't like the idea of doing
VMRUN with a known bad address.
