[SRU][J][PATCH 0/2] A general-proteciton exception during guest migration to unsupported PKRU machine
Chengen Du
chengen.du at canonical.com
Wed Mar 27 01:59:14 UTC 2024
Hi,
We have prepared a tested PPA [1] for the support team and the
customer to evaluate.
The test results from the support team meet our expectations [2], and
the customer is also satisfied with the outcome.
Furthermore, I have carefully reviewed the patch against the content
of the tested PPA, and it aligns with our expectations.
Best regards,
Chengen Du
[1] https://launchpad.net/~chengendu/+archive/ubuntu/sf00364034-test
[2] https://pastebin.canonical.com/p/Hgx8hjzqky/plain/
On Tue, Mar 26, 2024 at 4:34 PM Stefan Bader <stefan.bader at canonical.com> wrote:
>
> 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
>
More information about the kernel-team
mailing list