linux-kernel - Re: [RFC] Revert "kvm: nVMX: Restrict VMX capability MSR changes"

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: <eeef5ff3-8ca9-4f21-7e48-d6c930985059@redhat.com>
Date:   Mon, 20 Jan 2020 17:40:10 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Jim Mattson <jmattson@...gle.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Liran Alon <liran.alon@...cle.com>
Subject: Re: [RFC] Revert "kvm: nVMX: Restrict VMX capability MSR changes"

On 20/01/20 17:33, Vitaly Kuznetsov wrote:
>> I think this should be fixed in QEMU, by doing KVM_SET_MSRS for feature
>> MSRs way earlier.  I'll do it since I'm currently working on a patch to
>> add a KVM_SET_MSR for the microcode revision.
> Works for me, thanks)
> 
> The bigger issue is that the vCPU setup sequence (like QEMU's
> kvm_arch_put_registers()) effectively becomes an API convention and as
> it gets more complex it would be great to document it for KVM.

Indeed, it's tricky to get right.  Though this is smaller compared to
the issue of the ordering between VCPU events and everything else.

Paolo