linux-kernel - Re: [PATCH 07/54] KVM: x86: Alert userspace that KVM_SET_CPUID{,2} after KVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <af716f56-9d68-2514-7b85-f9bbb1a82acf@redhat.com>
Date:   Wed, 23 Jun 2021 20:49:29 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Jim Mattson <jmattson@...gle.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Joerg Roedel <joro@...tes.org>, kvm list <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Yu Zhang <yu.c.zhang@...ux.intel.com>,
        Maxim Levitsky <mlevitsk@...hat.com>
Subject: Re: [PATCH 07/54] KVM: x86: Alert userspace that KVM_SET_CPUID{,2}
 after KVM_RUN is broken

On 23/06/21 20:11, Jim Mattson wrote:
> On Wed, Jun 23, 2021 at 10:11 AM Paolo Bonzini <pbonzini@...hat.com> wrote:
>> Nah, that's not the philosophy.  The philosophy is that covering all
>> possible ways for userspace to shoot itself in the foot is impossible.
>>
>> However, here we're talking about 2 lines of code (thanks also to your
>> patches that add last_vmentry_cpu for completely unrelated reasons) to
>> remove a whole set of bullet/foot encounters.
> 
> What about the problems that arise when we have different CPUID tables
> for different vCPUs in the same VM? Can we just replace this
> hole-in-foot inducing ioctl with a KVM_VM_SET_CPUID ioctl on the VM
> level that has to be called before any vCPUs are created?

Are there any KVM bugs that this can fix?  The problem is that, unlike 
this case, it would be effectively impossible to deprecate 
KVM_SET_CPUID2 as a vcpu ioctl, so it would be hard to reap any benefits 
in KVM.

BTW, there is actually a theoretical usecase for KVM_SET_CPUID2 after 
KVM_RUN, which is to test OSes against microcode updates that hide, 
totally random example, the RTM bit.  But it's still not worth keeping 
it given 1) the bugs and complications in KVM, 2) if you really wanted 
that kind of testing so hard, the fact that you can just create a new 
vcpu file descriptor from scratch, possibly in cooperation with 
userspace MSR filtering 3) AFAIK no one has done that anyway in 15 years.

Paolo