linux-kernel - Re: [PATCH] KVM: x86: Allow XSAVES on CPUs where host doesn't use it due to an errata

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] [day] [month] [year] [list]

Message-ID: <CABgObfb_hv=_ksOrDLRSKjFpkQtjWh4oYHxzvK6oH=_YLgTn0A@mail.gmail.com>
Date:   Wed, 6 Dec 2023 23:45:02 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc:     Jim Mattson <jmattson@...gle.com>,
        Maxim Levitsky <mlevitsk@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Allow XSAVES on CPUs where host doesn't use it
 due to an errata

On Fri, Dec 1, 2023 at 5:05 PM Maciej S. Szmigiero
<mail@...iej.szmigiero.name> wrote:
>
> On 1.12.2023 00:57, Jim Mattson wrote:
> > On Thu, Nov 30, 2023 at 2:00 PM Maciej S. Szmigiero
> > <mail@...iej.szmigiero.name> wrote:
> >> I think that if particular guest would work on bare metal it should
> >> work on "-cpu host" too - no tinkering should be required for such
> >> basic functionality as being able to successfully finish booting.
> >
> > I disagree. Let's not focus on one particular erratum. If, for
> > whatever reason, the host kernel is booted with "noxsaves," I don't
> > think KVM should allow a guest to bypass that directive.
>
> This could be achieved by either adding special "noxsaves" flag
> or by setting X86_BUG_XSAVES_AVOID instead of clearing
> X86_FEATURE_XSAVES on these CPUs.
>
> Then the core kernel XSAVES code would check for lack of
> X86_BUG_XSAVES_AVOID (in addition to checking for
> presence of X86_FEATURE_XSAVES) while KVM would keep using
> only X86_FEATURE_XSAVES.

This is feasible, on the other hand the erratum is pretty bad. Since
the workaround is easy (just disable XSAVEC; and maybe XGETBV1 as
well?), you could just do a printk_ratelimited() on the write to
HV_X64_MSR_GUEST_OS_ID, in particular if:

1) guest CPUID has XSAVEC and SVM

2) host CPUID does not have XSAVES

3) guest OS id indicates Windows Server 10.x (which is 2016 to 2022),
which should be 0x0001040A00??????.

Paolo