linux-kernel - Re: [PATCH v2 0/3] KVM: EFER.LMSLE cleanup

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:   Wed, 21 Sep 2022 10:45:49 -0700
From:   Jim Mattson <jmattson@...gle.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H . Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v2 0/3] KVM: EFER.LMSLE cleanup

On Wed, Sep 21, 2022 at 10:11 AM Borislav Petkov <bp@...en8.de> wrote:
>
> On Wed, Sep 21, 2022 at 09:23:40AM -0700, Jim Mattson wrote:
> > AMD defined the 64-bit x86 extensions while Intel was distracted with
> > their VLIW science fair project. In this space, Intel produces AMD64
> > compatible CPUs.
>
> Almost-compatible. And maybe, just maybe, because Intel were probably
> and practically forced to implement AMD64 but then thought, oh well,
> we'll do some things differently.
>
> > The definitive specification comes from AMD (which is sad, because
> > AMD's documentation is abysmal).
>
> Just don't tell me the SDM is better...
>
> But you and I are really talking past each other: there's nothing
> definitive about a spec if, while implementing it, the other vendor is
> doing some subtle, but very software visible things differently.
>
> I.e., the theory vs reality point I'm trying to get across.

I get it. In reality, all of the reverse polarity CPUID feature bits
are essentially useless.

The only software that actually uses LMSLE is defunct. That software
predated the definition of CPUID.80000008:EBX.EferLmlseUnsupported and
is no longer being updated, so it isn't going to check the feature
bit. It's just going to fail with an unexpected #GP.

Maybe you think I'm being overly pedantic, but the code to do the
right thing is trivial, so why not do it?

This way, if anyone files a bug against KVM because an old VMware
hypervisor dies with an unexpected #GP, I can point to the spec and
say that it's user error.