From: Halil Pasic <pasic@linux.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: dgilbert@redhat.com, frankja@linux.ibm.com, pair@us.ibm.com,
qemu-devel@nongnu.org, pbonzini@redhat.com,
brijesh.singh@amd.com, ehabkost@redhat.com,
marcel.apfelbaum@gmail.com, "Michael S. Tsirkin" <mst@redhat.com>,
qemu-ppc@nongnu.org, kvm@vger.kernel.org, qemu-s390x@nongnu.org,
"David Hildenbrand" <david@redhat.com>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Richard Henderson" <rth@twiddle.net>,
"Daniel P. Berrangé" <berrange@redhat.com>,
mdroth@linux.vnet.ibm.com, "Thomas Huth" <thuth@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>
Subject: Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
Date: Mon, 7 Sep 2020 17:22:53 +0200 [thread overview]
Message-ID: <20200907172253.0a51f5f7.pasic@linux.ibm.com> (raw)
In-Reply-To: <20200724025744.69644-11-david@gibson.dropbear.id.au>
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;
+ }
if (vdc->realize != NULL) {
vdc->realize(dev, &err);
if (err != NULL) {
--
2.21.0
WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: pair@us.ibm.com, "Cornelia Huck" <cohuck@redhat.com>,
brijesh.singh@amd.com, frankja@linux.ibm.com,
kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
qemu-devel@nongnu.org, dgilbert@redhat.com,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, qemu-ppc@nongnu.org,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
pbonzini@redhat.com, "Richard Henderson" <rth@twiddle.net>,
mdroth@linux.vnet.ibm.com, ehabkost@redhat.com
Subject: Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
Date: Mon, 7 Sep 2020 17:22:53 +0200 [thread overview]
Message-ID: <20200907172253.0a51f5f7.pasic@linux.ibm.com> (raw)
In-Reply-To: <20200724025744.69644-11-david@gibson.dropbear.id.au>
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;
+ }
if (vdc->realize != NULL) {
vdc->realize(dev, &err);
if (err != NULL) {
--
2.21.0
next prev parent reply other threads:[~2020-09-07 15:25 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 2:57 [for-5.2 v4 00/10] Generalize memory encryption models David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 01/10] host trust limitation: Introduce new host trust limitation interface David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 02/10] host trust limitation: Handle memory encryption via interface David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 03/10] host trust limitation: Move side effect out of machine_set_memory_encryption() David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 04/10] host trust limitation: Rework the "memory-encryption" property David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 05/10] host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 06/10] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 07/10] spapr: Add PEF based host trust limitation David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-24 2:57 ` [for-5.2 v4 08/10] spapr: PEF: block migration David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-27 15:01 ` Dr. David Alan Gilbert
2020-07-27 15:01 ` Dr. David Alan Gilbert
2020-07-24 2:57 ` [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-27 15:05 ` Dr. David Alan Gilbert
2020-07-27 15:05 ` Dr. David Alan Gilbert
2020-08-13 7:43 ` Greg Kurz
2020-08-13 7:43 ` Greg Kurz
2020-08-13 8:19 ` Greg Kurz
2020-08-13 8:19 ` Greg Kurz
2020-09-07 15:10 ` Halil Pasic
2020-09-07 15:10 ` Halil Pasic
2020-09-11 2:04 ` David Gibson
2020-09-11 2:04 ` David Gibson
2020-09-11 13:49 ` Halil Pasic
2020-09-11 13:49 ` Halil Pasic
2020-07-24 2:57 ` [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option David Gibson
2020-07-24 2:57 ` David Gibson
2020-07-27 15:50 ` Cornelia Huck
2020-07-27 15:50 ` Cornelia Huck
2020-08-03 7:40 ` Janosch Frank
2020-08-03 7:40 ` Janosch Frank
2020-08-06 6:14 ` David Gibson
2020-08-06 6:14 ` David Gibson
2020-08-06 7:18 ` David Hildenbrand
2020-08-06 7:18 ` David Hildenbrand
2020-08-03 7:49 ` Janosch Frank
2020-08-03 7:49 ` Janosch Frank
2020-08-03 7:54 ` David Gibson
2020-08-03 7:54 ` David Gibson
2020-08-03 8:07 ` Janosch Frank
2020-08-03 8:07 ` Janosch Frank
2020-08-03 8:14 ` David Gibson
2020-08-03 8:14 ` David Gibson
2020-08-03 8:33 ` Cornelia Huck
2020-08-03 8:33 ` Cornelia Huck
2020-09-07 15:22 ` Halil Pasic [this message]
2020-09-07 15:22 ` Halil Pasic
2020-09-10 11:36 ` Cornelia Huck
2020-09-10 11:36 ` Cornelia Huck
2020-09-10 18:29 ` Halil Pasic
2020-09-10 18:29 ` Halil Pasic
2020-09-11 0:07 ` David Gibson
2020-09-11 0:07 ` David Gibson
2020-09-11 6:25 ` Greg Kurz
2020-09-11 6:25 ` Greg Kurz
2020-09-11 12:45 ` Halil Pasic
2020-09-11 12:45 ` Halil Pasic
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=20200907172253.0a51f5f7.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=brijesh.singh@amd.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.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=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.