On Tue, Jan 11, 2022 at 11:16 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > On Tue, Jan 11, 2022 at 10:52 AM Raghavendra Rao Ananta > <rananta@xxxxxxxxxx> wrote: > > > > On Mon, Jan 10, 2022 at 3:57 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > > > > > On Mon, Jan 10, 2022 at 3:07 PM Raghavendra Rao Ananta > > > <rananta@xxxxxxxxxx> wrote: > > > > > > > > On Fri, Jan 7, 2022 at 4:05 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > > > > > > > > > On Fri, Jan 7, 2022 at 3:43 PM Raghavendra Rao Ananta > > > > > <rananta@xxxxxxxxxx> wrote: > > > > > > > > > > > > Hi Reiji, > > > > > > > > > > > > On Thu, Jan 6, 2022 at 10:07 PM Reiji Watanabe <reijiw@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > Hi Raghu, > > > > > > > > > > > > > > On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta > > > > > > > <rananta@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > Capture the start of the KVM VM, which is basically the > > > > > > > > start of any vCPU run. This state of the VM is helpful > > > > > > > > in the upcoming patches to prevent user-space from > > > > > > > > configuring certain VM features after the VM has started > > > > > > > > running. > > > > > > > > > > What about live migration, where the VM has already technically been > > > > > started before the first call to KVM_RUN? > > > > > > > > My understanding is that a new 'struct kvm' is created on the target > > > > machine and this flag should be reset, which would allow the VMM to > > > > restore the firmware registers. However, we would be running KVM_RUN > > > > for the first time on the target machine, thus setting the flag. > > > > So, you are right; It's more of a resume operation from the guest's > > > > point of view. I guess the name of the variable is what's confusing > > > > here. > > > > > > I was actually thinking that live migration gives userspace an easy > > > way to circumvent your restriction. You said, "This state of the VM is > > > helpful in the upcoming patches to prevent user-space from configuring > > > certain VM features after the VM has started running." However, if you > > > don't ensure that these VM features are configured the same way on the > > > target machine as they were on the source machine, you have not > > > actually accomplished your stated goal. > > > > > Isn't that up to the VMM to save/restore and validate the registers > > across migrations? > > Yes, just as it is up to userspace not to make bad configuration > changes after the first VMRUN. > > > Perhaps I have to re-word my intentions for the patch- userspace > > should be able to configure the registers before issuing the first > > KVM_RUN. > > Perhaps it would help if you explained *why* you are doing this. It > sounds like you are either trying to protect against a malicious > userspace, or you are trying to keep userspace from doing something > stupid. In general, kvm only enforces constraints that are necessary > to protect the host. If that's what you're doing, I don't understand > why live migration doesn't provide an end-run around your protections. It's mainly to safeguard the guests. With respect to migration, KVM and the userspace are collectively playing a role here. It's up to the userspace to ensure that the registers are configured the same across migrations and KVM ensures that the userspace doesn't modify the registers after KVM_RUN so that they don't see features turned OFF/ON during execution. I'm not sure if it falls into the definition of protecting the host. Do you see a value in adding this extra protection from KVM? Regards, Raghavendra
