| Message ID | 20200724025744.69644-11-david@gibson.dropbear.id.au |
|---|---|
| State | New |
| Headers | show |
| Series | Generalize memory encryption models | expand |
On Thu, 10 Sep 2020 13:36:09 +0200 Cornelia Huck <cohuck@redhat.com> wrote: > On Mon, 7 Sep 2020 17:22:53 +0200 > Halil Pasic <pasic@linux.ibm.com> wrote: > > > On Fri, 24 Jul 2020 12:57:44 +1000 > > David Gibson <david@gibson.dropbear.id.au> wrote: > > > > > At least some s390 cpu models support "Protected Virtualization" (PV), > > > a mechanism to protect guests from eavesdropping by a compromised > > > hypervisor. > > > > > > This is similar in function to other mechanisms like AMD's SEV and > > > POWER's PEF, which are controlled bythe "host-trust-limitation" > > > machine option. s390 is a slightly special case, because we already > > > supported PV, simply by using a CPU model with the required feature > > > (S390_FEAT_UNPACK). > > > > > > To integrate this with the option used by other platforms, we > > > implement the following compromise: > > > > > > - When the host-trust-limitation option is set, s390 will recognize > > > it, verify that the CPU can support PV (failing if not) and set > > > virtio default options necessary for encrypted or protected guests, > > > as on other platforms. i.e. if host-trust-limitation is set, we > > > will either create a guest capable of entering PV mode, or fail > > > outright > > > > Shouldn't we also fail outright if the virtio features are not PV > > compatible (invalid configuration)? > > > > I would like to see something like follows as a part of this series. > > ----------------------------8<-------------------------- > > From: Halil Pasic <pasic@linux.ibm.com> > > Date: Mon, 7 Sep 2020 15:00:17 +0200 > > Subject: [PATCH] virtio: handle host trust limitation > > > > If host_trust_limitation_enabled() returns true, then emulated virtio > > devices must offer VIRTIO_F_ACCESS_PLATFORM, because the device is not > > capable of accessing all of the guest memory. Otherwise we are in > > violation of the virtio specification. > > > > Let's fail realize if we detect that VIRTIO_F_ACCESS_PLATFORM feature is > > obligatory but missing. > > > > Signed-off-by: Halil Pasic <pasic@linux.ibm.com> > > --- > > hw/virtio/virtio.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c > > index 5bd2a2f621..19b4b0a37a 100644 > > --- a/hw/virtio/virtio.c > > +++ b/hw/virtio/virtio.c > > @@ -27,6 +27,7 @@ > > #include "hw/virtio/virtio-access.h" > > #include "sysemu/dma.h" > > #include "sysemu/runstate.h" > > +#include "exec/host-trust-limitation.h" > > > > /* > > * The alignment to use between consumer and producer parts of vring. > > @@ -3618,6 +3619,12 @@ static void virtio_device_realize(DeviceState *dev, Error **errp) > > /* Devices should either use vmsd or the load/save methods */ > > assert(!vdc->vmsd || !vdc->load); > > > > + if (host_trust_limitation_enabled(MACHINE(qdev_get_machine())) > > + && !virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM)) { > > + error_setg(&err, "devices without VIRTIO_F_ACCESS_PLATFORM are not compatible with host trust imitation"); > > + error_propagate(errp, err); > > + return; > > How can we get here? I assume only if the user explicitly turned the > feature off while turning HTL on, as otherwise patch 9 should have > taken care of it? > Yes, we can get here only if iommu_platform is explicitly turned off. Regards, Halil
On Thu, Sep 10, 2020 at 08:29:24PM +0200, Halil Pasic wrote: > On Thu, 10 Sep 2020 13:36:09 +0200 > Cornelia Huck <cohuck@redhat.com> wrote: > > > On Mon, 7 Sep 2020 17:22:53 +0200 > > Halil Pasic <pasic@linux.ibm.com> wrote: > > > > > On Fri, 24 Jul 2020 12:57:44 +1000 > > > David Gibson <david@gibson.dropbear.id.au> wrote: > > > > > > > At least some s390 cpu models support "Protected Virtualization" (PV), > > > > a mechanism to protect guests from eavesdropping by a compromised > > > > hypervisor. > > > > > > > > This is similar in function to other mechanisms like AMD's SEV and > > > > POWER's PEF, which are controlled bythe "host-trust-limitation" > > > > machine option. s390 is a slightly special case, because we already > > > > supported PV, simply by using a CPU model with the required feature > > > > (S390_FEAT_UNPACK). > > > > > > > > To integrate this with the option used by other platforms, we > > > > implement the following compromise: > > > > > > > > - When the host-trust-limitation option is set, s390 will recognize > > > > it, verify that the CPU can support PV (failing if not) and set > > > > virtio default options necessary for encrypted or protected guests, > > > > as on other platforms. i.e. if host-trust-limitation is set, we > > > > will either create a guest capable of entering PV mode, or fail > > > > outright > > > > > > Shouldn't we also fail outright if the virtio features are not PV > > > compatible (invalid configuration)? > > > > > > I would like to see something like follows as a part of this series. > > > ----------------------------8<-------------------------- > > > From: Halil Pasic <pasic@linux.ibm.com> > > > Date: Mon, 7 Sep 2020 15:00:17 +0200 > > > Subject: [PATCH] virtio: handle host trust limitation > > > > > > If host_trust_limitation_enabled() returns true, then emulated virtio > > > devices must offer VIRTIO_F_ACCESS_PLATFORM, because the device is not > > > capable of accessing all of the guest memory. Otherwise we are in > > > violation of the virtio specification. > > > > > > Let's fail realize if we detect that VIRTIO_F_ACCESS_PLATFORM feature is > > > obligatory but missing. > > > > > > Signed-off-by: Halil Pasic <pasic@linux.ibm.com> > > > --- > > > hw/virtio/virtio.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c > > > index 5bd2a2f621..19b4b0a37a 100644 > > > --- a/hw/virtio/virtio.c > > > +++ b/hw/virtio/virtio.c > > > @@ -27,6 +27,7 @@ > > > #include "hw/virtio/virtio-access.h" > > > #include "sysemu/dma.h" > > > #include "sysemu/runstate.h" > > > +#include "exec/host-trust-limitation.h" > > > > > > /* > > > * The alignment to use between consumer and producer parts of vring. > > > @@ -3618,6 +3619,12 @@ static void virtio_device_realize(DeviceState *dev, Error **errp) > > > /* Devices should either use vmsd or the load/save methods */ > > > assert(!vdc->vmsd || !vdc->load); > > > > > > + if (host_trust_limitation_enabled(MACHINE(qdev_get_machine())) > > > + && !virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM)) { > > > + error_setg(&err, "devices without VIRTIO_F_ACCESS_PLATFORM are not compatible with host trust imitation"); > > > + error_propagate(errp, err); > > > + return; > > > > How can we get here? I assume only if the user explicitly turned the > > feature off while turning HTL on, as otherwise patch 9 should have > > taken care of it? > > > > Yes, we can get here only if iommu_platform is explicitly turned off. Right.. my assumption was that if you really want to specify contradictory options, you get to keep both pieces. Or, more seriously, there might be some weird experimental cases where this combination could do something useful if you really know what you're doing, and explicitly telling qemu to do this implies you know what you're doing.
diff --git a/hw/s390x/pv.c b/hw/s390x/pv.c index ab3a2482aa..4bf3b345b6 100644 --- a/hw/s390x/pv.c +++ b/hw/s390x/pv.c @@ -14,8 +14,11 @@ #include <linux/kvm.h> #include "cpu.h" +#include "qapi/error.h" #include "qemu/error-report.h" #include "sysemu/kvm.h" +#include "qom/object_interfaces.h" +#include "exec/host-trust-limitation.h" #include "hw/s390x/ipl.h" #include "hw/s390x/pv.h" @@ -111,3 +114,61 @@ void s390_pv_inject_reset_error(CPUState *cs) /* Report that we are unable to enter protected mode */ env->regs[r1 + 1] = DIAG_308_RC_INVAL_FOR_PV; } + +#define TYPE_S390_PV_GUEST "s390-pv-guest" +#define S390_PV_GUEST(obj) \ + OBJECT_CHECK(S390PVGuestState, (obj), TYPE_S390_PV_GUEST) + +typedef struct S390PVGuestState S390PVGuestState; + +/** + * S390PVGuestState: + * + * The S390PVGuestState object is basically a dummy used to tell the + * host trust limitation system to use s390's PV mechanism. guest. + * + * # $QEMU \ + * -object s390-pv-guest,id=pv0 \ + * -machine ...,host-trust-limitation=pv0 + */ +struct S390PVGuestState { + Object parent_obj; +}; + +static int s390_pv_kvm_init(HostTrustLimitation *gmpo, Error **errp) +{ + if (!s390_has_feat(S390_FEAT_UNPACK)) { + error_setg(errp, + "CPU model does not support Protected Virtualization"); + return -1; + } + + return 0; +} + +static void s390_pv_guest_class_init(ObjectClass *oc, void *data) +{ + HostTrustLimitationClass *gmpc = HOST_TRUST_LIMITATION_CLASS(oc); + + gmpc->kvm_init = s390_pv_kvm_init; +} + +static const TypeInfo s390_pv_guest_info = { + .parent = TYPE_OBJECT, + .name = TYPE_S390_PV_GUEST, + .instance_size = sizeof(S390PVGuestState), + .class_init = s390_pv_guest_class_init, + .interfaces = (InterfaceInfo[]) { + { TYPE_HOST_TRUST_LIMITATION }, + { TYPE_USER_CREATABLE }, + { } + } +}; + +static void +s390_pv_register_types(void) +{ + type_register_static(&s390_pv_guest_info); +} + +type_init(s390_pv_register_types);
At least some s390 cpu models support "Protected Virtualization" (PV), a mechanism to protect guests from eavesdropping by a compromised hypervisor. This is similar in function to other mechanisms like AMD's SEV and POWER's PEF, which are controlled bythe "host-trust-limitation" machine option. s390 is a slightly special case, because we already supported PV, simply by using a CPU model with the required feature (S390_FEAT_UNPACK). To integrate this with the option used by other platforms, we implement the following compromise: - When the host-trust-limitation option is set, s390 will recognize it, verify that the CPU can support PV (failing if not) and set virtio default options necessary for encrypted or protected guests, as on other platforms. i.e. if host-trust-limitation is set, we will either create a guest capable of entering PV mode, or fail outright - If host-trust-limitation is not set, guest's might still be able to enter PV mode, if the CPU has the right model. This may be a little surprising, but shouldn't actually be harmful. To start a guest supporting Protected Virtualization using the new option use the command line arguments: -object s390-pv-guest,id=pv0 -machine host-trust-limitation=pv0 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> --- hw/s390x/pv.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+)