linux-kernel - Re: [PATCH v4.1] KVM, SEV: Add KVM_EXIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMkAt6oc=SOYryXu+_w+WZR+VkMZfLR3_nd=hDvMU_cmOjJ0Xg@mail.gmail.com>
Date:   Fri, 8 Apr 2022 09:18:56 -0600
From:   Peter Gonda <pgonda@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     kvm list <kvm@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4.1] KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ES

On Thu, Apr 7, 2022 at 8:55 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Thu, Apr 07, 2022, Peter Gonda wrote:
> > If an SEV-ES guest requests termination, exit to userspace with
> > KVM_EXIT_SYSTEM_EVENT and a dedicated SEV_TERM type instead of -EINVAL
> > so that userspace can take appropriate action.
> >
> > See AMD's GHCB spec section '4.1.13 Termination Request' for more details.
>
> Maybe it'll be obvious by the lack of compilation errors, but the changelog should
> call out the flags => ndata+data shenanigans, otherwise this looks like ABI breakage.

Hmm I am not sure we can do this change anymore given that we have two
call sites using 'flags'

arch/arm64/kvm/psci.c:184
arch/riscv/kvm/vcpu_sbi.c:97

I am not at all familiar with ARM and RISC-V but some quick reading
tells me these archs also require 64-bit alignment on their 64-bit
accesses. If thats correct, should I fix this call sites up by
proceeding with this ndata + data[] change and move whatever they are
assigning to flags into data[0] like I am doing here? It looks like
both of these changes are not in a kernel release so IIUC we can still
fix the ABI here?

>
> > Suggested-by: Sean Christopherson <seanjc@...gle.com>
> > Suggested-by: Paolo Bonzini <pbonzini@...hat.com>
> > Cc: kvm@...r.kernel.org
> > Cc: linux-kernel@...r.kernel.org
> > Signed-off-by: Peter Gonda <pgonda@...gle.com>
> >
> > ---
> > V4
> >  * Updated to Sean and Paolo's suggestion of reworking the
> >    kvm_run.system_event struct to ndata and data fields to fix the
> >    padding.
> >  * 4.1 Updated commit description
> >
> > V3
> >  * Add Documentation/ update.
> >  * Updated other KVM_EXIT_SHUTDOWN exits to clear ndata and set reason
> >    to KVM_SHUTDOWN_REQ.
> >
> > V2
> >  * Add KVM_CAP_EXIT_SHUTDOWN_REASON check for KVM_CHECK_EXTENSION.
> >
> > Tested by making an SEV-ES guest call sev_es_terminate() with hardcoded
> > reason code set and reason code and then observing the codes from the
> > userspace VMM in the kvm_run.shutdown.data fields.
> >
> > ---
> >  arch/x86/kvm/svm/sev.c   | 9 +++++++--
> >  include/uapi/linux/kvm.h | 5 ++++-
> >  2 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > index 75fa6dd268f0..1a080f3f09d8 100644
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> > @@ -2735,8 +2735,13 @@ static int sev_handle_vmgexit_msr_protocol(struct vcpu_svm *svm)
> >               pr_info("SEV-ES guest requested termination: %#llx:%#llx\n",
> >                       reason_set, reason_code);
> >
> > -             ret = -EINVAL;
> > -             break;
> > +             vcpu->run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
> > +             vcpu->run->system_event.type = KVM_SYSTEM_EVENT_SEV_TERM |
> > +                                            KVM_SYSTEM_EVENT_NDATA_VALID;
> > +             vcpu->run->system_event.ndata = 1;
> > +             vcpu->run->system_event.data[1] = control->ghcb_gpa;
> > +
> > +             return 0;
>
> Kinda silly, but
>
>                 ret = 0;
>                 break;
>
> would be better so that this flows through the tracepoint.  I wouldn't care much
> if it didn't result in an unpaired "entry" tracepoint (and I still don't care that
> much...).

Ah I'll fix that up.


>
> >       }
> >       default:
> >               /* Error, keep GHCB MSR value as-is */
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 8616af85dc5d..dd1d8167e71f 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -444,8 +444,11 @@ struct kvm_run {
> >  #define KVM_SYSTEM_EVENT_SHUTDOWN       1
> >  #define KVM_SYSTEM_EVENT_RESET          2
> >  #define KVM_SYSTEM_EVENT_CRASH          3
> > +#define KVM_SYSTEM_EVENT_SEV_TERM       4
> > +#define KVM_SYSTEM_EVENT_NDATA_VALID    (1u << 31)
> >                       __u32 type;
> > -                     __u64 flags;
> > +                     __u32 ndata;
> > +                     __u64 data[16];
> >               } system_event;
> >               /* KVM_EXIT_S390_STSI */
> >               struct {
> > --
> > 2.35.1.1178.g4f1659d476-goog
> >