On Tue, Feb 14, 2023, Like Xu wrote:
> On 10/2/2023 8:31 am, Sean Christopherson wrote:
> > @@ -2168,6 +2187,23 @@ static int do_get_msr(struct kvm_vcpu *vcpu, unsigned index, u64 *data)
> > static int do_set_msr(struct kvm_vcpu *vcpu, unsigned index, u64 *data)
> > {
> > + u64 val;
> > +
> > + /*
> > + * Disallow writes to immutable feature MSRs after KVM_RUN. KVM does
> > + * not support modifying the guest vCPU model on the fly, e.g. changing
> > + * the nVMX capabilities while L2 is running is nonsensical. Ignore
> > + * writes of the same value, e.g. to allow userspace to blindly stuff
> > + * all MSRs when emulating RESET.
> > + */
> > + if (vcpu->arch.last_vmentry_cpu != -1 &&
>
> Three concerns on my mind (to help you think more if any):
> - why not using kvm->created_vcpus;
Because this is a vCPU scoped ioctl().
> - how about different vcpu models of the same guest have different
> feature_msr values;
KVM shouldn't care. If KVM does care, then that's a completely orthogonal bug
that needs to be fixed separately.
> (although they are not altered after the first run, cases (selftests) may be
> needed to
> show that it is dangerous for KVM);
>
> - the relative time to set "vcpu->arch.last_vmentry_cpu = vcpu->cpu" is
> still too late,
> since part of the guest code (an attack window) has already been executed on first
> run of kvm_x86_vcpu_run() which may run for a long time;
Again, this is a vCPU scoped ioctl. The task doing KVM_RUN holds vcpu->mutex so
there is no race.
