kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Ram Pai <linuxram@us.ibm.com>
Cc: qemu-devel@nongnu.org, brijesh.singh@amd.com,
	frankja@linux.ibm.com, dgilbert@redhat.com, pair@us.ibm.com,
	Eduardo Habkost <ehabkost@redhat.com>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	cohuck@redhat.com, mdroth@linux.vnet.ibm.com,
	qemu-ppc@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [RFC v2 17/18] spapr: Added PEF based guest memory protection
Date: Thu, 4 Jun 2020 13:46:26 +1000	[thread overview]
Message-ID: <20200604034626.GE228651@umbus.fritz.box> (raw)
In-Reply-To: <20200529075940.GA26785@oc0525413822.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 5793 bytes --]

On Fri, May 29, 2020 at 12:59:40AM -0700, Ram Pai wrote:
> On Thu, May 21, 2020 at 01:43:03PM +1000, David Gibson wrote:
> > Some upcoming POWER machines have a system called PEF (Protected
> > Execution Framework) which uses a small ultravisor to allow guests to
> 
> Framework -> Facility
> 
> > run in a way that they can't be eavesdropped by the hypervisor.  The
> > effect is roughly similar to AMD SEV, although the mechanisms are
> > quite different.
> > 
> > Most of the work of this is done between the guest, KVM and the
> > ultravisor, with little need for involvement by qemu.  However qemu
> > does need to tell KVM to allow secure VMs.
> > 
> > Because the availability of secure mode is a guest visible difference
> > which depends on havint the right hardware and firmware, we don't
> 
> havint -> having
> 
> > enable this by default.  In order to run a secure guest you need to
> > create a "pef-guest" object and set the guest-memory-protection machine property to point to it.
> > 
> > Note that this just *allows* secure guests, the architecture of PEF is
> > such that the guest still needs to talk to the ultravisor to enter
> > secure mode, so we can't know if the guest actually is secure until
> > well after machine creation time.
> 
> In fact, Qemu has no direct way of knowing if the guest has turned
> secure or not, even after machine creation time. There are indirect ways
> for Qemu to know that, but nothing informs Qemu explicitly about it. 
> 
> So maybe we should just say...
> 
> "..
>  such that the guest still needs to talk to the ultravisor to enter
>  secure mode, so we can't directly know if the guest actually is secure." 
> 
> 
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  target/ppc/Makefile.objs |  2 +-
> >  target/ppc/pef.c         | 81 ++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 82 insertions(+), 1 deletion(-)
> >  create mode 100644 target/ppc/pef.c
> > 
> > diff --git a/target/ppc/Makefile.objs b/target/ppc/Makefile.objs
> > index e8fa18ce13..ac93b9700e 100644
> > --- a/target/ppc/Makefile.objs
> > +++ b/target/ppc/Makefile.objs
> > @@ -6,7 +6,7 @@ obj-y += machine.o mmu_helper.o mmu-hash32.o monitor.o arch_dump.o
> >  obj-$(TARGET_PPC64) += mmu-hash64.o mmu-book3s-v3.o compat.o
> >  obj-$(TARGET_PPC64) += mmu-radix64.o
> >  endif
> > -obj-$(CONFIG_KVM) += kvm.o
> > +obj-$(CONFIG_KVM) += kvm.o pef.o
> >  obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
> >  obj-y += dfp_helper.o
> >  obj-y += excp_helper.o
> > diff --git a/target/ppc/pef.c b/target/ppc/pef.c
> > new file mode 100644
> > index 0000000000..823daf3e9c
> > --- /dev/null
> > +++ b/target/ppc/pef.c
> > @@ -0,0 +1,81 @@
> > +/*
> > + * PEF (Protected Execution Framework) for POWER support
> > + *
> > + * Copyright David Gibson, Redhat Inc. 2020
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +
> > +#define TYPE_PEF_GUEST "pef-guest"
> > +#define PEF_GUEST(obj)                                  \
> > +    OBJECT_CHECK(PefGuestState, (obj), TYPE_SEV_GUEST)
> > +
> > +typedef struct PefGuestState PefGuestState;
> > +
> > +/**
> > + * PefGuestState:
> > + *
> > + * The PefGuestState object is used for creating and managing a PEF
> > + * guest.
> > + *
> > + * # $QEMU \
> > + *         -object pef-guest,id=pef0 \
> > + *         -machine ...,guest-memory-protection=pef0
> > + */
> > +struct PefGuestState {
> > +    Object parent_obj;
> > +};
> > +
> > +static Error *pef_mig_blocker;
> > +
> > +static int pef_kvm_init(GuestMemoryProtection *gmpo, Error **errp)
> > +{
> > +    PefGuestState *pef = PEF_GUEST(gmpo);
> > +
> > +    if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURE_GUEST)) {
> > +        error_setg(errp,
> > +                   "KVM implementation does not support Secure VMs (is an ultravisor running?)");
> > +        return -1;
> > +    } else {
> > +        int ret = kvm_vm_enable_cap(kvm_state, KVM_CAP_PPC_SECURE_GUEST, 0, 1);
> > +
> > +        if (ret < 0) {
> > +            error_setg(errp,
> > +                       "Error enabling PEF with KVM");
> > +            return -1;
> > +        }
> > +    }
> > +
> > +    return 0;
> > +}
> 
> This looks correct to me.
> 
> > +
> > +static void pef_guest_class_init(ObjectClass *oc, void *data)
> > +{
> > +    GuestMemoryProtectionClass *gmpc = GUEST_MEMORY_PROTECTION_CLASS(oc);
> > +
> > +    gmpc->kvm_init = pef_kvm_init;
> > +}
> > +
> > +static const TypeInfo pef_guest_info = {
> > +    .parent = TYPE_OBJECT,
> > +    .name = TYPE_PEF_GUEST,
> > +    .instance_size = sizeof(PefGuestState),
> > +    .class_init = pef_guest_class_init,
> > +    .interfaces = (InterfaceInfo[]) {
> > +        { TYPE_GUEST_MEMORY_PROTECTION },
> > +        { TYPE_USER_CREATABLE },
> > +        { }
> > +    }
> > +};
> > +
> > +static void
> > +pef_register_types(void)
> > +{
> > +    type_register_static(&pef_guest_info);
> > +}
> > +
> > +type_init(pef_register_types);
> 
> Acked-by: Ram Pai <linuxram@us.ibm.com>
> 
> Thanks for doing this!
> 
> BTW: Will there be a new machine type defined for running secure VMs?

