Messages in this thread | | | From | Jim Mattson <> | Date | Wed, 21 Sep 2022 08:11:29 -0700 | Subject | Re: [PATCH v2 0/3] KVM: EFER.LMSLE cleanup |
| |
On Wed, Sep 21, 2022 at 6:54 AM Borislav Petkov <bp@alien8.de> wrote: > > On Wed, Sep 21, 2022 at 06:45:24AM -0700, Jim Mattson wrote: > > EFER.LMLSE is not a reserved bit on AMD64 CPUs, unless > > CPUID.80000008:EBX[20] is set (or you're running very, very old > > hardware). > > > > We really shouldn't just decide on a whim to treat EFER.LMSLE as > > reserved under KVM. The guest CPUID information represents our > > detailed contract with the guest software. By setting > > CPUID.80000008:EBX[20], we are telling the guest that if it tries to > > set EFER.LMSLE, we will raise a #GP. > > I understand all that. What I'm asking is, what happens in KVM *after* > your patch 1/3 is applied when a guest tries to set EFER.LMSLE? Does it > #GP or does it allow the WRMSR to succeed? I.e., does KVM check when > reserved bits in that MSR are being set? > > By looking at it, there's kvm_enable_efer_bits() so it looks like KVM > does control which bits are allowed to set and which not...?
Yes, after the revert, KVM will treat the bit as reserved, and it will synthesize a #GP, *in violation of the architectural specification.* As I said, we could document this behavior as a KVM erratum.
> > If we don't set that bit in the guest CPUID information and we raise > > #GP on an attempt to set EFER.LMSLE, the virtual hardware is > > defective. > > See, this is what I don't get - why is it defective? After the revert, > that bit to KVM is reserved.
KVM can't just decide willy nilly to reserve arbitrary bits. If it is in violation of AMD's architectural specification, the virtual CPU is defective.
> > We could document this behavior as an erratum, but since a > > mechanism exists to declare that the guest can expect EFER.LMSLE to > > #GP, doesn't it make sense to use it? > > I don't mind all that and the X86_FEATURE bit and so on - I'm just > trying to ask you guys: what is KVM's behavior when the guest tries to > set a reserved EFER bit. > > Maybe I'm not expressing myself precisely enough...
I feel the same way. :-(
The two patches after the revert are to amend the contract with the guest (as expressed by the guest CPUID table) so that the KVM virtual CPU can raise a #GP on EFER.LMSLE and still conform to the architectural specification.
From the APM, volume 2, 4.12.2 Data Limit Checks in 64-bit Mode:
> Data segment limit checking in 64-bit mode is not supported by all processor implementations and has been deprecated. If CPUID Fn8000_0008_EBX[EferLmlseUnsupported](bit 20) = 1, 64-bit mode segment limit checking is not supported and attempting to enable this feature by setting EFER.LMSLE =1 will result in a #GP exception.
| |