On 10/05/21 18:56, Sean Christopherson wrote:
On Mon, May 10, 2021, Maxim Levitsky wrote:
On Tue, 2021-05-04 at 14:58 -0700, Jim Mattson wrote:
On Tue, May 4, 2021 at 2:57 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
On 04/05/21 23:53, Sean Christopherson wrote:
Does the right thing happen here if the vCPU is in guest mode when
userspace decides to toggle the CPUID.80000001H:EDX.RDTSCP bit on or
off?
I hate our terminology. By "guest mode", do you mean running the vCPU, or do
you specifically mean running in L2?
Guest mode should mean L2.
(I wonder if we should have a capability that says "KVM_SET_CPUID2 can
only be called prior to KVM_RUN").
It would certainly make it easier to reason about potential security issues.
I vote too for this.
Alternatively, what about adding KVM_VCPU_RESET to let userspace explicitly
pull RESET#, and defining that ioctl() to freeze the vCPU model? I.e. after
userspace resets the vCPU, KVM_SET_CPUID (and any other relevant ioctls() is
disallowed.
Lack of proper RESET emulation is annoying, e.g. userspace has to manually stuff
EDX after vCPU creation to get the right value at RESET. A dedicated ioctl()
would kill two birds with one stone, without having to add yet another "2"
ioctl().
That has a disadvantage of opting into the more secure behavior, but we
can do both (forbidding KVM_SET_CPUID2 after both KVM_RUN and KVM_RESET).
Paolo
