linux-kernel - Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

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: <eeae3e95-c908-695a-043f-a99f8ed39919@redhat.com>
Date:   Mon, 26 Feb 2018 12:47:27 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Borislav Petkov <bp@...en8.de>, Wanpeng Li <kernellwp@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, kvm <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [PATCH] KVM: X86: Allow userspace to define the microcode version

On 26/02/2018 11:49, Borislav Petkov wrote:
>> I think it is the host admin(e.g. cloud provider)'s responsibility to
>> set an expected microcode revision.
> +       vcpu->arch.microcode_version = 0x1;
> 
> That already looks pretty arbitrary and non-sensical to me.

It's actually 0x100000000.

>> In addition, the non-sensical value which is written by the guest will
>> not reflect to guest-visible microcode revision and just be ignored in
>> this implementation.
>
> Huh? How so?
> 
> So a guest will have *two* microcode revisions - both of which are most
> likely wrong?!

I don't understand this either.

Actually I think this patch makes sense, since some errata actually can
be worked around in the guest in the same way as the host.  However, it
should also be tied to the recently introduced mechanism to read MSR
contents from the host.

Paolo