linux-kernel - Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's 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: <42809091-3330-c99b-0d11-218db66a3de9@redhat.com>
Date:   Mon, 27 Nov 2017 11:40:03 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Filippo Sironi <sironi@...zon.de>, rkrcmar@...hat.com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the
 microcode version

On 26/11/2017 17:41, Filippo Sironi wrote:
> ... that the guest should see.
> Guest operating systems may check the microcode version to decide whether
> to disable certain features that are known to be buggy up to certain
> microcode versions.  Address the issue by making the microcode version
> that the guest should see settable.

What's the advantage of specifying the microcode version, rather than
relying on userspace to drop the CPUID bit for the buggy feature?

                           old guest(*)         new guest

   hide in CPUID              good                 good

   use ucode rev              BAD                  good


(*) old guest = doesn't know that the feature is buggy until a given
ucode revision

Thanks,

Paolo

> The rationale for having userspace specifying the microcode version, rather
> than having the kernel picking it, is to ensure consistency for live-migrated
> instances; we don't want them to see a microcode version increase without a
> reset.