linux-kernel - Re: [PATCH 2/5] KVM: svm: Disallow EFER.LMSLE on hardware that doesn't support it

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: <YyT5uW8bjXae2c4l@google.com>
Date:   Fri, 16 Sep 2022 22:33:29 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Jim Mattson <jmattson@...gle.com>, Avi Kivity <avi@...hat.com>,
        Babu Moger <babu.moger@....com>,
        "Chang S. Bae" <chang.seok.bae@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Joerg Roedel <joerg.roedel@....com>,
        Josh Poimboeuf <jpoimboe@...nel.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wyes Karny <wyes.karny@....com>, x86@...nel.org
Subject: Re: [PATCH 2/5] KVM: svm: Disallow EFER.LMSLE on hardware that
 doesn't support it

On Sat, Sep 17, 2022, Borislav Petkov wrote:
> On Fri, Sep 16, 2022 at 02:00:26PM -0700, Jim Mattson wrote:
> > It's possible that SLES11 Xen 4.0 sets the bit, but never actually
> > uses truncated segments in 64-bit mode. In any case, according to the
> > original commit, it won't boot if setting EFER.LMSLE is not allowed.
> 
> How is SLE11 at all relevant to the upstream kernel?

Yeah, I'm inclined to revert the original commit and advertise NO_LSMLE unconditionally.
I don't like the idea of knowingly ignoring the fact that KVM doesn't correctly
virtualize LMSLE.

Xen itself already does exactly this:

  commit 23ccf530431561268b0190f0f1b740b618771b7b
  Author: Andrew Cooper <andrew.cooper3@...rix.com>
  Date:   Fri Apr 2 14:10:25 2021 +0100

    x86/cpuid: Advertise no-lmsl unilaterally to hvm guests
    
    While part of the original AMD64 spec, Long Mode Segment Limit was a feature
    not picked up by Intel, and therefore didn't see much adoption in software.
    AMD have finally dropped the feature from hardware, and allocated a CPUID bit
    to indicate its absence.
    
    Xen has never supported the feature for guests, even when running on capable
    hardware, so advertise the feature's absence unilaterally.
    
    There is nothing specifically wrong with exposing this bit to PV guests, but
    the PV ABI doesn't include a working concept of MSR_EFER in the first place,
    so exposing it to PV guests would be out-of-place.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@...rix.com>
    Reviewed-by: Jan Beulich <jbeulich@...e.com>

because as noted in commit f2c6084442 ("x86/SVM: correct boot time cpu_data[] handling"),
Xen broke detection of LMSLE support shortly after it was added in 2010, presumably
before any official release.  "Support" was added for HVM guests in by commit 

  727bc17d20 ("svm: support EFER.LMSLE for guests")

and then broken a few weeks later by commit
 
  566ddbe833 ("x86: Fail CPU bringup cleanly if it cannot initialise HVM.")

Note that Xen did a "safe" WRMSR+RDMSR to detect LMSLE, so either someone added
extra out-of-tree code that caused Xen to fail to boot, or "necessary ... to boot
with nested svm" only meant being able to expose SVM to L2.

Either way, KVM appears to be carrying a half-baked "fix" for a buggy guest that's
long since gone.  So like we did in commit 8805875aa473 ("Revert "KVM: nVMX: Do not
expose MPX VMX controls when guest MPX disabled""), I think we should just revert
the "fix".