[SRU][J][PATCH 0/2] A general-proteciton exception during guest migration to unsupported PKRU machine

[Stefan Bader]

On 16.03.24 04:43, Chengen Du wrote:
> BugLink: https://bugs.launchpad.net/bugs/2032164
> 
> SRU Justification:
> 
> [Impact]
> When a host that supports PKRU initiates a guest that lacks PKRU support, the flag is enabled on the guest's fpstate.
> This information is then passed to userspace through the vcpu ioctl KVM_GET_XSAVE.
> However, a problem arises when the user opts to migrate the mentioned guest to another machine that does not support PKRU.
> In this scenario, the new host attempts to restore the guest's fpu registers.
> Nevertheless, due to the absence of PKRU support on the new host, a general-protection exception takes place, leading to a guest crash.
> 
> [Fix]
> The problem is resolved by the following upstream commit:
> 18164f66e6c5 x86/fpu: Allow caller to constrain xfeatures when copying to uabi buffer
> 8647c52e9504 KVM: x86: Constrain guest-supported xfeatures only at KVM_GET_XSAVE{2}
> 
> [Test Plan]
> Several scenarios need to be conducted to confirm the migration outcome.
> 	Patched kernel with PKRU -> kernel with PKRU
> 	Patched kernel with PKRU -> kernel without PKRU
> 	Patched kernel without PKRU -> kernel with PKRU
> 	Patched kernel without PKRU -> kernel without PKRU
> 	Kernel with PKRU -> patched kernel with PKRU
> 	Kernel with PKRU -> patched kernel without PKRU
> 	Kernel without PKRU -> patched kernel with PKRU
> 	Kernel without PKRU -> patched kernel without PKRU
> 	Patched kernel with PKRU -> patched kernel without PKRU
> 
> Each scenarios shall succeed except "Kernel with PKRU -> patched kernel without PKRU" one.
> Addressing this case poses challenges because the most plausible solution is to clamp the FPU features at the destination during migration.
> However, upstream does not support this approach due to concerns about silently dropping features requested by userspace.
> This could potentially lead to other issues and violate KVM's ABI.
> 
> [Where problems could occur]
> The introduced commits will impact the guest migration process,
> potentially leading to failures and preventing the guest from operating successfully on the migration destination.
> 
> Sean Christopherson (2):
>    x86/fpu: Allow caller to constrain xfeatures when copying to uabi
>      buffer
>    KVM: x86: Constrain guest-supported xfeatures only at KVM_GET_XSAVE{2}
> 
>   arch/x86/include/asm/fpu/api.h |  3 ++-
>   arch/x86/kernel/fpu/core.c     |  5 +++--
>   arch/x86/kernel/fpu/xstate.c   |  7 +++++--
>   arch/x86/kernel/fpu/xstate.h   |  3 ++-
>   arch/x86/kvm/x86.c             | 33 +++++++++++++++++++++++++++------
>   5 files changed, 39 insertions(+), 12 deletions(-)
> 
Given the complexity of the changes with parts dropped from the upstream 
patches because other changes were not done, it would be better to have 
tested the outcome before applying to a cycle. Has this been done?

-- 
- Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 48643 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240326/9ec1dcd9/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240326/9ec1dcd9/attachment-0001.sig>