linux-kernel - Re: [PATCH 04/43] KVM: SVM: Fall back to KVM's hardcoded value for EDX at RESET/INIT

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]

Date:   Tue, 18 May 2021 22:41:40 -0700
From:   Reiji Watanabe <reijiw@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 04/43] KVM: SVM: Fall back to KVM's hardcoded value for
 EDX at RESET/INIT

On Fri, Apr 23, 2021 at 5:47 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> At vCPU RESET/INIT (mostly RESET), stuff EDX with KVM's hardcoded,
> default Family-Model-Stepping ID of 0x600 if CPUID.0x1 isn't defined.
> At RESET, the CPUID lookup is guaranteed to "miss" because KVM emulates
> RESET before exposing the vCPU to userspace, i.e. userspace can't
> possibly have done set the vCPU's CPUID model, and thus KVM will always
> write '0'.  At INIT, using 0x600 is less bad than using '0'.
>
> While initializing EDX to '0' is _extremely_ unlikely to be noticed by
> the guest, let alone break the guest, and can be overridden by
> userspace for the RESET case, using 0x600 is preferable as it will allow
> consolidating the relevant VMX and SVM RESET/INIT logic in the future.
> And, digging through old specs suggests that neither Intel nor AMD have
> ever shipped a CPU that initialized EDX to '0' at RESET.
>
> Regarding 0x600 as KVM's default Family, it is a sane default and in
> many ways the most appropriate.  Prior to the 386 implementations, DX
> was undefined at RESET.  With the 386, 486, 586/P5, and 686/P6/Athlon,
> both Intel and AMD set EDX to 3, 4, 5, and 6 respectively.  AMD switched
> to using '15' as its primary Family with the introduction of AMD64, but
> Intel has continued using '6' for the last few decades.
>
> So, '6' is a valid Family for both Intel and AMD CPUs, is compatible
> with both 32-bit and 64-bit CPUs (albeit not a perfect fit for 64-bit
> AMD), and of the common Families (3 - 6), is the best fit with respect to
> KVM's virtual CPU model.  E.g. prior to the P6, Intel CPUs did not have a
> STI window.  Modern operating systems, Linux included, rely on the STI
> window, e.g. for "safe halt", and KVM unconditionally assumes the virtual
> CPU has an STI window.  Thus enumerating a Family ID of 3, 4, or 5 would
> be provably wrong.
>
> Opportunistically remove a stale comment.
>
> Fixes: 66f7b72e1171 ("KVM: x86: Make register state after reset conform to specification")
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>

Reviewed-by: Reiji Watanabe <reijiw@...gle.com>