KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels
authorSean Christopherson <sean.j.christopherson@intel.com>
Tue, 2 Apr 2019 15:10:48 +0000 (08:10 -0700)
committerPaolo Bonzini <pbonzini@redhat.com>
Tue, 16 Apr 2019 13:37:38 +0000 (15:37 +0200)
commitb68f3cc7d978943fcf85148165b00594c38db776
tree67a64244ef7df43f32fdd32f4264d17aef1b6be2
parent8f4dc2e77cdfaf7e644ef29693fa229db29ee1de
KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels

Invoking the 64-bit variation on a 32-bit kenrel will crash the guest,
trigger a WARN, and/or lead to a buffer overrun in the host, e.g.
rsm_load_state_64() writes r8-r15 unconditionally, but enum kvm_reg and
thus x86_emulate_ctxt._regs only define r8-r15 for CONFIG_X86_64.

KVM allows userspace to report long mode support via CPUID, even though
the guest is all but guaranteed to crash if it actually tries to enable
long mode.  But, a pure 32-bit guest that is ignorant of long mode will
happily plod along.

SMM complicates things as 64-bit CPUs use a different SMRAM save state
area.  KVM handles this correctly for 64-bit kernels, e.g. uses the
legacy save state map if userspace has hid long mode from the guest,
but doesn't fare well when userspace reports long mode support on a
32-bit host kernel (32-bit KVM doesn't support 64-bit guests).

Since the alternative is to crash the guest, e.g. by not loading state
or explicitly requesting shutdown, unconditionally use the legacy SMRAM
save state map for 32-bit KVM.  If a guest has managed to get far enough
to handle SMIs when running under a weird/buggy userspace hypervisor,
then don't deliberately crash the guest since there are no downsides
(from KVM's perspective) to allow it to continue running.

Fixes: 660a5d517aaab ("KVM: x86: save/load state on SMM switch")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
arch/x86/kvm/emulate.c
arch/x86/kvm/x86.c