I wasn't planning on it.  Part of the point of this unified
configuration is that we can reasonably have libvirt and upper layers
tell qemu to do this without needing specific machine type hacks.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-04  6:12 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21  3:42 [RFC v2 00/18] Refactor configuration of guest memory protection David Gibson
2020-05-21  3:42 ` [RFC v2 01/18] target/i386: sev: Remove unused QSevGuestInfoClass David Gibson
2020-05-29  9:01   ` Philippe Mathieu-Daudé
2020-06-02  3:04   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 02/18] target/i386: sev: Move local structure definitions into .c file David Gibson
2020-05-29  9:03   ` Philippe Mathieu-Daudé
2020-06-02  3:05   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 03/18] target/i386: sev: Rename QSevGuestInfo David Gibson
2020-05-29  9:05   ` Philippe Mathieu-Daudé
2020-06-02  3:06   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 04/18] target/i386: sev: Embed SEVState in SevGuestState David Gibson
2020-05-29  9:09   ` Philippe Mathieu-Daudé
2020-06-04  3:15     ` David Gibson
2020-06-02  3:07   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 05/18] target/i386: sev: Partial cleanup to sev_state global David Gibson
2020-06-02  3:08   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 06/18] target/i386: sev: Remove redundant cbitpos and reduced_phys_bits fields David Gibson
2020-05-29  9:11   ` Philippe Mathieu-Daudé
2020-06-02  3:09   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 07/18] target/i386: sev: Remove redundant policy field David Gibson
2020-06-02  3:13   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 08/18] target/i386: sev: Remove redundant handle field David Gibson
2020-06-02  3:16   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 09/18] target/i386: sev: Unify SEVState and SevGuestState David Gibson
2020-05-29  9:13   ` Philippe Mathieu-Daudé
2020-06-02  3:18   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 10/18] guest memory protection: Add guest memory protection interface David Gibson
2020-05-25 10:27   ` Greg Kurz
2020-06-03 10:09     ` David Gibson
2020-06-02  1:44   ` Richard Henderson
2020-06-03 10:09     ` David Gibson
2020-05-21  3:42 ` [RFC v2 11/18] guest memory protection: Handle memory encrption via interface David Gibson
2020-05-25 10:26   ` Greg Kurz
2020-06-04  3:27     ` David Gibson
2020-06-02  3:21   ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 12/18] guest memory protection: Perform KVM init " David Gibson
2020-06-02  3:39   ` Richard Henderson
2020-06-02  3:45     ` Richard Henderson
2020-05-21  3:42 ` [RFC v2 13/18] guest memory protection: Move side effect out of machine_set_memory_encryption() David Gibson
2020-06-02  3:41   ` Richard Henderson
2020-05-21  3:43 ` [RFC v2 14/18] guest memory protection: Rework the "memory-encryption" property David Gibson
2020-06-02  3:54   ` Richard Henderson
2020-06-04  5:56     ` David Gibson
2020-06-04  6:19       ` Thomas Huth
2020-06-04  6:25         ` David Gibson
2020-05-21  3:43 ` [RFC v2 15/18] guest memory protection: Decouple kvm_memcrypt_*() helpers from KVM David Gibson
2020-06-02  4:13   ` Richard Henderson
2020-06-03 10:18     ` David Gibson
2020-05-21  3:43 ` [RFC v2 16/18] guest memory protection: Add Error ** to GuestMemoryProtection::kvm_init David Gibson
2020-05-29  9:16   ` Philippe Mathieu-Daudé
2020-06-02  4:15   ` Richard Henderson
2020-05-21  3:43 ` [RFC v2 17/18] spapr: Added PEF based guest memory protection David Gibson
2020-05-25 11:14   ` Greg Kurz
2020-05-29  7:59   ` Ram Pai
2020-06-04  3:46     ` David Gibson [this message]
2020-05-21  3:43 ` [RFC v2 18/18] guest memory protection: Alter virtio default properties for protected guests David Gibson
2020-06-05 10:45   ` Cornelia Huck
2020-06-05 16:04     ` Halil Pasic
2020-06-06 20:21   ` Michael S. Tsirkin
2020-06-07  3:07     ` David Gibson
2020-06-09 10:16       ` Cornelia Huck
2020-06-09 15:40         ` Halil Pasic
2020-06-09 15:57           ` Cornelia Huck
2020-06-09 16:01           ` Michael S. Tsirkin
2020-06-10  4:45           ` David Gibson
2020-06-10  4:39         ` David Gibson
2020-06-10  8:48           ` Cornelia Huck
2020-06-10 10:07             ` David Gibson
2020-06-10 13:21             ` Halil Pasic
2020-05-29 22:19 ` [RFC v2 00/18] Refactor configuration of guest memory protection Sean Christopherson
2020-06-01  9:16   ` Dr. David Alan Gilbert
2020-06-04  3:11     ` David Gibson
2020-06-04 16:20       ` Sean Christopherson
2020-06-04  3:05   ` David Gibson
2020-06-04  4:39 ` Thiago Jung Bauermann
2020-06-04  6:21   ` David Gibson
2020-06-04 21:54     ` Thiago Jung Bauermann
2020-06-04 22:47       ` Paolo Bonzini
2020-06-04 23:30         ` Thiago Jung Bauermann
2020-06-04 23:41           ` Paolo Bonzini
2020-06-05 20:01             ` Thiago Jung Bauermann
2020-06-06  8:24               ` David Gibson
2020-06-08 15:10                 ` Thiago Jung Bauermann
2020-06-04  6:44   ` David Gibson
2020-06-04  9:08     ` Greg Kurz
2020-06-06  8:45       ` David Gibson
2020-06-05 10:55 ` Cornelia Huck
2020-06-06  8:44   ` David Gibson
2020-06-09 10:11     ` Halil Pasic
2020-06-10  4:36       ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200604034626.GE228651@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=brijesh.singh@amd.com \
    --cc=cohuck@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=pair@us.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).