| Message ID | 20220205081658.562208-3-leobras@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/kvm/fpu: Fix guest migration bugs that can crash guest | expand |
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 74b53a16f38a..f4e42de3560a 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5010,7 +5010,8 @@ static int kvm_vcpu_ioctl_x86_set_xsave(struct kvm_vcpu *vcpu, return fpu_copy_uabi_to_guest_fpstate(&vcpu->arch.guest_fpu, guest_xsave->region, - supported_xcr0, &vcpu->arch.pkru); + vcpu->arch.guest_supported_xcr0, + &vcpu->arch.pkru); } static void kvm_vcpu_ioctl_x86_get_xcrs(struct kvm_vcpu *vcpu,
As of today, if userspace tries to set guest's fpu features to any value (vcpu ioctl: KVM_SET_XSAVE), it is checked against the supported features of the host cpu, and the supported features of KVM. This makes possible to set the guest fpstate with features that were not enabled during guest creation, but are available in the host cpu. This becomes an issue during guest migration, if the target host does not support the given feature: 1 - Create guest vcpu without support to featureA, on a source host that supports it, 2 - Set featureA to guest vcpu, even if it does not support it. It will run just fine, as the current host cpu supports featureA, 3 - Migrate guest to another host, which does not support featureA, 4 - After migration is completed, restoring guest fpustate to fpu regs will cause a general-protection exception, and crash the guest. A way to avoid the issue is by returning error if the user tries to set any feature not enabled during guest creation (guest_supported_xcr0). Signed-off-by: Leonardo Bras <leobras@redhat.com> --- arch/x86/kvm/x86.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)