Message ID | 20200930041659.28181-1-sean.j.christopherson@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: x86: Handle reserved CR4 bit interception in VMX | expand |
On 30/09/20 06:16, Sean Christopherson wrote: > This series stems from Lai's RFC patches to intercept LA57 and let the > guest own FSGSBASE[*]. Discussion and inspection revealed that KVM does > not handle the case where LA57 is supported in hardware but not exposed to > the guest. This is actually true for all CR4 bits, but LA57 is currently > the only bit that can be reserved and also owned by the guest. I have > a unit test for this that I'll post separately. > > Intercepting LA57 was by far the easiest fix for the immedidate bug, and > is likely the right change in the long term as there's no justification > for letting the guest own LA57. > > The middle three patches adjust VMX's CR4 guest/host mask to intercept > reserved bits. This required reworking CPUID updates to also refresh said > mask at the correct time. > > The last past is Lai's, which let's the guest own FSGSBASE. This depends > on the reserved bit handling being in place. > > Ran everything through unit tests, and ran the kernel's FSGSBASE selftests > in a VM. > > [*] https://lkml.kernel.org/r/20200928083047.3349-1-jiangshanlai@gmail.com > > Lai Jiangshan (2): > KVM: x86: Intercept LA57 to inject #GP fault when it's reserved > KVM: x86: Let the guest own CR4.FSGSBASE > > Sean Christopherson (3): > KVM: x86: Invoke vendor's vcpu_after_set_cpuid() after all common > updates > KVM: x86: Move call to update_exception_bitmap() into VMX code > KVM: VMX: Intercept guest reserved CR4 bits to inject #GP fault > > arch/x86/kvm/cpuid.c | 6 +++--- > arch/x86/kvm/kvm_cache_regs.h | 2 +- > arch/x86/kvm/vmx/vmx.c | 18 +++++++++++++----- > 3 files changed, 17 insertions(+), 9 deletions(-) > Queued, thanks. Paolo
On 30/09/20 06:16, Sean Christopherson wrote: > This series stems from Lai's RFC patches to intercept LA57 and let the > guest own FSGSBASE[*]. Discussion and inspection revealed that KVM does > not handle the case where LA57 is supported in hardware but not exposed to > the guest. This is actually true for all CR4 bits, but LA57 is currently > the only bit that can be reserved and also owned by the guest. I have > a unit test for this that I'll post separately. > > Intercepting LA57 was by far the easiest fix for the immedidate bug, and > is likely the right change in the long term as there's no justification > for letting the guest own LA57. > > The middle three patches adjust VMX's CR4 guest/host mask to intercept > reserved bits. This required reworking CPUID updates to also refresh said > mask at the correct time. > > The last past is Lai's, which let's the guest own FSGSBASE. This depends > on the reserved bit handling being in place. > > Ran everything through unit tests, and ran the kernel's FSGSBASE selftests > in a VM. > > [*] https://lkml.kernel.org/r/20200928083047.3349-1-jiangshanlai@gmail.com > > Lai Jiangshan (2): > KVM: x86: Intercept LA57 to inject #GP fault when it's reserved > KVM: x86: Let the guest own CR4.FSGSBASE > > Sean Christopherson (3): > KVM: x86: Invoke vendor's vcpu_after_set_cpuid() after all common > updates > KVM: x86: Move call to update_exception_bitmap() into VMX code > KVM: VMX: Intercept guest reserved CR4 bits to inject #GP fault > > arch/x86/kvm/cpuid.c | 6 +++--- > arch/x86/kvm/kvm_cache_regs.h | 2 +- > arch/x86/kvm/vmx/vmx.c | 18 +++++++++++++----- > 3 files changed, 17 insertions(+), 9 deletions(-) > Queued, thanks. Paolo