* [for-5.2 v4 00/10] Generalize memory encryption models
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck
A number of hardware platforms are implementing mechanisms whereby the
hypervisor does not have unfettered access to guest memory, in order
to mitigate the security impact of a compromised hypervisor.
AMD's SEV implements this with in-cpu memory encryption, and Intel has
its own memory encryption mechanism. POWER has an upcoming mechanism
to accomplish this in a different way, using a new memory protection
level plus a small trusted ultravisor. s390 also has a protected
execution environment.
The current code (committed or draft) for these features has each
platform's version configured entirely differently. That doesn't seem
ideal for users, or particularly for management layers.
AMD SEV introduces a notionally generic machine option
"machine-encryption", but it doesn't actually cover any cases other
than SEV.
This series is a proposal to at least partially unify configuration
for these mechanisms, by renaming and generalizing AMD's
"memory-encryption" property. It is replaced by a
"host-trust-limitation" property pointing to a platform specific
object which configures and manages the specific details.
Please apply.
Changes since v3:
* Rebased
* Added first cut at handling of s390 protected virtualization
Changes since RFCv2:
* Rebased
* Removed preliminary SEV cleanups (they've been merged)
* Changed name to "host trust limitation"
* Added migration blocker to the PEF code (based on SEV's version)
Changes since RFCv1:
* Rebased
* Fixed some errors pointed out by Dave Gilbert
David Gibson (10):
host trust limitation: Introduce new host trust limitation interface
host trust limitation: Handle memory encryption via interface
host trust limitation: Move side effect out of
machine_set_memory_encryption()
host trust limitation: Rework the "memory-encryption" property
host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM
host trust limitation: Add Error ** to HostTrustLimitation::kvm_init
spapr: Add PEF based host trust limitation
spapr: PEF: block migration
host trust limitation: Alter virtio default properties for protected
guests
s390: Recognize host-trust-limitation option
accel/kvm/kvm-all.c | 40 ++------
accel/kvm/sev-stub.c | 7 +-
accel/stubs/kvm-stub.c | 10 --
backends/Makefile.objs | 2 +
backends/host-trust-limitation.c | 29 ++++++
hw/core/machine.c | 61 +++++++++--
hw/i386/pc_sysfw.c | 6 +-
hw/s390x/pv.c | 61 +++++++++++
include/exec/host-trust-limitation.h | 72 +++++++++++++
include/hw/boards.h | 2 +-
include/qemu/typedefs.h | 1 +
include/sysemu/kvm.h | 17 ---
include/sysemu/sev.h | 4 +-
target/i386/sev.c | 148 ++++++++++++---------------
target/ppc/Makefile.objs | 2 +-
target/ppc/pef.c | 89 ++++++++++++++++
16 files changed, 387 insertions(+), 164 deletions(-)
create mode 100644 backends/host-trust-limitation.c
create mode 100644 include/exec/host-trust-limitation.h
create mode 100644 target/ppc/pef.c
--
2.26.2
^ permalink raw reply [flat|nested] 66+ messages in thread
* [for-5.2 v4 00/10] Generalize memory encryption models
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson, David Gibson
A number of hardware platforms are implementing mechanisms whereby the
hypervisor does not have unfettered access to guest memory, in order
to mitigate the security impact of a compromised hypervisor.
AMD's SEV implements this with in-cpu memory encryption, and Intel has
its own memory encryption mechanism. POWER has an upcoming mechanism
to accomplish this in a different way, using a new memory protection
level plus a small trusted ultravisor. s390 also has a protected
execution environment.
The current code (committed or draft) for these features has each
platform's version configured entirely differently. That doesn't seem
ideal for users, or particularly for management layers.
AMD SEV introduces a notionally generic machine option
"machine-encryption", but it doesn't actually cover any cases other
than SEV.
This series is a proposal to at least partially unify configuration
for these mechanisms, by renaming and generalizing AMD's
"memory-encryption" property. It is replaced by a
"host-trust-limitation" property pointing to a platform specific
object which configures and manages the specific details.
Please apply.
Changes since v3:
* Rebased
* Added first cut at handling of s390 protected virtualization
Changes since RFCv2:
* Rebased
* Removed preliminary SEV cleanups (they've been merged)
* Changed name to "host trust limitation"
* Added migration blocker to the PEF code (based on SEV's version)
Changes since RFCv1:
* Rebased
* Fixed some errors pointed out by Dave Gilbert
David Gibson (10):
host trust limitation: Introduce new host trust limitation interface
host trust limitation: Handle memory encryption via interface
host trust limitation: Move side effect out of
machine_set_memory_encryption()
host trust limitation: Rework the "memory-encryption" property
host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM
host trust limitation: Add Error ** to HostTrustLimitation::kvm_init
spapr: Add PEF based host trust limitation
spapr: PEF: block migration
host trust limitation: Alter virtio default properties for protected
guests
s390: Recognize host-trust-limitation option
accel/kvm/kvm-all.c | 40 ++------
accel/kvm/sev-stub.c | 7 +-
accel/stubs/kvm-stub.c | 10 --
backends/Makefile.objs | 2 +
backends/host-trust-limitation.c | 29 ++++++
hw/core/machine.c | 61 +++++++++--
hw/i386/pc_sysfw.c | 6 +-
hw/s390x/pv.c | 61 +++++++++++
include/exec/host-trust-limitation.h | 72 +++++++++++++
include/hw/boards.h | 2 +-
include/qemu/typedefs.h | 1 +
include/sysemu/kvm.h | 17 ---
include/sysemu/sev.h | 4 +-
target/i386/sev.c | 148 ++++++++++++---------------
target/ppc/Makefile.objs | 2 +-
target/ppc/pef.c | 89 ++++++++++++++++
16 files changed, 387 insertions(+), 164 deletions(-)
create mode 100644 backends/host-trust-limitation.c
create mode 100644 include/exec/host-trust-limitation.h
create mode 100644 target/ppc/pef.c
--
2.26.2
^ permalink raw reply [flat|nested] 66+ messages in thread
* [for-5.2 v4 01/10] host trust limitation: Introduce new host trust limitation interface
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Richard Henderson
Several architectures have mechanisms which are designed to protect guest
memory from interference or eavesdropping by a compromised hypervisor. AMD
SEV does this with in-chip memory encryption and Intel has a similar
mechanism. POWER's Protected Execution Framework (PEF) accomplishes a
similar goal using an ultravisor and new memory protection features,
instead of encryption.
To (partially) unify handling for these, this introduces a new
HostTrustLimitation QOM interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
backends/Makefile.objs | 2 ++
backends/host-trust-limitation.c | 29 ++++++++++++++++++++++++
include/exec/host-trust-limitation.h | 33 ++++++++++++++++++++++++++++
include/qemu/typedefs.h | 1 +
4 files changed, 65 insertions(+)
create mode 100644 backends/host-trust-limitation.c
create mode 100644 include/exec/host-trust-limitation.h
diff --git a/backends/Makefile.objs b/backends/Makefile.objs
index 22d204cb48..dcb8f58d31 100644
--- a/backends/Makefile.objs
+++ b/backends/Makefile.objs
@@ -21,3 +21,5 @@ common-obj-$(CONFIG_LINUX) += hostmem-memfd.o
common-obj-$(CONFIG_GIO) += dbus-vmstate.o
dbus-vmstate.o-cflags = $(GIO_CFLAGS)
dbus-vmstate.o-libs = $(GIO_LIBS)
+
+common-obj-y += host-trust-limitation.o
diff --git a/backends/host-trust-limitation.c b/backends/host-trust-limitation.c
new file mode 100644
index 0000000000..96a381cd8a
--- /dev/null
+++ b/backends/host-trust-limitation.c
@@ -0,0 +1,29 @@
+/*
+ * QEMU Host Trust Limitation interface
+ *
+ * Copyright: David Gibson, Red Hat Inc. 2020
+ *
+ * Authors:
+ * David Gibson <david@gibson.dropbear.id.au>
+ *
+ * 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"
+
+#include "exec/host-trust-limitation.h"
+
+static const TypeInfo host_trust_limitation_info = {
+ .name = TYPE_HOST_TRUST_LIMITATION,
+ .parent = TYPE_INTERFACE,
+ .class_size = sizeof(HostTrustLimitationClass),
+};
+
+static void host_trust_limitation_register_types(void)
+{
+ type_register_static(&host_trust_limitation_info);
+}
+
+type_init(host_trust_limitation_register_types)
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
new file mode 100644
index 0000000000..03887b1be1
--- /dev/null
+++ b/include/exec/host-trust-limitation.h
@@ -0,0 +1,33 @@
+/*
+ * QEMU Host Trust Limitation interface
+ *
+ * Copyright: David Gibson, Red Hat Inc. 2020
+ *
+ * Authors:
+ * David Gibson <david@gibson.dropbear.id.au>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ *
+ */
+#ifndef QEMU_HOST_TRUST_LIMITATION_H
+#define QEMU_HOST_TRUST_LIMITATION_H
+
+#include "qom/object.h"
+
+#define TYPE_HOST_TRUST_LIMITATION "host-trust-limitation"
+#define HOST_TRUST_LIMITATION(obj) \
+ INTERFACE_CHECK(HostTrustLimitation, (obj), \
+ TYPE_HOST_TRUST_LIMITATION)
+#define HOST_TRUST_LIMITATION_CLASS(klass) \
+ OBJECT_CLASS_CHECK(HostTrustLimitationClass, (klass), \
+ TYPE_HOST_TRUST_LIMITATION)
+#define HOST_TRUST_LIMITATION_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(HostTrustLimitationClass, (obj), \
+ TYPE_HOST_TRUST_LIMITATION)
+
+typedef struct HostTrustLimitationClass {
+ InterfaceClass parent;
+} HostTrustLimitationClass;
+
+#endif /* QEMU_HOST_TRUST_LIMITATION_H */
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 427027a970..624d59c037 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -51,6 +51,7 @@ typedef struct FWCfgIoState FWCfgIoState;
typedef struct FWCfgMemState FWCfgMemState;
typedef struct FWCfgState FWCfgState;
typedef struct HostMemoryBackend HostMemoryBackend;
+typedef struct HostTrustLimitation HostTrustLimitation;
typedef struct I2CBus I2CBus;
typedef struct I2SCodec I2SCodec;
typedef struct IOMMUMemoryRegion IOMMUMemoryRegion;
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 01/10] host trust limitation: Introduce new host trust limitation interface
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand,
Richard Henderson, mdroth, pasic, Christian Borntraeger,
qemu-s390x, qemu-ppc, Richard Henderson, David Gibson
Several architectures have mechanisms which are designed to protect guest
memory from interference or eavesdropping by a compromised hypervisor. AMD
SEV does this with in-chip memory encryption and Intel has a similar
mechanism. POWER's Protected Execution Framework (PEF) accomplishes a
similar goal using an ultravisor and new memory protection features,
instead of encryption.
To (partially) unify handling for these, this introduces a new
HostTrustLimitation QOM interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
backends/Makefile.objs | 2 ++
backends/host-trust-limitation.c | 29 ++++++++++++++++++++++++
include/exec/host-trust-limitation.h | 33 ++++++++++++++++++++++++++++
include/qemu/typedefs.h | 1 +
4 files changed, 65 insertions(+)
create mode 100644 backends/host-trust-limitation.c
create mode 100644 include/exec/host-trust-limitation.h
diff --git a/backends/Makefile.objs b/backends/Makefile.objs
index 22d204cb48..dcb8f58d31 100644
--- a/backends/Makefile.objs
+++ b/backends/Makefile.objs
@@ -21,3 +21,5 @@ common-obj-$(CONFIG_LINUX) += hostmem-memfd.o
common-obj-$(CONFIG_GIO) += dbus-vmstate.o
dbus-vmstate.o-cflags = $(GIO_CFLAGS)
dbus-vmstate.o-libs = $(GIO_LIBS)
+
+common-obj-y += host-trust-limitation.o
diff --git a/backends/host-trust-limitation.c b/backends/host-trust-limitation.c
new file mode 100644
index 0000000000..96a381cd8a
--- /dev/null
+++ b/backends/host-trust-limitation.c
@@ -0,0 +1,29 @@
+/*
+ * QEMU Host Trust Limitation interface
+ *
+ * Copyright: David Gibson, Red Hat Inc. 2020
+ *
+ * Authors:
+ * David Gibson <david@gibson.dropbear.id.au>
+ *
+ * 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"
+
+#include "exec/host-trust-limitation.h"
+
+static const TypeInfo host_trust_limitation_info = {
+ .name = TYPE_HOST_TRUST_LIMITATION,
+ .parent = TYPE_INTERFACE,
+ .class_size = sizeof(HostTrustLimitationClass),
+};
+
+static void host_trust_limitation_register_types(void)
+{
+ type_register_static(&host_trust_limitation_info);
+}
+
+type_init(host_trust_limitation_register_types)
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
new file mode 100644
index 0000000000..03887b1be1
--- /dev/null
+++ b/include/exec/host-trust-limitation.h
@@ -0,0 +1,33 @@
+/*
+ * QEMU Host Trust Limitation interface
+ *
+ * Copyright: David Gibson, Red Hat Inc. 2020
+ *
+ * Authors:
+ * David Gibson <david@gibson.dropbear.id.au>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ *
+ */
+#ifndef QEMU_HOST_TRUST_LIMITATION_H
+#define QEMU_HOST_TRUST_LIMITATION_H
+
+#include "qom/object.h"
+
+#define TYPE_HOST_TRUST_LIMITATION "host-trust-limitation"
+#define HOST_TRUST_LIMITATION(obj) \
+ INTERFACE_CHECK(HostTrustLimitation, (obj), \
+ TYPE_HOST_TRUST_LIMITATION)
+#define HOST_TRUST_LIMITATION_CLASS(klass) \
+ OBJECT_CLASS_CHECK(HostTrustLimitationClass, (klass), \
+ TYPE_HOST_TRUST_LIMITATION)
+#define HOST_TRUST_LIMITATION_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(HostTrustLimitationClass, (obj), \
+ TYPE_HOST_TRUST_LIMITATION)
+
+typedef struct HostTrustLimitationClass {
+ InterfaceClass parent;
+} HostTrustLimitationClass;
+
+#endif /* QEMU_HOST_TRUST_LIMITATION_H */
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 427027a970..624d59c037 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -51,6 +51,7 @@ typedef struct FWCfgIoState FWCfgIoState;
typedef struct FWCfgMemState FWCfgMemState;
typedef struct FWCfgState FWCfgState;
typedef struct HostMemoryBackend HostMemoryBackend;
+typedef struct HostTrustLimitation HostTrustLimitation;
typedef struct I2CBus I2CBus;
typedef struct I2SCodec I2SCodec;
typedef struct IOMMUMemoryRegion IOMMUMemoryRegion;
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 02/10] host trust limitation: Handle memory encryption via interface
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Richard Henderson
At the moment AMD SEV sets a special function pointer, plus an opaque
handle in KVMState to let things know how to encrypt guest memory.
Now that we have a QOM interface for handling things related to host trust
limitation, use a QOM method on that interface, rather than a bare function
pointer for this.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 38 ++++++---
accel/kvm/sev-stub.c | 7 +-
include/exec/host-trust-limitation.h | 3 +
include/sysemu/sev.h | 4 +-
target/i386/sev.c | 119 +++++++++++----------------
5 files changed, 80 insertions(+), 91 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 63ef6af9a1..d7d95eacc7 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -39,11 +39,11 @@
#include "qemu/main-loop.h"
#include "trace.h"
#include "hw/irq.h"
-#include "sysemu/sev.h"
#include "qapi/visitor.h"
#include "qapi/qapi-types-common.h"
#include "qapi/qapi-visit-common.h"
#include "sysemu/reset.h"
+#include "exec/host-trust-limitation.h"
#include "hw/boards.h"
@@ -117,9 +117,8 @@ struct KVMState
KVMMemoryListener memory_listener;
QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
- /* memory encryption */
- void *memcrypt_handle;
- int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
+ /* host trust limitation (e.g. by guest memory encryption) */
+ HostTrustLimitation *htl;
/* For "info mtree -f" to tell if an MR is registered in KVM */
int nr_as;
@@ -221,7 +220,7 @@ int kvm_get_max_memslots(void)
bool kvm_memcrypt_enabled(void)
{
- if (kvm_state && kvm_state->memcrypt_handle) {
+ if (kvm_state && kvm_state->htl) {
return true;
}
@@ -230,10 +229,12 @@ bool kvm_memcrypt_enabled(void)
int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
{
- if (kvm_state->memcrypt_handle &&
- kvm_state->memcrypt_encrypt_data) {
- return kvm_state->memcrypt_encrypt_data(kvm_state->memcrypt_handle,
- ptr, len);
+ HostTrustLimitation *htl = kvm_state->htl;
+
+ if (htl) {
+ HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_GET_CLASS(htl);
+
+ return htlc->encrypt_data(htl, ptr, len);
}
return 1;
@@ -2186,13 +2187,24 @@ static int kvm_init(MachineState *ms)
* encryption context.
*/
if (ms->memory_encryption) {
- kvm_state->memcrypt_handle = sev_guest_init(ms->memory_encryption);
- if (!kvm_state->memcrypt_handle) {
+ Object *obj = object_resolve_path_component(object_get_objects_root(),
+ ms->memory_encryption);
+
+ if (object_dynamic_cast(obj, TYPE_HOST_TRUST_LIMITATION)) {
+ HostTrustLimitation *htl = HOST_TRUST_LIMITATION(obj);
+ HostTrustLimitationClass *htlc
+ = HOST_TRUST_LIMITATION_GET_CLASS(htl);
+
+ ret = htlc->kvm_init(htl);
+ if (ret < 0) {
+ goto err;
+ }
+
+ kvm_state->htl = htl;
+ } else {
ret = -1;
goto err;
}
-
- kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
}
ret = kvm_arch_init(ms, s);
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 4f97452585..9c7c897593 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -15,12 +15,7 @@
#include "qemu-common.h"
#include "sysemu/sev.h"
-int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
-{
- abort();
-}
-
-void *sev_guest_init(const char *id)
+HostTrustLimitation *sev_guest_init(const char *id)
{
return NULL;
}
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
index 03887b1be1..a19f12ae14 100644
--- a/include/exec/host-trust-limitation.h
+++ b/include/exec/host-trust-limitation.h
@@ -28,6 +28,9 @@
typedef struct HostTrustLimitationClass {
InterfaceClass parent;
+
+ int (*kvm_init)(HostTrustLimitation *);
+ int (*encrypt_data)(HostTrustLimitation *, uint8_t *, uint64_t);
} HostTrustLimitationClass;
#endif /* QEMU_HOST_TRUST_LIMITATION_H */
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 98c1ec8d38..a4aee6a87d 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -16,6 +16,6 @@
#include "sysemu/kvm.h"
-void *sev_guest_init(const char *id);
-int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+HostTrustLimitation *sev_guest_init(const char *id);
+
#endif
diff --git a/target/i386/sev.c b/target/i386/sev.c
index c3ecf86704..8e3c9dcc2c 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -28,6 +28,7 @@
#include "sysemu/runstate.h"
#include "trace.h"
#include "migration/blocker.h"
+#include "exec/host-trust-limitation.h"
#define TYPE_SEV_GUEST "sev-guest"
#define SEV_GUEST(obj) \
@@ -281,26 +282,6 @@ sev_guest_set_sev_device(Object *obj, const char *value, Error **errp)
sev->sev_device = g_strdup(value);
}
-static void
-sev_guest_class_init(ObjectClass *oc, void *data)
-{
- object_class_property_add_str(oc, "sev-device",
- sev_guest_get_sev_device,
- sev_guest_set_sev_device);
- object_class_property_set_description(oc, "sev-device",
- "SEV device to use");
- object_class_property_add_str(oc, "dh-cert-file",
- sev_guest_get_dh_cert_file,
- sev_guest_set_dh_cert_file);
- object_class_property_set_description(oc, "dh-cert-file",
- "guest owners DH certificate (encoded with base64)");
- object_class_property_add_str(oc, "session-file",
- sev_guest_get_session_file,
- sev_guest_set_session_file);
- object_class_property_set_description(oc, "session-file",
- "guest owners session parameters (encoded with base64)");
-}
-
static void
sev_guest_instance_init(Object *obj)
{
@@ -319,40 +300,6 @@ sev_guest_instance_init(Object *obj)
OBJ_PROP_FLAG_READWRITE);
}
-/* sev guest info */
-static const TypeInfo sev_guest_info = {
- .parent = TYPE_OBJECT,
- .name = TYPE_SEV_GUEST,
- .instance_size = sizeof(SevGuestState),
- .instance_finalize = sev_guest_finalize,
- .class_init = sev_guest_class_init,
- .instance_init = sev_guest_instance_init,
- .interfaces = (InterfaceInfo[]) {
- { TYPE_USER_CREATABLE },
- { }
- }
-};
-
-static SevGuestState *
-lookup_sev_guest_info(const char *id)
-{
- Object *obj;
- SevGuestState *info;
-
- obj = object_resolve_path_component(object_get_objects_root(), id);
- if (!obj) {
- return NULL;
- }
-
- info = (SevGuestState *)
- object_dynamic_cast(obj, TYPE_SEV_GUEST);
- if (!info) {
- return NULL;
- }
-
- return info;
-}
-
bool
sev_enabled(void)
{
@@ -679,10 +626,9 @@ sev_vm_state_change(void *opaque, int running, RunState state)
}
}
-void *
-sev_guest_init(const char *id)
+static int sev_kvm_init(HostTrustLimitation *htl)
{
- SevGuestState *sev;
+ SevGuestState *sev = SEV_GUEST(htl);
char *devname;
int ret, fw_error;
uint32_t ebx;
@@ -692,14 +638,7 @@ sev_guest_init(const char *id)
ret = ram_block_discard_disable(true);
if (ret) {
error_report("%s: cannot disable RAM discard", __func__);
- return NULL;
- }
-
- sev = lookup_sev_guest_info(id);
- if (!sev) {
- error_report("%s: '%s' is not a valid '%s' object",
- __func__, id, TYPE_SEV_GUEST);
- goto err;
+ return -1;
}
sev_guest = sev;
@@ -763,17 +702,17 @@ sev_guest_init(const char *id)
qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
qemu_add_vm_change_state_handler(sev_vm_state_change, sev);
- return sev;
+ return 0;
err:
sev_guest = NULL;
ram_block_discard_disable(false);
- return NULL;
+ return -1;
}
-int
-sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
+static int
+sev_encrypt_data(HostTrustLimitation *opaque, uint8_t *ptr, uint64_t len)
{
- SevGuestState *sev = handle;
+ SevGuestState *sev = SEV_GUEST(opaque);
assert(sev);
@@ -785,6 +724,46 @@ sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
return 0;
}
+static void
+sev_guest_class_init(ObjectClass *oc, void *data)
+{
+ HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_CLASS(oc);
+
+ object_class_property_add_str(oc, "sev-device",
+ sev_guest_get_sev_device,
+ sev_guest_set_sev_device);
+ object_class_property_set_description(oc, "sev-device",
+ "SEV device to use");
+ object_class_property_add_str(oc, "dh-cert-file",
+ sev_guest_get_dh_cert_file,
+ sev_guest_set_dh_cert_file);
+ object_class_property_set_description(oc, "dh-cert-file",
+ "guest owners DH certificate (encoded with base64)");
+ object_class_property_add_str(oc, "session-file",
+ sev_guest_get_session_file,
+ sev_guest_set_session_file);
+ object_class_property_set_description(oc, "session-file",
+ "guest owners session parameters (encoded with base64)");
+
+ htlc->kvm_init = sev_kvm_init;
+ htlc->encrypt_data = sev_encrypt_data;
+}
+
+/* sev guest info */
+static const TypeInfo sev_guest_info = {
+ .parent = TYPE_OBJECT,
+ .name = TYPE_SEV_GUEST,
+ .instance_size = sizeof(SevGuestState),
+ .instance_finalize = sev_guest_finalize,
+ .class_init = sev_guest_class_init,
+ .instance_init = sev_guest_instance_init,
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_HOST_TRUST_LIMITATION },
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
static void
sev_register_types(void)
{
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 02/10] host trust limitation: Handle memory encryption via interface
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand,
Richard Henderson, mdroth, pasic, Christian Borntraeger,
qemu-s390x, qemu-ppc, Richard Henderson, David Gibson
At the moment AMD SEV sets a special function pointer, plus an opaque
handle in KVMState to let things know how to encrypt guest memory.
Now that we have a QOM interface for handling things related to host trust
limitation, use a QOM method on that interface, rather than a bare function
pointer for this.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 38 ++++++---
accel/kvm/sev-stub.c | 7 +-
include/exec/host-trust-limitation.h | 3 +
include/sysemu/sev.h | 4 +-
target/i386/sev.c | 119 +++++++++++----------------
5 files changed, 80 insertions(+), 91 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 63ef6af9a1..d7d95eacc7 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -39,11 +39,11 @@
#include "qemu/main-loop.h"
#include "trace.h"
#include "hw/irq.h"
-#include "sysemu/sev.h"
#include "qapi/visitor.h"
#include "qapi/qapi-types-common.h"
#include "qapi/qapi-visit-common.h"
#include "sysemu/reset.h"
+#include "exec/host-trust-limitation.h"
#include "hw/boards.h"
@@ -117,9 +117,8 @@ struct KVMState
KVMMemoryListener memory_listener;
QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
- /* memory encryption */
- void *memcrypt_handle;
- int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
+ /* host trust limitation (e.g. by guest memory encryption) */
+ HostTrustLimitation *htl;
/* For "info mtree -f" to tell if an MR is registered in KVM */
int nr_as;
@@ -221,7 +220,7 @@ int kvm_get_max_memslots(void)
bool kvm_memcrypt_enabled(void)
{
- if (kvm_state && kvm_state->memcrypt_handle) {
+ if (kvm_state && kvm_state->htl) {
return true;
}
@@ -230,10 +229,12 @@ bool kvm_memcrypt_enabled(void)
int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
{
- if (kvm_state->memcrypt_handle &&
- kvm_state->memcrypt_encrypt_data) {
- return kvm_state->memcrypt_encrypt_data(kvm_state->memcrypt_handle,
- ptr, len);
+ HostTrustLimitation *htl = kvm_state->htl;
+
+ if (htl) {
+ HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_GET_CLASS(htl);
+
+ return htlc->encrypt_data(htl, ptr, len);
}
return 1;
@@ -2186,13 +2187,24 @@ static int kvm_init(MachineState *ms)
* encryption context.
*/
if (ms->memory_encryption) {
- kvm_state->memcrypt_handle = sev_guest_init(ms->memory_encryption);
- if (!kvm_state->memcrypt_handle) {
+ Object *obj = object_resolve_path_component(object_get_objects_root(),
+ ms->memory_encryption);
+
+ if (object_dynamic_cast(obj, TYPE_HOST_TRUST_LIMITATION)) {
+ HostTrustLimitation *htl = HOST_TRUST_LIMITATION(obj);
+ HostTrustLimitationClass *htlc
+ = HOST_TRUST_LIMITATION_GET_CLASS(htl);
+
+ ret = htlc->kvm_init(htl);
+ if (ret < 0) {
+ goto err;
+ }
+
+ kvm_state->htl = htl;
+ } else {
ret = -1;
goto err;
}
-
- kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
}
ret = kvm_arch_init(ms, s);
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 4f97452585..9c7c897593 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -15,12 +15,7 @@
#include "qemu-common.h"
#include "sysemu/sev.h"
-int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
-{
- abort();
-}
-
-void *sev_guest_init(const char *id)
+HostTrustLimitation *sev_guest_init(const char *id)
{
return NULL;
}
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
index 03887b1be1..a19f12ae14 100644
--- a/include/exec/host-trust-limitation.h
+++ b/include/exec/host-trust-limitation.h
@@ -28,6 +28,9 @@
typedef struct HostTrustLimitationClass {
InterfaceClass parent;
+
+ int (*kvm_init)(HostTrustLimitation *);
+ int (*encrypt_data)(HostTrustLimitation *, uint8_t *, uint64_t);
} HostTrustLimitationClass;
#endif /* QEMU_HOST_TRUST_LIMITATION_H */
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 98c1ec8d38..a4aee6a87d 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -16,6 +16,6 @@
#include "sysemu/kvm.h"
-void *sev_guest_init(const char *id);
-int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+HostTrustLimitation *sev_guest_init(const char *id);
+
#endif
diff --git a/target/i386/sev.c b/target/i386/sev.c
index c3ecf86704..8e3c9dcc2c 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -28,6 +28,7 @@
#include "sysemu/runstate.h"
#include "trace.h"
#include "migration/blocker.h"
+#include "exec/host-trust-limitation.h"
#define TYPE_SEV_GUEST "sev-guest"
#define SEV_GUEST(obj) \
@@ -281,26 +282,6 @@ sev_guest_set_sev_device(Object *obj, const char *value, Error **errp)
sev->sev_device = g_strdup(value);
}
-static void
-sev_guest_class_init(ObjectClass *oc, void *data)
-{
- object_class_property_add_str(oc, "sev-device",
- sev_guest_get_sev_device,
- sev_guest_set_sev_device);
- object_class_property_set_description(oc, "sev-device",
- "SEV device to use");
- object_class_property_add_str(oc, "dh-cert-file",
- sev_guest_get_dh_cert_file,
- sev_guest_set_dh_cert_file);
- object_class_property_set_description(oc, "dh-cert-file",
- "guest owners DH certificate (encoded with base64)");
- object_class_property_add_str(oc, "session-file",
- sev_guest_get_session_file,
- sev_guest_set_session_file);
- object_class_property_set_description(oc, "session-file",
- "guest owners session parameters (encoded with base64)");
-}
-
static void
sev_guest_instance_init(Object *obj)
{
@@ -319,40 +300,6 @@ sev_guest_instance_init(Object *obj)
OBJ_PROP_FLAG_READWRITE);
}
-/* sev guest info */
-static const TypeInfo sev_guest_info = {
- .parent = TYPE_OBJECT,
- .name = TYPE_SEV_GUEST,
- .instance_size = sizeof(SevGuestState),
- .instance_finalize = sev_guest_finalize,
- .class_init = sev_guest_class_init,
- .instance_init = sev_guest_instance_init,
- .interfaces = (InterfaceInfo[]) {
- { TYPE_USER_CREATABLE },
- { }
- }
-};
-
-static SevGuestState *
-lookup_sev_guest_info(const char *id)
-{
- Object *obj;
- SevGuestState *info;
-
- obj = object_resolve_path_component(object_get_objects_root(), id);
- if (!obj) {
- return NULL;
- }
-
- info = (SevGuestState *)
- object_dynamic_cast(obj, TYPE_SEV_GUEST);
- if (!info) {
- return NULL;
- }
-
- return info;
-}
-
bool
sev_enabled(void)
{
@@ -679,10 +626,9 @@ sev_vm_state_change(void *opaque, int running, RunState state)
}
}
-void *
-sev_guest_init(const char *id)
+static int sev_kvm_init(HostTrustLimitation *htl)
{
- SevGuestState *sev;
+ SevGuestState *sev = SEV_GUEST(htl);
char *devname;
int ret, fw_error;
uint32_t ebx;
@@ -692,14 +638,7 @@ sev_guest_init(const char *id)
ret = ram_block_discard_disable(true);
if (ret) {
error_report("%s: cannot disable RAM discard", __func__);
- return NULL;
- }
-
- sev = lookup_sev_guest_info(id);
- if (!sev) {
- error_report("%s: '%s' is not a valid '%s' object",
- __func__, id, TYPE_SEV_GUEST);
- goto err;
+ return -1;
}
sev_guest = sev;
@@ -763,17 +702,17 @@ sev_guest_init(const char *id)
qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
qemu_add_vm_change_state_handler(sev_vm_state_change, sev);
- return sev;
+ return 0;
err:
sev_guest = NULL;
ram_block_discard_disable(false);
- return NULL;
+ return -1;
}
-int
-sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
+static int
+sev_encrypt_data(HostTrustLimitation *opaque, uint8_t *ptr, uint64_t len)
{
- SevGuestState *sev = handle;
+ SevGuestState *sev = SEV_GUEST(opaque);
assert(sev);
@@ -785,6 +724,46 @@ sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
return 0;
}
+static void
+sev_guest_class_init(ObjectClass *oc, void *data)
+{
+ HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_CLASS(oc);
+
+ object_class_property_add_str(oc, "sev-device",
+ sev_guest_get_sev_device,
+ sev_guest_set_sev_device);
+ object_class_property_set_description(oc, "sev-device",
+ "SEV device to use");
+ object_class_property_add_str(oc, "dh-cert-file",
+ sev_guest_get_dh_cert_file,
+ sev_guest_set_dh_cert_file);
+ object_class_property_set_description(oc, "dh-cert-file",
+ "guest owners DH certificate (encoded with base64)");
+ object_class_property_add_str(oc, "session-file",
+ sev_guest_get_session_file,
+ sev_guest_set_session_file);
+ object_class_property_set_description(oc, "session-file",
+ "guest owners session parameters (encoded with base64)");
+
+ htlc->kvm_init = sev_kvm_init;
+ htlc->encrypt_data = sev_encrypt_data;
+}
+
+/* sev guest info */
+static const TypeInfo sev_guest_info = {
+ .parent = TYPE_OBJECT,
+ .name = TYPE_SEV_GUEST,
+ .instance_size = sizeof(SevGuestState),
+ .instance_finalize = sev_guest_finalize,
+ .class_init = sev_guest_class_init,
+ .instance_init = sev_guest_instance_init,
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_HOST_TRUST_LIMITATION },
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
static void
sev_register_types(void)
{
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 03/10] host trust limitation: Move side effect out of machine_set_memory_encryption()
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Richard Henderson
When the "memory-encryption" property is set, we also disable KSM
merging for the guest, since it won't accomplish anything.
We want that, but doing it in the property set function itself is
thereoretically incorrect, in the unlikely event of some configuration
environment that set the property then cleared it again before
constructing the guest.
More importantly, it makes some other cleanups we want more difficult.
So, instead move this logic to machine_run_board_init() conditional on
the final value of the property.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
hw/core/machine.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 2f881d6d75..035a1fc631 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -432,14 +432,6 @@ static void machine_set_memory_encryption(Object *obj, const char *value,
g_free(ms->memory_encryption);
ms->memory_encryption = g_strdup(value);
-
- /*
- * With memory encryption, the host can't see the real contents of RAM,
- * so there's no point in it trying to merge areas.
- */
- if (value) {
- machine_set_mem_merge(obj, false, errp);
- }
}
static bool machine_get_nvdimm(Object *obj, Error **errp)
@@ -1131,6 +1123,15 @@ void machine_run_board_init(MachineState *machine)
}
}
+ if (machine->memory_encryption) {
+ /*
+ * With host trust limitation, the host can't see the real
+ * contents of RAM, so there's no point in it trying to merge
+ * areas.
+ */
+ machine_set_mem_merge(OBJECT(machine), false, &error_abort);
+ }
+
machine_class->init(machine);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 03/10] host trust limitation: Move side effect out of machine_set_memory_encryption()
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand,
Richard Henderson, mdroth, pasic, Christian Borntraeger,
qemu-s390x, qemu-ppc, Richard Henderson, David Gibson
When the "memory-encryption" property is set, we also disable KSM
merging for the guest, since it won't accomplish anything.
We want that, but doing it in the property set function itself is
thereoretically incorrect, in the unlikely event of some configuration
environment that set the property then cleared it again before
constructing the guest.
More importantly, it makes some other cleanups we want more difficult.
So, instead move this logic to machine_run_board_init() conditional on
the final value of the property.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
hw/core/machine.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 2f881d6d75..035a1fc631 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -432,14 +432,6 @@ static void machine_set_memory_encryption(Object *obj, const char *value,
g_free(ms->memory_encryption);
ms->memory_encryption = g_strdup(value);
-
- /*
- * With memory encryption, the host can't see the real contents of RAM,
- * so there's no point in it trying to merge areas.
- */
- if (value) {
- machine_set_mem_merge(obj, false, errp);
- }
}
static bool machine_get_nvdimm(Object *obj, Error **errp)
@@ -1131,6 +1123,15 @@ void machine_run_board_init(MachineState *machine)
}
}
+ if (machine->memory_encryption) {
+ /*
+ * With host trust limitation, the host can't see the real
+ * contents of RAM, so there's no point in it trying to merge
+ * areas.
+ */
+ machine_set_mem_merge(OBJECT(machine), false, &error_abort);
+ }
+
machine_class->init(machine);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 04/10] host trust limitation: Rework the "memory-encryption" property
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Richard Henderson
Currently the "memory-encryption" property is only looked at once we get to
kvm_init(). Although protection of guest memory from the hypervisor isn't
something that could really ever work with TCG, it's not conceptually tied
to the KVM accelerator.
In addition, the way the string property is resolved to an object is
almost identical to how a QOM link property is handled.
So, create a new "host-trust-limitation" link property which sets this QOM
interface link directly in the machine. For compatibility we keep the
"memory-encryption" property, but now implemented in terms of the new
property.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 23 +++++++----------------
hw/core/machine.c | 41 ++++++++++++++++++++++++++++++++++++-----
include/hw/boards.h | 2 +-
3 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index d7d95eacc7..e2d8f47f93 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2186,25 +2186,16 @@ static int kvm_init(MachineState *ms)
* if memory encryption object is specified then initialize the memory
* encryption context.
*/
- if (ms->memory_encryption) {
- Object *obj = object_resolve_path_component(object_get_objects_root(),
- ms->memory_encryption);
-
- if (object_dynamic_cast(obj, TYPE_HOST_TRUST_LIMITATION)) {
- HostTrustLimitation *htl = HOST_TRUST_LIMITATION(obj);
- HostTrustLimitationClass *htlc
- = HOST_TRUST_LIMITATION_GET_CLASS(htl);
-
- ret = htlc->kvm_init(htl);
- if (ret < 0) {
- goto err;
- }
+ if (ms->htl) {
+ HostTrustLimitationClass *htlc =
+ HOST_TRUST_LIMITATION_GET_CLASS(ms->htl);
- kvm_state->htl = htl;
- } else {
- ret = -1;
+ ret = htlc->kvm_init(ms->htl);
+ if (ret < 0) {
goto err;
}
+
+ kvm_state->htl = ms->htl;
}
ret = kvm_arch_init(ms, s);
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 035a1fc631..b599b0ba65 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -27,6 +27,7 @@
#include "hw/pci/pci.h"
#include "hw/mem/nvdimm.h"
#include "migration/vmstate.h"
+#include "exec/host-trust-limitation.h"
GlobalProperty hw_compat_5_0[] = {
{ "virtio-balloon-device", "page-poison", "false" },
@@ -422,16 +423,37 @@ static char *machine_get_memory_encryption(Object *obj, Error **errp)
{
MachineState *ms = MACHINE(obj);
- return g_strdup(ms->memory_encryption);
+ if (ms->htl) {
+ return g_strdup(object_get_canonical_path_component(OBJECT(ms->htl)));
+ }
+
+ return NULL;
}
static void machine_set_memory_encryption(Object *obj, const char *value,
Error **errp)
{
- MachineState *ms = MACHINE(obj);
+ Object *htl =
+ object_resolve_path_component(object_get_objects_root(), value);
+
+ if (!htl) {
+ error_setg(errp, "No such memory encryption object '%s'", value);
+ return;
+ }
- g_free(ms->memory_encryption);
- ms->memory_encryption = g_strdup(value);
+ object_property_set_link(obj, "host-trust-limitation", htl, errp);
+}
+
+static void machine_check_host_trust_limitation(const Object *obj,
+ const char *name,
+ Object *new_target,
+ Error **errp)
+{
+ /*
+ * So far the only constraint is that the target has the
+ * TYPE_HOST_TRUST_LIMITATION interface, and that's checked by the
+ * QOM core
+ */
}
static bool machine_get_nvdimm(Object *obj, Error **errp)
@@ -852,6 +874,15 @@ static void machine_class_init(ObjectClass *oc, void *data)
object_class_property_set_description(oc, "enforce-config-section",
"Set on to enforce configuration section migration");
+ object_class_property_add_link(oc, "host-trust-limitation",
+ TYPE_HOST_TRUST_LIMITATION,
+ offsetof(MachineState, htl),
+ machine_check_host_trust_limitation,
+ OBJ_PROP_LINK_STRONG);
+ object_class_property_set_description(oc, "host-trust-limitation",
+ "Set host trust limitation object to use");
+
+ /* For compatibility */
object_class_property_add_str(oc, "memory-encryption",
machine_get_memory_encryption, machine_set_memory_encryption);
object_class_property_set_description(oc, "memory-encryption",
@@ -1123,7 +1154,7 @@ void machine_run_board_init(MachineState *machine)
}
}
- if (machine->memory_encryption) {
+ if (machine->htl) {
/*
* With host trust limitation, the host can't see the real
* contents of RAM, so there's no point in it trying to merge
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 426ce5f625..c70fb8bd9f 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -278,7 +278,7 @@ struct MachineState {
bool suppress_vmdesc;
bool enforce_config_section;
bool enable_graphics;
- char *memory_encryption;
+ HostTrustLimitation *htl;
char *ram_memdev_id;
/*
* convenience alias to ram_memdev_id backend memory region
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 04/10] host trust limitation: Rework the "memory-encryption" property
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand,
Richard Henderson, mdroth, pasic, Christian Borntraeger,
qemu-s390x, qemu-ppc, Richard Henderson, David Gibson
Currently the "memory-encryption" property is only looked at once we get to
kvm_init(). Although protection of guest memory from the hypervisor isn't
something that could really ever work with TCG, it's not conceptually tied
to the KVM accelerator.
In addition, the way the string property is resolved to an object is
almost identical to how a QOM link property is handled.
So, create a new "host-trust-limitation" link property which sets this QOM
interface link directly in the machine. For compatibility we keep the
"memory-encryption" property, but now implemented in terms of the new
property.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 23 +++++++----------------
hw/core/machine.c | 41 ++++++++++++++++++++++++++++++++++++-----
include/hw/boards.h | 2 +-
3 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index d7d95eacc7..e2d8f47f93 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2186,25 +2186,16 @@ static int kvm_init(MachineState *ms)
* if memory encryption object is specified then initialize the memory
* encryption context.
*/
- if (ms->memory_encryption) {
- Object *obj = object_resolve_path_component(object_get_objects_root(),
- ms->memory_encryption);
-
- if (object_dynamic_cast(obj, TYPE_HOST_TRUST_LIMITATION)) {
- HostTrustLimitation *htl = HOST_TRUST_LIMITATION(obj);
- HostTrustLimitationClass *htlc
- = HOST_TRUST_LIMITATION_GET_CLASS(htl);
-
- ret = htlc->kvm_init(htl);
- if (ret < 0) {
- goto err;
- }
+ if (ms->htl) {
+ HostTrustLimitationClass *htlc =
+ HOST_TRUST_LIMITATION_GET_CLASS(ms->htl);
- kvm_state->htl = htl;
- } else {
- ret = -1;
+ ret = htlc->kvm_init(ms->htl);
+ if (ret < 0) {
goto err;
}
+
+ kvm_state->htl = ms->htl;
}
ret = kvm_arch_init(ms, s);
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 035a1fc631..b599b0ba65 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -27,6 +27,7 @@
#include "hw/pci/pci.h"
#include "hw/mem/nvdimm.h"
#include "migration/vmstate.h"
+#include "exec/host-trust-limitation.h"
GlobalProperty hw_compat_5_0[] = {
{ "virtio-balloon-device", "page-poison", "false" },
@@ -422,16 +423,37 @@ static char *machine_get_memory_encryption(Object *obj, Error **errp)
{
MachineState *ms = MACHINE(obj);
- return g_strdup(ms->memory_encryption);
+ if (ms->htl) {
+ return g_strdup(object_get_canonical_path_component(OBJECT(ms->htl)));
+ }
+
+ return NULL;
}
static void machine_set_memory_encryption(Object *obj, const char *value,
Error **errp)
{
- MachineState *ms = MACHINE(obj);
+ Object *htl =
+ object_resolve_path_component(object_get_objects_root(), value);
+
+ if (!htl) {
+ error_setg(errp, "No such memory encryption object '%s'", value);
+ return;
+ }
- g_free(ms->memory_encryption);
- ms->memory_encryption = g_strdup(value);
+ object_property_set_link(obj, "host-trust-limitation", htl, errp);
+}
+
+static void machine_check_host_trust_limitation(const Object *obj,
+ const char *name,
+ Object *new_target,
+ Error **errp)
+{
+ /*
+ * So far the only constraint is that the target has the
+ * TYPE_HOST_TRUST_LIMITATION interface, and that's checked by the
+ * QOM core
+ */
}
static bool machine_get_nvdimm(Object *obj, Error **errp)
@@ -852,6 +874,15 @@ static void machine_class_init(ObjectClass *oc, void *data)
object_class_property_set_description(oc, "enforce-config-section",
"Set on to enforce configuration section migration");
+ object_class_property_add_link(oc, "host-trust-limitation",
+ TYPE_HOST_TRUST_LIMITATION,
+ offsetof(MachineState, htl),
+ machine_check_host_trust_limitation,
+ OBJ_PROP_LINK_STRONG);
+ object_class_property_set_description(oc, "host-trust-limitation",
+ "Set host trust limitation object to use");
+
+ /* For compatibility */
object_class_property_add_str(oc, "memory-encryption",
machine_get_memory_encryption, machine_set_memory_encryption);
object_class_property_set_description(oc, "memory-encryption",
@@ -1123,7 +1154,7 @@ void machine_run_board_init(MachineState *machine)
}
}
- if (machine->memory_encryption) {
+ if (machine->htl) {
/*
* With host trust limitation, the host can't see the real
* contents of RAM, so there's no point in it trying to merge
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 426ce5f625..c70fb8bd9f 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -278,7 +278,7 @@ struct MachineState {
bool suppress_vmdesc;
bool enforce_config_section;
bool enable_graphics;
- char *memory_encryption;
+ HostTrustLimitation *htl;
char *ram_memdev_id;
/*
* convenience alias to ram_memdev_id backend memory region
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 05/10] host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Richard Henderson
The kvm_memcrypt_enabled() and kvm_memcrypt_encrypt_data() helper functions
don't conceptually have any connection to KVM (although it's not possible
in practice to use them without it).
They also rely on looking at the global KVMState. But the same information
is available from the machine, and the only existing callers have natural
access to the machine state.
Therefore, move and rename them to helpers in host-trust-limitation.h,
taking an explicit machine parameter.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 27 ---------------------
accel/stubs/kvm-stub.c | 10 --------
hw/i386/pc_sysfw.c | 6 +++--
include/exec/host-trust-limitation.h | 36 ++++++++++++++++++++++++++++
include/sysemu/kvm.h | 17 -------------
5 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index e2d8f47f93..4b6402c12c 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -117,9 +117,6 @@ struct KVMState
KVMMemoryListener memory_listener;
QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
- /* host trust limitation (e.g. by guest memory encryption) */
- HostTrustLimitation *htl;
-
/* For "info mtree -f" to tell if an MR is registered in KVM */
int nr_as;
struct KVMAs {
@@ -218,28 +215,6 @@ int kvm_get_max_memslots(void)
return s->nr_slots;
}
-bool kvm_memcrypt_enabled(void)
-{
- if (kvm_state && kvm_state->htl) {
- return true;
- }
-
- return false;
-}
-
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
-{
- HostTrustLimitation *htl = kvm_state->htl;
-
- if (htl) {
- HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_GET_CLASS(htl);
-
- return htlc->encrypt_data(htl, ptr, len);
- }
-
- return 1;
-}
-
/* Called with KVMMemoryListener.slots_lock held */
static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
{
@@ -2194,8 +2169,6 @@ static int kvm_init(MachineState *ms)
if (ret < 0) {
goto err;
}
-
- kvm_state->htl = ms->htl;
}
ret = kvm_arch_init(ms, s);
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 82f118d2df..78b3eef117 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -104,16 +104,6 @@ int kvm_on_sigbus(int code, void *addr)
return 1;
}
-bool kvm_memcrypt_enabled(void)
-{
- return false;
-}
-
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
-{
- return 1;
-}
-
#ifndef CONFIG_USER_ONLY
int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
{
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b6c0822fe3..e8d3b795a1 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -38,6 +38,7 @@
#include "sysemu/sysemu.h"
#include "hw/block/flash.h"
#include "sysemu/kvm.h"
+#include "exec/host-trust-limitation.h"
/*
* We don't have a theoretically justifiable exact lower bound on the base
@@ -201,10 +202,11 @@ static void pc_system_flash_map(PCMachineState *pcms,
pc_isa_bios_init(rom_memory, flash_mem, size);
/* Encrypt the pflash boot ROM */
- if (kvm_memcrypt_enabled()) {
+ if (host_trust_limitation_enabled(MACHINE(pcms))) {
flash_ptr = memory_region_get_ram_ptr(flash_mem);
flash_size = memory_region_size(flash_mem);
- ret = kvm_memcrypt_encrypt_data(flash_ptr, flash_size);
+ ret = host_trust_limitation_encrypt(MACHINE(pcms),
+ flash_ptr, flash_size);
if (ret) {
error_report("failed to encrypt pflash rom");
exit(1);
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
index a19f12ae14..fc30ea3f78 100644
--- a/include/exec/host-trust-limitation.h
+++ b/include/exec/host-trust-limitation.h
@@ -14,6 +14,7 @@
#define QEMU_HOST_TRUST_LIMITATION_H
#include "qom/object.h"
+#include "hw/boards.h"
#define TYPE_HOST_TRUST_LIMITATION "host-trust-limitation"
#define HOST_TRUST_LIMITATION(obj) \
@@ -33,4 +34,39 @@ typedef struct HostTrustLimitationClass {
int (*encrypt_data)(HostTrustLimitation *, uint8_t *, uint64_t);
} HostTrustLimitationClass;
+/**
+ * host_trust_limitation_enabled - return whether guest memory is protected
+ * from hypervisor access (with memory
+ * encryption or otherwise)
+ * Returns: true guest memory is not directly accessible to qemu
+ * false guest memory is directly accessible to qemu
+ */
+static inline bool host_trust_limitation_enabled(MachineState *machine)
+{
+ return !!machine->htl;
+}
+
+/**
+ * host_trust_limitation_encrypt: encrypt the memory range to make
+ * it guest accessible
+ *
+ * Return: 1 failed to encrypt the range
+ * 0 succesfully encrypted memory region
+ */
+static inline int host_trust_limitation_encrypt(MachineState *machine,
+ uint8_t *ptr, uint64_t len)
+{
+ HostTrustLimitation *htl = machine->htl;
+
+ if (htl) {
+ HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_GET_CLASS(htl);
+
+ if (htlc->encrypt_data) {
+ return htlc->encrypt_data(htl, ptr, len);
+ }
+ }
+
+ return 1;
+}
+
#endif /* QEMU_HOST_TRUST_LIMITATION_H */
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index b4174d941c..c7b9739609 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -231,23 +231,6 @@ int kvm_destroy_vcpu(CPUState *cpu);
*/
bool kvm_arm_supports_user_irq(void);
-/**
- * kvm_memcrypt_enabled - return boolean indicating whether memory encryption
- * is enabled
- * Returns: 1 memory encryption is enabled
- * 0 memory encryption is disabled
- */
-bool kvm_memcrypt_enabled(void);
-
-/**
- * kvm_memcrypt_encrypt_data: encrypt the memory range
- *
- * Return: 1 failed to encrypt the range
- * 0 succesfully encrypted memory region
- */
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len);
-
-
#ifdef NEED_CPU_H
#include "cpu.h"
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 05/10] host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand,
Richard Henderson, mdroth, pasic, Christian Borntraeger,
qemu-s390x, qemu-ppc, Richard Henderson, David Gibson
The kvm_memcrypt_enabled() and kvm_memcrypt_encrypt_data() helper functions
don't conceptually have any connection to KVM (although it's not possible
in practice to use them without it).
They also rely on looking at the global KVMState. But the same information
is available from the machine, and the only existing callers have natural
access to the machine state.
Therefore, move and rename them to helpers in host-trust-limitation.h,
taking an explicit machine parameter.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 27 ---------------------
accel/stubs/kvm-stub.c | 10 --------
hw/i386/pc_sysfw.c | 6 +++--
include/exec/host-trust-limitation.h | 36 ++++++++++++++++++++++++++++
include/sysemu/kvm.h | 17 -------------
5 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index e2d8f47f93..4b6402c12c 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -117,9 +117,6 @@ struct KVMState
KVMMemoryListener memory_listener;
QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
- /* host trust limitation (e.g. by guest memory encryption) */
- HostTrustLimitation *htl;
-
/* For "info mtree -f" to tell if an MR is registered in KVM */
int nr_as;
struct KVMAs {
@@ -218,28 +215,6 @@ int kvm_get_max_memslots(void)
return s->nr_slots;
}
-bool kvm_memcrypt_enabled(void)
-{
- if (kvm_state && kvm_state->htl) {
- return true;
- }
-
- return false;
-}
-
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
-{
- HostTrustLimitation *htl = kvm_state->htl;
-
- if (htl) {
- HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_GET_CLASS(htl);
-
- return htlc->encrypt_data(htl, ptr, len);
- }
-
- return 1;
-}
-
/* Called with KVMMemoryListener.slots_lock held */
static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
{
@@ -2194,8 +2169,6 @@ static int kvm_init(MachineState *ms)
if (ret < 0) {
goto err;
}
-
- kvm_state->htl = ms->htl;
}
ret = kvm_arch_init(ms, s);
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 82f118d2df..78b3eef117 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -104,16 +104,6 @@ int kvm_on_sigbus(int code, void *addr)
return 1;
}
-bool kvm_memcrypt_enabled(void)
-{
- return false;
-}
-
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
-{
- return 1;
-}
-
#ifndef CONFIG_USER_ONLY
int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
{
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b6c0822fe3..e8d3b795a1 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -38,6 +38,7 @@
#include "sysemu/sysemu.h"
#include "hw/block/flash.h"
#include "sysemu/kvm.h"
+#include "exec/host-trust-limitation.h"
/*
* We don't have a theoretically justifiable exact lower bound on the base
@@ -201,10 +202,11 @@ static void pc_system_flash_map(PCMachineState *pcms,
pc_isa_bios_init(rom_memory, flash_mem, size);
/* Encrypt the pflash boot ROM */
- if (kvm_memcrypt_enabled()) {
+ if (host_trust_limitation_enabled(MACHINE(pcms))) {
flash_ptr = memory_region_get_ram_ptr(flash_mem);
flash_size = memory_region_size(flash_mem);
- ret = kvm_memcrypt_encrypt_data(flash_ptr, flash_size);
+ ret = host_trust_limitation_encrypt(MACHINE(pcms),
+ flash_ptr, flash_size);
if (ret) {
error_report("failed to encrypt pflash rom");
exit(1);
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
index a19f12ae14..fc30ea3f78 100644
--- a/include/exec/host-trust-limitation.h
+++ b/include/exec/host-trust-limitation.h
@@ -14,6 +14,7 @@
#define QEMU_HOST_TRUST_LIMITATION_H
#include "qom/object.h"
+#include "hw/boards.h"
#define TYPE_HOST_TRUST_LIMITATION "host-trust-limitation"
#define HOST_TRUST_LIMITATION(obj) \
@@ -33,4 +34,39 @@ typedef struct HostTrustLimitationClass {
int (*encrypt_data)(HostTrustLimitation *, uint8_t *, uint64_t);
} HostTrustLimitationClass;
+/**
+ * host_trust_limitation_enabled - return whether guest memory is protected
+ * from hypervisor access (with memory
+ * encryption or otherwise)
+ * Returns: true guest memory is not directly accessible to qemu
+ * false guest memory is directly accessible to qemu
+ */
+static inline bool host_trust_limitation_enabled(MachineState *machine)
+{
+ return !!machine->htl;
+}
+
+/**
+ * host_trust_limitation_encrypt: encrypt the memory range to make
+ * it guest accessible
+ *
+ * Return: 1 failed to encrypt the range
+ * 0 succesfully encrypted memory region
+ */
+static inline int host_trust_limitation_encrypt(MachineState *machine,
+ uint8_t *ptr, uint64_t len)
+{
+ HostTrustLimitation *htl = machine->htl;
+
+ if (htl) {
+ HostTrustLimitationClass *htlc = HOST_TRUST_LIMITATION_GET_CLASS(htl);
+
+ if (htlc->encrypt_data) {
+ return htlc->encrypt_data(htl, ptr, len);
+ }
+ }
+
+ return 1;
+}
+
#endif /* QEMU_HOST_TRUST_LIMITATION_H */
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index b4174d941c..c7b9739609 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -231,23 +231,6 @@ int kvm_destroy_vcpu(CPUState *cpu);
*/
bool kvm_arm_supports_user_irq(void);
-/**
- * kvm_memcrypt_enabled - return boolean indicating whether memory encryption
- * is enabled
- * Returns: 1 memory encryption is enabled
- * 0 memory encryption is disabled
- */
-bool kvm_memcrypt_enabled(void);
-
-/**
- * kvm_memcrypt_encrypt_data: encrypt the memory range
- *
- * Return: 1 failed to encrypt the range
- * 0 succesfully encrypted memory region
- */
-int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len);
-
-
#ifdef NEED_CPU_H
#include "cpu.h"
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 06/10] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Philippe Mathieu-Daudé,
Richard Henderson
This allows failures to be reported richly and idiomatically.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 4 +++-
include/exec/host-trust-limitation.h | 2 +-
target/i386/sev.c | 31 ++++++++++++++--------------
3 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 4b6402c12c..3f98c6be7c 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2164,9 +2164,11 @@ static int kvm_init(MachineState *ms)
if (ms->htl) {
HostTrustLimitationClass *htlc =
HOST_TRUST_LIMITATION_GET_CLASS(ms->htl);
+ Error *local_err = NULL;
- ret = htlc->kvm_init(ms->htl);
+ ret = htlc->kvm_init(ms->htl, &local_err);
if (ret < 0) {
+ error_report_err(local_err);
goto err;
}
}
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
index fc30ea3f78..d93b537280 100644
--- a/include/exec/host-trust-limitation.h
+++ b/include/exec/host-trust-limitation.h
@@ -30,7 +30,7 @@
typedef struct HostTrustLimitationClass {
InterfaceClass parent;
- int (*kvm_init)(HostTrustLimitation *);
+ int (*kvm_init)(HostTrustLimitation *, Error **);
int (*encrypt_data)(HostTrustLimitation *, uint8_t *, uint64_t);
} HostTrustLimitationClass;
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 8e3c9dcc2c..0d06976da5 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -626,7 +626,7 @@ sev_vm_state_change(void *opaque, int running, RunState state)
}
}
-static int sev_kvm_init(HostTrustLimitation *htl)
+static int sev_kvm_init(HostTrustLimitation *htl, Error **errp)
{
SevGuestState *sev = SEV_GUEST(htl);
char *devname;
@@ -648,14 +648,14 @@ static int sev_kvm_init(HostTrustLimitation *htl)
host_cbitpos = ebx & 0x3f;
if (host_cbitpos != sev->cbitpos) {
- error_report("%s: cbitpos check failed, host '%d' requested '%d'",
- __func__, host_cbitpos, sev->cbitpos);
+ error_setg(errp, "%s: cbitpos check failed, host '%d' requested '%d'",
+ __func__, host_cbitpos, sev->cbitpos);
goto err;
}
if (sev->reduced_phys_bits < 1) {
- error_report("%s: reduced_phys_bits check failed, it should be >=1,"
- " requested '%d'", __func__, sev->reduced_phys_bits);
+ error_setg(errp, "%s: reduced_phys_bits check failed, it should be >=1,"
+ " requested '%d'", __func__, sev->reduced_phys_bits);
goto err;
}
@@ -664,20 +664,19 @@ static int sev_kvm_init(HostTrustLimitation *htl)
devname = object_property_get_str(OBJECT(sev), "sev-device", NULL);
sev->sev_fd = open(devname, O_RDWR);
if (sev->sev_fd < 0) {
- error_report("%s: Failed to open %s '%s'", __func__,
- devname, strerror(errno));
- }
- g_free(devname);
- if (sev->sev_fd < 0) {
+ error_setg(errp, "%s: Failed to open %s '%s'", __func__,
+ devname, strerror(errno));
+ g_free(devname);
goto err;
}
+ g_free(devname);
ret = sev_platform_ioctl(sev->sev_fd, SEV_PLATFORM_STATUS, &status,
&fw_error);
if (ret) {
- error_report("%s: failed to get platform status ret=%d "
- "fw_error='%d: %s'", __func__, ret, fw_error,
- fw_error_to_str(fw_error));
+ error_setg(errp, "%s: failed to get platform status ret=%d "
+ "fw_error='%d: %s'", __func__, ret, fw_error,
+ fw_error_to_str(fw_error));
goto err;
}
sev->build_id = status.build;
@@ -687,14 +686,14 @@ static int sev_kvm_init(HostTrustLimitation *htl)
trace_kvm_sev_init();
ret = sev_ioctl(sev->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
if (ret) {
- error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
- __func__, ret, fw_error, fw_error_to_str(fw_error));
+ error_setg(errp, "%s: failed to initialize ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
goto err;
}
ret = sev_launch_start(sev);
if (ret) {
- error_report("%s: failed to create encryption context", __func__);
+ error_setg(errp, "%s: failed to create encryption context", __func__);
goto err;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 06/10] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand,
Richard Henderson, mdroth, pasic, Christian Borntraeger,
qemu-s390x, qemu-ppc, Richard Henderson,
Philippe Mathieu-Daudé,
David Gibson
This allows failures to be reported richly and idiomatically.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
---
accel/kvm/kvm-all.c | 4 +++-
include/exec/host-trust-limitation.h | 2 +-
target/i386/sev.c | 31 ++++++++++++++--------------
3 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 4b6402c12c..3f98c6be7c 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2164,9 +2164,11 @@ static int kvm_init(MachineState *ms)
if (ms->htl) {
HostTrustLimitationClass *htlc =
HOST_TRUST_LIMITATION_GET_CLASS(ms->htl);
+ Error *local_err = NULL;
- ret = htlc->kvm_init(ms->htl);
+ ret = htlc->kvm_init(ms->htl, &local_err);
if (ret < 0) {
+ error_report_err(local_err);
goto err;
}
}
diff --git a/include/exec/host-trust-limitation.h b/include/exec/host-trust-limitation.h
index fc30ea3f78..d93b537280 100644
--- a/include/exec/host-trust-limitation.h
+++ b/include/exec/host-trust-limitation.h
@@ -30,7 +30,7 @@
typedef struct HostTrustLimitationClass {
InterfaceClass parent;
- int (*kvm_init)(HostTrustLimitation *);
+ int (*kvm_init)(HostTrustLimitation *, Error **);
int (*encrypt_data)(HostTrustLimitation *, uint8_t *, uint64_t);
} HostTrustLimitationClass;
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 8e3c9dcc2c..0d06976da5 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -626,7 +626,7 @@ sev_vm_state_change(void *opaque, int running, RunState state)
}
}
-static int sev_kvm_init(HostTrustLimitation *htl)
+static int sev_kvm_init(HostTrustLimitation *htl, Error **errp)
{
SevGuestState *sev = SEV_GUEST(htl);
char *devname;
@@ -648,14 +648,14 @@ static int sev_kvm_init(HostTrustLimitation *htl)
host_cbitpos = ebx & 0x3f;
if (host_cbitpos != sev->cbitpos) {
- error_report("%s: cbitpos check failed, host '%d' requested '%d'",
- __func__, host_cbitpos, sev->cbitpos);
+ error_setg(errp, "%s: cbitpos check failed, host '%d' requested '%d'",
+ __func__, host_cbitpos, sev->cbitpos);
goto err;
}
if (sev->reduced_phys_bits < 1) {
- error_report("%s: reduced_phys_bits check failed, it should be >=1,"
- " requested '%d'", __func__, sev->reduced_phys_bits);
+ error_setg(errp, "%s: reduced_phys_bits check failed, it should be >=1,"
+ " requested '%d'", __func__, sev->reduced_phys_bits);
goto err;
}
@@ -664,20 +664,19 @@ static int sev_kvm_init(HostTrustLimitation *htl)
devname = object_property_get_str(OBJECT(sev), "sev-device", NULL);
sev->sev_fd = open(devname, O_RDWR);
if (sev->sev_fd < 0) {
- error_report("%s: Failed to open %s '%s'", __func__,
- devname, strerror(errno));
- }
- g_free(devname);
- if (sev->sev_fd < 0) {
+ error_setg(errp, "%s: Failed to open %s '%s'", __func__,
+ devname, strerror(errno));
+ g_free(devname);
goto err;
}
+ g_free(devname);
ret = sev_platform_ioctl(sev->sev_fd, SEV_PLATFORM_STATUS, &status,
&fw_error);
if (ret) {
- error_report("%s: failed to get platform status ret=%d "
- "fw_error='%d: %s'", __func__, ret, fw_error,
- fw_error_to_str(fw_error));
+ error_setg(errp, "%s: failed to get platform status ret=%d "
+ "fw_error='%d: %s'", __func__, ret, fw_error,
+ fw_error_to_str(fw_error));
goto err;
}
sev->build_id = status.build;
@@ -687,14 +686,14 @@ static int sev_kvm_init(HostTrustLimitation *htl)
trace_kvm_sev_init();
ret = sev_ioctl(sev->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
if (ret) {
- error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
- __func__, ret, fw_error, fw_error_to_str(fw_error));
+ error_setg(errp, "%s: failed to initialize ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
goto err;
}
ret = sev_launch_start(sev);
if (ret) {
- error_report("%s: failed to create encryption context", __func__);
+ error_setg(errp, "%s: failed to create encryption context", __func__);
goto err;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 07/10] spapr: Add PEF based host trust limitation
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Ram Pai
Some upcoming POWER machines have a system called PEF (Protected
Execution Facility) which uses a small ultravisor to allow guests to
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 having the right hardware and firmware, we don't
enable this by default. In order to run a secure guest you need to
create a "pef-guest" object and set the host-trust-limitation 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. Qemu has no directly way of knowing if the guest is in
secure mode, and certainly can't know until well after machine
creation time.
To start a PEF-capable guest, use the command line options:
-object pef-guest,id=pef0 -machine host-trust-limitation=pef0
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Ram Pai <linuxram@us.ibm.com>
---
target/ppc/Makefile.objs | 2 +-
target/ppc/pef.c | 83 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 84 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..53a6af0347
--- /dev/null
+++ b/target/ppc/pef.c
@@ -0,0 +1,83 @@
+/*
+ * PEF (Protected Execution Facility) 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"
+
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "sysemu/kvm.h"
+#include "migration/blocker.h"
+#include "exec/host-trust-limitation.h"
+
+#define TYPE_PEF_GUEST "pef-guest"
+#define PEF_GUEST(obj) \
+ OBJECT_CHECK(PefGuestState, (obj), TYPE_PEF_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 ...,host-trust-limitation=pef0
+ */
+struct PefGuestState {
+ Object parent_obj;
+};
+
+static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
+{
+ 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;
+}
+
+static void pef_guest_class_init(ObjectClass *oc, void *data)
+{
+ HostTrustLimitationClass *gmpc = HOST_TRUST_LIMITATION_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_HOST_TRUST_LIMITATION },
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
+static void
+pef_register_types(void)
+{
+ type_register_static(&pef_guest_info);
+}
+
+type_init(pef_register_types);
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 07/10] spapr: Add PEF based host trust limitation
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, Ram Pai,
mdroth, pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson, David Gibson
Some upcoming POWER machines have a system called PEF (Protected
Execution Facility) which uses a small ultravisor to allow guests to
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 having the right hardware and firmware, we don't
enable this by default. In order to run a secure guest you need to
create a "pef-guest" object and set the host-trust-limitation 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. Qemu has no directly way of knowing if the guest is in
secure mode, and certainly can't know until well after machine
creation time.
To start a PEF-capable guest, use the command line options:
-object pef-guest,id=pef0 -machine host-trust-limitation=pef0
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Ram Pai <linuxram@us.ibm.com>
---
target/ppc/Makefile.objs | 2 +-
target/ppc/pef.c | 83 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 84 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..53a6af0347
--- /dev/null
+++ b/target/ppc/pef.c
@@ -0,0 +1,83 @@
+/*
+ * PEF (Protected Execution Facility) 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"
+
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "sysemu/kvm.h"
+#include "migration/blocker.h"
+#include "exec/host-trust-limitation.h"
+
+#define TYPE_PEF_GUEST "pef-guest"
+#define PEF_GUEST(obj) \
+ OBJECT_CHECK(PefGuestState, (obj), TYPE_PEF_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 ...,host-trust-limitation=pef0
+ */
+struct PefGuestState {
+ Object parent_obj;
+};
+
+static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
+{
+ 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;
+}
+
+static void pef_guest_class_init(ObjectClass *oc, void *data)
+{
+ HostTrustLimitationClass *gmpc = HOST_TRUST_LIMITATION_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_HOST_TRUST_LIMITATION },
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
+static void
+pef_register_types(void)
+{
+ type_register_static(&pef_guest_info);
+}
+
+type_init(pef_register_types);
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 08/10] spapr: PEF: block migration
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck
We haven't yet implemented the fairly involved handshaking that will be
needed to migrate PEF protected guests. For now, just use a migration
blocker so we get a meaningful error if someone attempts this (this is the
same approach used by AMD SEV).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
target/ppc/pef.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/target/ppc/pef.c b/target/ppc/pef.c
index 53a6af0347..6a50efd580 100644
--- a/target/ppc/pef.c
+++ b/target/ppc/pef.c
@@ -36,6 +36,8 @@ struct PefGuestState {
Object parent_obj;
};
+static Error *pef_mig_blocker;
+
static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
{
if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURE_GUEST)) {
@@ -52,6 +54,10 @@ static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
}
}
+ /* add migration blocker */
+ error_setg(&pef_mig_blocker, "PEF: Migration is not implemented");
+ migrate_add_blocker(pef_mig_blocker, &error_abort);
+
return 0;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 08/10] spapr: PEF: block migration
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson, David Gibson
We haven't yet implemented the fairly involved handshaking that will be
needed to migrate PEF protected guests. For now, just use a migration
blocker so we get a meaningful error if someone attempts this (this is the
same approach used by AMD SEV).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
target/ppc/pef.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/target/ppc/pef.c b/target/ppc/pef.c
index 53a6af0347..6a50efd580 100644
--- a/target/ppc/pef.c
+++ b/target/ppc/pef.c
@@ -36,6 +36,8 @@ struct PefGuestState {
Object parent_obj;
};
+static Error *pef_mig_blocker;
+
static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
{
if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURE_GUEST)) {
@@ -52,6 +54,10 @@ static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
}
}
+ /* add migration blocker */
+ error_setg(&pef_mig_blocker, "PEF: Migration is not implemented");
+ migrate_add_blocker(pef_mig_blocker, &error_abort);
+
return 0;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck
The default behaviour for virtio devices is not to use the platforms normal
DMA paths, but instead to use the fact that it's running in a hypervisor
to directly access guest memory. That doesn't work if the guest's memory
is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
So, if a host trust limitation mechanism is enabled, then apply the
iommu_platform=on option so it will go through normal DMA mechanisms.
Those will presumably have some way of marking memory as shared with the
hypervisor or hardware so that DMA will work.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
hw/core/machine.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index b599b0ba65..2a723bf07b 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -28,6 +28,8 @@
#include "hw/mem/nvdimm.h"
#include "migration/vmstate.h"
#include "exec/host-trust-limitation.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-pci.h"
GlobalProperty hw_compat_5_0[] = {
{ "virtio-balloon-device", "page-poison", "false" },
@@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
* areas.
*/
machine_set_mem_merge(OBJECT(machine), false, &error_abort);
+
+ /*
+ * Virtio devices can't count on directly accessing guest
+ * memory, so they need iommu_platform=on to use normal DMA
+ * mechanisms. That requires disabling legacy virtio support
+ * for virtio pci devices
+ */
+ object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
+ object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
}
machine_class->init(machine);
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson, David Gibson
The default behaviour for virtio devices is not to use the platforms normal
DMA paths, but instead to use the fact that it's running in a hypervisor
to directly access guest memory. That doesn't work if the guest's memory
is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
So, if a host trust limitation mechanism is enabled, then apply the
iommu_platform=on option so it will go through normal DMA mechanisms.
Those will presumably have some way of marking memory as shared with the
hypervisor or hardware so that DMA will work.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
hw/core/machine.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index b599b0ba65..2a723bf07b 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -28,6 +28,8 @@
#include "hw/mem/nvdimm.h"
#include "migration/vmstate.h"
#include "exec/host-trust-limitation.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-pci.h"
GlobalProperty hw_compat_5_0[] = {
{ "virtio-balloon-device", "page-poison", "false" },
@@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
* areas.
*/
machine_set_mem_merge(OBJECT(machine), false, &error_abort);
+
+ /*
+ * Virtio devices can't count on directly accessing guest
+ * memory, so they need iommu_platform=on to use normal DMA
+ * mechanisms. That requires disabling legacy virtio support
+ * for virtio pci devices
+ */
+ object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
+ object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
}
machine_class->init(machine);
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-07-24 2:57 ` David Gibson
@ 2020-07-24 2:57 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Gibson, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck
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(+)
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);
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-07-24 2:57 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-07-24 2:57 UTC (permalink / raw)
To: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson, David Gibson
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(+)
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);
--
2.26.2
^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 08/10] spapr: PEF: block migration
2020-07-24 2:57 ` David Gibson
@ 2020-07-27 15:01 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 66+ messages in thread
From: Dr. David Alan Gilbert @ 2020-07-27 15:01 UTC (permalink / raw)
To: David Gibson
Cc: frankja, pair, qemu-devel, pbonzini, brijesh.singh, ehabkost,
marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm, pasic,
qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck
* David Gibson (david@gibson.dropbear.id.au) wrote:
> We haven't yet implemented the fairly involved handshaking that will be
> needed to migrate PEF protected guests. For now, just use a migration
> blocker so we get a meaningful error if someone attempts this (this is the
> same approach used by AMD SEV).
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> target/ppc/pef.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/target/ppc/pef.c b/target/ppc/pef.c
> index 53a6af0347..6a50efd580 100644
> --- a/target/ppc/pef.c
> +++ b/target/ppc/pef.c
> @@ -36,6 +36,8 @@ struct PefGuestState {
> Object parent_obj;
> };
>
> +static Error *pef_mig_blocker;
> +
> static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
> {
> if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURE_GUEST)) {
> @@ -52,6 +54,10 @@ static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
> }
> }
>
> + /* add migration blocker */
> + error_setg(&pef_mig_blocker, "PEF: Migration is not implemented");
> + migrate_add_blocker(pef_mig_blocker, &error_abort);
> +
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
You might want that to be &error_fatal rather than error_abort; I think
someone could trigger it just by using --only-migratable together with
your pef device?
(I previously asked whether this would trigger with -cpu host; I hadn't
noticed this was based on the device rather than the CPU flag that said
whether you had the feature)
Dave
> return 0;
> }
>
> --
> 2.26.2
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 08/10] spapr: PEF: block migration
@ 2020-07-27 15:01 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 66+ messages in thread
From: Dr. David Alan Gilbert @ 2020-07-27 15:01 UTC (permalink / raw)
To: David Gibson
Cc: pair, Cornelia Huck, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, David Hildenbrand, qemu-devel, mdroth, pasic,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, ehabkost
* David Gibson (david@gibson.dropbear.id.au) wrote:
> We haven't yet implemented the fairly involved handshaking that will be
> needed to migrate PEF protected guests. For now, just use a migration
> blocker so we get a meaningful error if someone attempts this (this is the
> same approach used by AMD SEV).
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> target/ppc/pef.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/target/ppc/pef.c b/target/ppc/pef.c
> index 53a6af0347..6a50efd580 100644
> --- a/target/ppc/pef.c
> +++ b/target/ppc/pef.c
> @@ -36,6 +36,8 @@ struct PefGuestState {
> Object parent_obj;
> };
>
> +static Error *pef_mig_blocker;
> +
> static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
> {
> if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURE_GUEST)) {
> @@ -52,6 +54,10 @@ static int pef_kvm_init(HostTrustLimitation *gmpo, Error **errp)
> }
> }
>
> + /* add migration blocker */
> + error_setg(&pef_mig_blocker, "PEF: Migration is not implemented");
> + migrate_add_blocker(pef_mig_blocker, &error_abort);
> +
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
You might want that to be &error_fatal rather than error_abort; I think
someone could trigger it just by using --only-migratable together with
your pef device?
(I previously asked whether this would trigger with -cpu host; I hadn't
noticed this was based on the device rather than the CPU flag that said
whether you had the feature)
Dave
> return 0;
> }
>
> --
> 2.26.2
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
2020-07-24 2:57 ` David Gibson
@ 2020-07-27 15:05 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 66+ messages in thread
From: Dr. David Alan Gilbert @ 2020-07-27 15:05 UTC (permalink / raw)
To: David Gibson
Cc: frankja, pair, qemu-devel, pbonzini, brijesh.singh, ehabkost,
marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm, pasic,
qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck
* David Gibson (david@gibson.dropbear.id.au) wrote:
> The default behaviour for virtio devices is not to use the platforms normal
> DMA paths, but instead to use the fact that it's running in a hypervisor
> to directly access guest memory. That doesn't work if the guest's memory
> is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
>
> So, if a host trust limitation mechanism is enabled, then apply the
> iommu_platform=on option so it will go through normal DMA mechanisms.
> Those will presumably have some way of marking memory as shared with the
> hypervisor or hardware so that DMA will work.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Good, it's just too easy to forget them at the moment and get hopelessly
confused.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
> hw/core/machine.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index b599b0ba65..2a723bf07b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -28,6 +28,8 @@
> #include "hw/mem/nvdimm.h"
> #include "migration/vmstate.h"
> #include "exec/host-trust-limitation.h"
> +#include "hw/virtio/virtio.h"
> +#include "hw/virtio/virtio-pci.h"
>
> GlobalProperty hw_compat_5_0[] = {
> { "virtio-balloon-device", "page-poison", "false" },
> @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> * areas.
> */
> machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> +
> + /*
> + * Virtio devices can't count on directly accessing guest
> + * memory, so they need iommu_platform=on to use normal DMA
> + * mechanisms. That requires disabling legacy virtio support
> + * for virtio pci devices
> + */
> + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
> + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> }
>
> machine_class->init(machine);
> --
> 2.26.2
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
@ 2020-07-27 15:05 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 66+ messages in thread
From: Dr. David Alan Gilbert @ 2020-07-27 15:05 UTC (permalink / raw)
To: David Gibson
Cc: pair, Cornelia Huck, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, David Hildenbrand, qemu-devel, mdroth, pasic,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, ehabkost
* David Gibson (david@gibson.dropbear.id.au) wrote:
> The default behaviour for virtio devices is not to use the platforms normal
> DMA paths, but instead to use the fact that it's running in a hypervisor
> to directly access guest memory. That doesn't work if the guest's memory
> is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
>
> So, if a host trust limitation mechanism is enabled, then apply the
> iommu_platform=on option so it will go through normal DMA mechanisms.
> Those will presumably have some way of marking memory as shared with the
> hypervisor or hardware so that DMA will work.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Good, it's just too easy to forget them at the moment and get hopelessly
confused.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
> hw/core/machine.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index b599b0ba65..2a723bf07b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -28,6 +28,8 @@
> #include "hw/mem/nvdimm.h"
> #include "migration/vmstate.h"
> #include "exec/host-trust-limitation.h"
> +#include "hw/virtio/virtio.h"
> +#include "hw/virtio/virtio-pci.h"
>
> GlobalProperty hw_compat_5_0[] = {
> { "virtio-balloon-device", "page-poison", "false" },
> @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> * areas.
> */
> machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> +
> + /*
> + * Virtio devices can't count on directly accessing guest
> + * memory, so they need iommu_platform=on to use normal DMA
> + * mechanisms. That requires disabling legacy virtio support
> + * for virtio pci devices
> + */
> + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
> + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> }
>
> machine_class->init(machine);
> --
> 2.26.2
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-07-24 2:57 ` David Gibson
@ 2020-07-27 15:50 ` Cornelia Huck
-1 siblings, 0 replies; 66+ messages in thread
From: Cornelia Huck @ 2020-07-27 15:50 UTC (permalink / raw)
To: David Gibson
Cc: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh,
ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth
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
>
> - 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.
This could be workable, I guess. Would like a second opinion, though.
>
> 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(+)
>
> 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;
> +}
So here's where I'm confused: If I follow the code correctly, the
->kvm_init callback is invoked before kvm_arch_init() is called. The
kvm_arch_init() implementation for s390x checks whether
KVM_CAP_S390_PROTECTED is available, which is a pre-req for
S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
hardware check whether this works as intended?
> +
> +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);
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-07-27 15:50 ` Cornelia Huck
0 siblings, 0 replies; 66+ messages in thread
From: Cornelia Huck @ 2020-07-27 15:50 UTC (permalink / raw)
To: David Gibson
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
David Hildenbrand, qemu-devel, dgilbert, pasic,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, ehabkost
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
>
> - 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.
This could be workable, I guess. Would like a second opinion, though.
>
> 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(+)
>
> 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;
> +}
So here's where I'm confused: If I follow the code correctly, the
->kvm_init callback is invoked before kvm_arch_init() is called. The
kvm_arch_init() implementation for s390x checks whether
KVM_CAP_S390_PROTECTED is available, which is a pre-req for
S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
hardware check whether this works as intended?
> +
> +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);
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-07-27 15:50 ` Cornelia Huck
@ 2020-08-03 7:40 ` Janosch Frank
-1 siblings, 0 replies; 66+ messages in thread
From: Janosch Frank @ 2020-08-03 7:40 UTC (permalink / raw)
To: Cornelia Huck, David Gibson
Cc: dgilbert, pair, qemu-devel, pbonzini, brijesh.singh, ehabkost,
marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm, pasic,
qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth
[-- Attachment #1.1: Type: text/plain, Size: 5130 bytes --]
On 7/27/20 5:50 PM, Cornelia Huck 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
>>
>> - 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.
>
> This could be workable, I guess. Would like a second opinion, though.
>
>>
>> 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(+)
>>
>> 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;
>> +}
>
> So here's where I'm confused: If I follow the code correctly, the
> ->kvm_init callback is invoked before kvm_arch_init() is called. The
> kvm_arch_init() implementation for s390x checks whether
> KVM_CAP_S390_PROTECTED is available, which is a pre-req for
> S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
> hardware check whether this works as intended?
Doesn't look good:
./s390x-run s390x/stsi.img -object s390-pv-guest,id=pv0 -machine
host-trust-limitation=pv0
/usr/local/bin/qemu-system-s390x -nodefaults -nographic -machine
s390-ccw-virtio,accel=kvm -chardev stdio,id=con0 -device
sclpconsole,chardev=con0 -kernel s390x/stsi.img -object
s390-pv-guest,id=pv0 -machine host-trust-limitation=pv0 # -initrd
/tmp/tmp.uacr85fJnw
qemu-system-s390x: CPU model does not support Protected Virtualization
qemu-system-s390x: failed to initialize kvm: Operation not permitted
Without the htl it's happy.
>
>> +
>> +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);
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-03 7:40 ` Janosch Frank
0 siblings, 0 replies; 66+ messages in thread
From: Janosch Frank @ 2020-08-03 7:40 UTC (permalink / raw)
To: Cornelia Huck, David Gibson
Cc: pair, brijesh.singh, ehabkost, kvm, Michael S. Tsirkin,
David Hildenbrand, dgilbert, qemu-devel, pasic,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, mdroth, Richard Henderson
[-- Attachment #1.1: Type: text/plain, Size: 5130 bytes --]
On 7/27/20 5:50 PM, Cornelia Huck 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
>>
>> - 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.
>
> This could be workable, I guess. Would like a second opinion, though.
>
>>
>> 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(+)
>>
>> 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;
>> +}
>
> So here's where I'm confused: If I follow the code correctly, the
> ->kvm_init callback is invoked before kvm_arch_init() is called. The
> kvm_arch_init() implementation for s390x checks whether
> KVM_CAP_S390_PROTECTED is available, which is a pre-req for
> S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
> hardware check whether this works as intended?
Doesn't look good:
./s390x-run s390x/stsi.img -object s390-pv-guest,id=pv0 -machine
host-trust-limitation=pv0
/usr/local/bin/qemu-system-s390x -nodefaults -nographic -machine
s390-ccw-virtio,accel=kvm -chardev stdio,id=con0 -device
sclpconsole,chardev=con0 -kernel s390x/stsi.img -object
s390-pv-guest,id=pv0 -machine host-trust-limitation=pv0 # -initrd
/tmp/tmp.uacr85fJnw
qemu-system-s390x: CPU model does not support Protected Virtualization
qemu-system-s390x: failed to initialize kvm: Operation not permitted
Without the htl it's happy.
>
>> +
>> +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);
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-07-24 2:57 ` David Gibson
@ 2020-08-03 7:49 ` Janosch Frank
-1 siblings, 0 replies; 66+ messages in thread
From: Janosch Frank @ 2020-08-03 7:49 UTC (permalink / raw)
To: David Gibson, dgilbert, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson
[-- Attachment #1.1: Type: text/plain, Size: 4434 bytes --]
On 7/24/20 4:57 AM, David Gibson 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
>
> - 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.
As I already explained, they have to continue to work without any change
to the VM's configuration.
Our users already expect PV to work without HTL. This feature is already
being used and the documentation has been online for a few months. I've
already heard enough complains because users found small errors in our
documentation. I'm not looking forward to complains because suddenly we
need to specify new command line arguments depending on the QEMU version.
@Cornelia: QEMU is not my expertise, am I missing something here?
>
> 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(+)
>
> 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);
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-03 7:49 ` Janosch Frank
0 siblings, 0 replies; 66+ messages in thread
From: Janosch Frank @ 2020-08-03 7:49 UTC (permalink / raw)
To: David Gibson, dgilbert, pair, qemu-devel, pbonzini, brijesh.singh
Cc: Thomas Huth, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, Cornelia Huck,
David Hildenbrand, mdroth, pasic, Christian Borntraeger,
qemu-s390x, qemu-ppc, Richard Henderson
[-- Attachment #1.1: Type: text/plain, Size: 4434 bytes --]
On 7/24/20 4:57 AM, David Gibson 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
>
> - 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.
As I already explained, they have to continue to work without any change
to the VM's configuration.
Our users already expect PV to work without HTL. This feature is already
being used and the documentation has been online for a few months. I've
already heard enough complains because users found small errors in our
documentation. I'm not looking forward to complains because suddenly we
need to specify new command line arguments depending on the QEMU version.
@Cornelia: QEMU is not my expertise, am I missing something here?
>
> 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(+)
>
> 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);
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-08-03 7:49 ` Janosch Frank
@ 2020-08-03 7:54 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-08-03 7:54 UTC (permalink / raw)
To: Janosch Frank
Cc: dgilbert, pair, qemu-devel, pbonzini, brijesh.singh, Thomas Huth,
Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson
[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]
On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
> On 7/24/20 4:57 AM, David Gibson 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
> >
> > - 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.
>
> As I already explained, they have to continue to work without any change
> to the VM's configuration.
Yes.. that's what I'm saying will happen.
> Our users already expect PV to work without HTL. This feature is already
> being used and the documentation has been online for a few months. I've
> already heard enough complains because users found small errors in our
> documentation. I'm not looking forward to complains because suddenly we
> need to specify new command line arguments depending on the QEMU version.
>
> @Cornelia: QEMU is not my expertise, am I missing something here?
What I'm saying here is that you don't need a new option. I'm only
suggesting we make the new option the preferred way for future
upstream releases. (the new option has the advantage that you *just*
need to specify it, and any necessary virtio or other options to be
compatible should be handled for you).
But existing configurations should work as is (I'm not sure they do
with the current patch, because I'm not familiar with the s390 code
and have no means to test PV, but that can be sorted out before
merge).
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-03 7:54 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-08-03 7:54 UTC (permalink / raw)
To: Janosch Frank
Cc: Thomas Huth, brijesh.singh, ehabkost, kvm, Michael S. Tsirkin,
qemu-devel, Cornelia Huck, David Hildenbrand, pair, dgilbert,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
pbonzini, mdroth, Richard Henderson
[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]
On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
> On 7/24/20 4:57 AM, David Gibson 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
> >
> > - 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.
>
> As I already explained, they have to continue to work without any change
> to the VM's configuration.
Yes.. that's what I'm saying will happen.
> Our users already expect PV to work without HTL. This feature is already
> being used and the documentation has been online for a few months. I've
> already heard enough complains because users found small errors in our
> documentation. I'm not looking forward to complains because suddenly we
> need to specify new command line arguments depending on the QEMU version.
>
> @Cornelia: QEMU is not my expertise, am I missing something here?
What I'm saying here is that you don't need a new option. I'm only
suggesting we make the new option the preferred way for future
upstream releases. (the new option has the advantage that you *just*
need to specify it, and any necessary virtio or other options to be
compatible should be handled for you).
But existing configurations should work as is (I'm not sure they do
with the current patch, because I'm not familiar with the s390 code
and have no means to test PV, but that can be sorted out before
merge).
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-08-03 7:54 ` David Gibson
@ 2020-08-03 8:07 ` Janosch Frank
-1 siblings, 0 replies; 66+ messages in thread
From: Janosch Frank @ 2020-08-03 8:07 UTC (permalink / raw)
To: David Gibson
Cc: dgilbert, pair, qemu-devel, pbonzini, brijesh.singh, Thomas Huth,
Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson
[-- Attachment #1.1: Type: text/plain, Size: 2640 bytes --]
On 8/3/20 9:54 AM, David Gibson wrote:
> On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
>> On 7/24/20 4:57 AM, David Gibson 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
>>>
>>> - 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.
>>
>> As I already explained, they have to continue to work without any change
>> to the VM's configuration.
>
> Yes.. that's what I'm saying will happen.
>
>> Our users already expect PV to work without HTL. This feature is already
>> being used and the documentation has been online for a few months. I've
>> already heard enough complains because users found small errors in our
>> documentation. I'm not looking forward to complains because suddenly we
>> need to specify new command line arguments depending on the QEMU version.
>>
>> @Cornelia: QEMU is not my expertise, am I missing something here?
>
> What I'm saying here is that you don't need a new option. I'm only
> suggesting we make the new option the preferred way for future
> upstream releases. (the new option has the advantage that you *just*
> need to specify it, and any necessary virtio or other options to be
> compatible should be handled for you).
>
> But existing configurations should work as is (I'm not sure they do
> with the current patch, because I'm not familiar with the s390 code
> and have no means to test PV, but that can be sorted out before
> merge).
>
OK, should and might are two different things so I was a bit concerned.
That's fine then, thanks for the answer.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-03 8:07 ` Janosch Frank
0 siblings, 0 replies; 66+ messages in thread
From: Janosch Frank @ 2020-08-03 8:07 UTC (permalink / raw)
To: David Gibson
Cc: Thomas Huth, brijesh.singh, ehabkost, kvm, Michael S. Tsirkin,
qemu-devel, Cornelia Huck, David Hildenbrand, pair, dgilbert,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
pbonzini, mdroth, Richard Henderson
[-- Attachment #1.1: Type: text/plain, Size: 2640 bytes --]
On 8/3/20 9:54 AM, David Gibson wrote:
> On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
>> On 7/24/20 4:57 AM, David Gibson 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
>>>
>>> - 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.
>>
>> As I already explained, they have to continue to work without any change
>> to the VM's configuration.
>
> Yes.. that's what I'm saying will happen.
>
>> Our users already expect PV to work without HTL. This feature is already
>> being used and the documentation has been online for a few months. I've
>> already heard enough complains because users found small errors in our
>> documentation. I'm not looking forward to complains because suddenly we
>> need to specify new command line arguments depending on the QEMU version.
>>
>> @Cornelia: QEMU is not my expertise, am I missing something here?
>
> What I'm saying here is that you don't need a new option. I'm only
> suggesting we make the new option the preferred way for future
> upstream releases. (the new option has the advantage that you *just*
> need to specify it, and any necessary virtio or other options to be
> compatible should be handled for you).
>
> But existing configurations should work as is (I'm not sure they do
> with the current patch, because I'm not familiar with the s390 code
> and have no means to test PV, but that can be sorted out before
> merge).
>
OK, should and might are two different things so I was a bit concerned.
That's fine then, thanks for the answer.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-08-03 8:07 ` Janosch Frank
@ 2020-08-03 8:14 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-08-03 8:14 UTC (permalink / raw)
To: Janosch Frank
Cc: dgilbert, pair, qemu-devel, pbonzini, brijesh.singh, Thomas Huth,
Cornelia Huck, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson
[-- Attachment #1: Type: text/plain, Size: 3595 bytes --]
On Mon, Aug 03, 2020 at 10:07:42AM +0200, Janosch Frank wrote:
> On 8/3/20 9:54 AM, David Gibson wrote:
> > On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
> >> On 7/24/20 4:57 AM, David Gibson 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
> >>>
> >>> - 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.
> >>
> >> As I already explained, they have to continue to work without any change
> >> to the VM's configuration.
> >
> > Yes.. that's what I'm saying will happen.
> >
> >> Our users already expect PV to work without HTL. This feature is already
> >> being used and the documentation has been online for a few months. I've
> >> already heard enough complains because users found small errors in our
> >> documentation. I'm not looking forward to complains because suddenly we
> >> need to specify new command line arguments depending on the QEMU version.
> >>
> >> @Cornelia: QEMU is not my expertise, am I missing something here?
> >
> > What I'm saying here is that you don't need a new option. I'm only
> > suggesting we make the new option the preferred way for future
> > upstream releases. (the new option has the advantage that you *just*
> > need to specify it, and any necessary virtio or other options to be
> > compatible should be handled for you).
> >
> > But existing configurations should work as is (I'm not sure they do
> > with the current patch, because I'm not familiar with the s390 code
> > and have no means to test PV, but that can be sorted out before
> > merge).
> >
> OK, should and might are two different things so I was a bit concerned.
> That's fine then, thanks for the answer.
Well, the "should" and "might" are covering different things.
Existing working command lines should continue to work. But those
command lines must already have the necessary tweaks to make virtio
work properly. If you try to make a new command line for a PV guest
with a virtio device - or anything else that introduces extra PV
complications - then just chosing a CPU model with UNPACK might not be
enough. By contrast, if you set host-trust-limitation, then it should
work and be PV capable with an arbitrary set of devices, or else fail
immediately with a meaningful error.
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-03 8:14 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-08-03 8:14 UTC (permalink / raw)
To: Janosch Frank
Cc: Thomas Huth, brijesh.singh, ehabkost, kvm, Michael S. Tsirkin,
qemu-devel, Cornelia Huck, David Hildenbrand, pair, dgilbert,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
pbonzini, mdroth, Richard Henderson
[-- Attachment #1: Type: text/plain, Size: 3595 bytes --]
On Mon, Aug 03, 2020 at 10:07:42AM +0200, Janosch Frank wrote:
> On 8/3/20 9:54 AM, David Gibson wrote:
> > On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
> >> On 7/24/20 4:57 AM, David Gibson 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
> >>>
> >>> - 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.
> >>
> >> As I already explained, they have to continue to work without any change
> >> to the VM's configuration.
> >
> > Yes.. that's what I'm saying will happen.
> >
> >> Our users already expect PV to work without HTL. This feature is already
> >> being used and the documentation has been online for a few months. I've
> >> already heard enough complains because users found small errors in our
> >> documentation. I'm not looking forward to complains because suddenly we
> >> need to specify new command line arguments depending on the QEMU version.
> >>
> >> @Cornelia: QEMU is not my expertise, am I missing something here?
> >
> > What I'm saying here is that you don't need a new option. I'm only
> > suggesting we make the new option the preferred way for future
> > upstream releases. (the new option has the advantage that you *just*
> > need to specify it, and any necessary virtio or other options to be
> > compatible should be handled for you).
> >
> > But existing configurations should work as is (I'm not sure they do
> > with the current patch, because I'm not familiar with the s390 code
> > and have no means to test PV, but that can be sorted out before
> > merge).
> >
> OK, should and might are two different things so I was a bit concerned.
> That's fine then, thanks for the answer.
Well, the "should" and "might" are covering different things.
Existing working command lines should continue to work. But those
command lines must already have the necessary tweaks to make virtio
work properly. If you try to make a new command line for a PV guest
with a virtio device - or anything else that introduces extra PV
complications - then just chosing a CPU model with UNPACK might not be
enough. By contrast, if you set host-trust-limitation, then it should
work and be PV capable with an arbitrary set of devices, or else fail
immediately with a meaningful error.
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-08-03 8:14 ` David Gibson
@ 2020-08-03 8:33 ` Cornelia Huck
-1 siblings, 0 replies; 66+ messages in thread
From: Cornelia Huck @ 2020-08-03 8:33 UTC (permalink / raw)
To: David Gibson
Cc: Janosch Frank, dgilbert, pair, qemu-devel, pbonzini,
brijesh.singh, Thomas Huth, Daniel P. Berrangé,
ehabkost, kvm, Michael S. Tsirkin, David Hildenbrand, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Richard Henderson
[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]
On Mon, 3 Aug 2020 18:14:57 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Aug 03, 2020 at 10:07:42AM +0200, Janosch Frank wrote:
> > On 8/3/20 9:54 AM, David Gibson wrote:
> > > On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
> > >> On 7/24/20 4:57 AM, David Gibson 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
> > >>>
> > >>> - 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.
> > >>
> > >> As I already explained, they have to continue to work without any change
> > >> to the VM's configuration.
> > >
> > > Yes.. that's what I'm saying will happen.
> > >
> > >> Our users already expect PV to work without HTL. This feature is already
> > >> being used and the documentation has been online for a few months. I've
> > >> already heard enough complains because users found small errors in our
> > >> documentation. I'm not looking forward to complains because suddenly we
> > >> need to specify new command line arguments depending on the QEMU version.
> > >>
> > >> @Cornelia: QEMU is not my expertise, am I missing something here?
> > >
> > > What I'm saying here is that you don't need a new option. I'm only
> > > suggesting we make the new option the preferred way for future
> > > upstream releases. (the new option has the advantage that you *just*
> > > need to specify it, and any necessary virtio or other options to be
> > > compatible should be handled for you).
> > >
> > > But existing configurations should work as is (I'm not sure they do
> > > with the current patch, because I'm not familiar with the s390 code
> > > and have no means to test PV, but that can be sorted out before
> > > merge).
> > >
> > OK, should and might are two different things so I was a bit concerned.
> > That's fine then, thanks for the answer.
>
> Well, the "should" and "might" are covering different things.
> Existing working command lines should continue to work. But those
> command lines must already have the necessary tweaks to make virtio
> work properly. If you try to make a new command line for a PV guest
> with a virtio device - or anything else that introduces extra PV
> complications - then just chosing a CPU model with UNPACK might not be
> enough. By contrast, if you set host-trust-limitation, then it should
> work and be PV capable with an arbitrary set of devices, or else fail
> immediately with a meaningful error.
Yes, that was also my understanding.
Getting the interaction with the cpu model right seems to be the tricky
part, though. The UNPACK feature would only be set automatically
_after_ the htl device has already checked for it...
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-03 8:33 ` Cornelia Huck
0 siblings, 0 replies; 66+ messages in thread
From: Cornelia Huck @ 2020-08-03 8:33 UTC (permalink / raw)
To: David Gibson
Cc: pair, brijesh.singh, Janosch Frank, kvm, Michael S. Tsirkin,
David Hildenbrand, qemu-devel, dgilbert, pasic,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, ehabkost
[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]
On Mon, 3 Aug 2020 18:14:57 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Aug 03, 2020 at 10:07:42AM +0200, Janosch Frank wrote:
> > On 8/3/20 9:54 AM, David Gibson wrote:
> > > On Mon, Aug 03, 2020 at 09:49:42AM +0200, Janosch Frank wrote:
> > >> On 7/24/20 4:57 AM, David Gibson 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
> > >>>
> > >>> - 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.
> > >>
> > >> As I already explained, they have to continue to work without any change
> > >> to the VM's configuration.
> > >
> > > Yes.. that's what I'm saying will happen.
> > >
> > >> Our users already expect PV to work without HTL. This feature is already
> > >> being used and the documentation has been online for a few months. I've
> > >> already heard enough complains because users found small errors in our
> > >> documentation. I'm not looking forward to complains because suddenly we
> > >> need to specify new command line arguments depending on the QEMU version.
> > >>
> > >> @Cornelia: QEMU is not my expertise, am I missing something here?
> > >
> > > What I'm saying here is that you don't need a new option. I'm only
> > > suggesting we make the new option the preferred way for future
> > > upstream releases. (the new option has the advantage that you *just*
> > > need to specify it, and any necessary virtio or other options to be
> > > compatible should be handled for you).
> > >
> > > But existing configurations should work as is (I'm not sure they do
> > > with the current patch, because I'm not familiar with the s390 code
> > > and have no means to test PV, but that can be sorted out before
> > > merge).
> > >
> > OK, should and might are two different things so I was a bit concerned.
> > That's fine then, thanks for the answer.
>
> Well, the "should" and "might" are covering different things.
> Existing working command lines should continue to work. But those
> command lines must already have the necessary tweaks to make virtio
> work properly. If you try to make a new command line for a PV guest
> with a virtio device - or anything else that introduces extra PV
> complications - then just chosing a CPU model with UNPACK might not be
> enough. By contrast, if you set host-trust-limitation, then it should
> work and be PV capable with an arbitrary set of devices, or else fail
> immediately with a meaningful error.
Yes, that was also my understanding.
Getting the interaction with the cpu model right seems to be the tricky
part, though. The UNPACK feature would only be set automatically
_after_ the htl device has already checked for it...
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-07-27 15:50 ` Cornelia Huck
@ 2020-08-06 6:14 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-08-06 6:14 UTC (permalink / raw)
To: Cornelia Huck
Cc: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh,
ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth
[-- Attachment #1: Type: text/plain, Size: 4431 bytes --]
On Mon, Jul 27, 2020 at 05:50:40PM +0200, Cornelia Huck 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
> >
> > - 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.
>
> This could be workable, I guess. Would like a second opinion, though.
>
> >
> > 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(+)
> >
> > 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;
> > +}
>
> So here's where I'm confused: If I follow the code correctly, the
> ->kvm_init callback is invoked before kvm_arch_init() is called. The
> kvm_arch_init() implementation for s390x checks whether
> KVM_CAP_S390_PROTECTED is available, which is a pre-req for
> S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
> hardware check whether this works as intended?
Ah, yes, I need to rethink this. kvm_arch_init() happens
substantially earlier than I realized. Plus the setup of s390 cpu
models is confusing to me, it seems to set up the model after the cpu
instance is created, rather than having cpu models correspond to cpu
classes and thus existing before the cpus are actually instantiated.
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-06 6:14 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-08-06 6:14 UTC (permalink / raw)
To: Cornelia Huck
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
David Hildenbrand, qemu-devel, dgilbert, pasic,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, ehabkost
[-- Attachment #1: Type: text/plain, Size: 4431 bytes --]
On Mon, Jul 27, 2020 at 05:50:40PM +0200, Cornelia Huck 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
> >
> > - 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.
>
> This could be workable, I guess. Would like a second opinion, though.
>
> >
> > 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(+)
> >
> > 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;
> > +}
>
> So here's where I'm confused: If I follow the code correctly, the
> ->kvm_init callback is invoked before kvm_arch_init() is called. The
> kvm_arch_init() implementation for s390x checks whether
> KVM_CAP_S390_PROTECTED is available, which is a pre-req for
> S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
> hardware check whether this works as intended?
Ah, yes, I need to rethink this. kvm_arch_init() happens
substantially earlier than I realized. Plus the setup of s390 cpu
models is confusing to me, it seems to set up the model after the cpu
instance is created, rather than having cpu models correspond to cpu
classes and thus existing before the cpus are actually instantiated.
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-08-06 6:14 ` David Gibson
@ 2020-08-06 7:18 ` David Hildenbrand
-1 siblings, 0 replies; 66+ messages in thread
From: David Hildenbrand @ 2020-08-06 7:18 UTC (permalink / raw)
To: David Gibson, Cornelia Huck
Cc: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh,
ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
pasic, qemu-s390x, Christian Borntraeger, Richard Henderson,
Daniel P. Berrangé,
mdroth, Thomas Huth
On 06.08.20 08:14, David Gibson wrote:
> On Mon, Jul 27, 2020 at 05:50:40PM +0200, Cornelia Huck 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
>>>
>>> - 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.
>>
>> This could be workable, I guess. Would like a second opinion, though.
>>
>>>
>>> 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(+)
>>>
>>> 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;
>>> +}
>>
>> So here's where I'm confused: If I follow the code correctly, the
>> ->kvm_init callback is invoked before kvm_arch_init() is called. The
>> kvm_arch_init() implementation for s390x checks whether
>> KVM_CAP_S390_PROTECTED is available, which is a pre-req for
>> S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
>> hardware check whether this works as intended?
>
> Ah, yes, I need to rethink this. kvm_arch_init() happens
> substantially earlier than I realized. Plus the setup of s390 cpu
> models is confusing to me, it seems to set up the model after the cpu
> instance is created, rather than having cpu models correspond to cpu
> classes and thus existing before the cpus are actually instantiated.
The class only contains the cpu definition, the instance contains the
actual model. A definition is static and immutable at runtime (e.g., a
z15 with all possible features), a model is a variation of that (e.g.,
enable/disable features, e.g., a z15 with features available in the
current configuration).
We initialize the actual model in instance_init() (so during init, not
after init), where we create and initialize cpu->model, based on the cpu
definition in the class information (xcc->cpu_def).
In case of qemu/host/max model, we have to construct the cpu model at
init time, because the cpu model does not match an exact cpu definition
we have at hand.
So whenever we init a cpu, we already have to have kvm running such that
we can query the actual host/max model to construct cpu->model.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-08-06 7:18 ` David Hildenbrand
0 siblings, 0 replies; 66+ messages in thread
From: David Hildenbrand @ 2020-08-06 7:18 UTC (permalink / raw)
To: David Gibson, Cornelia Huck
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
qemu-devel, dgilbert, pasic, Christian Borntraeger, qemu-s390x,
qemu-ppc, Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, ehabkost
On 06.08.20 08:14, David Gibson wrote:
> On Mon, Jul 27, 2020 at 05:50:40PM +0200, Cornelia Huck 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
>>>
>>> - 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.
>>
>> This could be workable, I guess. Would like a second opinion, though.
>>
>>>
>>> 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(+)
>>>
>>> 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;
>>> +}
>>
>> So here's where I'm confused: If I follow the code correctly, the
>> ->kvm_init callback is invoked before kvm_arch_init() is called. The
>> kvm_arch_init() implementation for s390x checks whether
>> KVM_CAP_S390_PROTECTED is available, which is a pre-req for
>> S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
>> hardware check whether this works as intended?
>
> Ah, yes, I need to rethink this. kvm_arch_init() happens
> substantially earlier than I realized. Plus the setup of s390 cpu
> models is confusing to me, it seems to set up the model after the cpu
> instance is created, rather than having cpu models correspond to cpu
> classes and thus existing before the cpus are actually instantiated.
The class only contains the cpu definition, the instance contains the
actual model. A definition is static and immutable at runtime (e.g., a
z15 with all possible features), a model is a variation of that (e.g.,
enable/disable features, e.g., a z15 with features available in the
current configuration).
We initialize the actual model in instance_init() (so during init, not
after init), where we create and initialize cpu->model, based on the cpu
definition in the class information (xcc->cpu_def).
In case of qemu/host/max model, we have to construct the cpu model at
init time, because the cpu model does not match an exact cpu definition
we have at hand.
So whenever we init a cpu, we already have to have kvm running such that
we can query the actual host/max model to construct cpu->model.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
2020-07-27 15:05 ` Dr. David Alan Gilbert
@ 2020-08-13 7:43 ` Greg Kurz
-1 siblings, 0 replies; 66+ messages in thread
From: Greg Kurz @ 2020-08-13 7:43 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: David Gibson, pair, Cornelia Huck, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, David Hildenbrand, qemu-devel, mdroth, pasic,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
marcel.apfelbaum, Thomas Huth, pbonzini, Richard Henderson,
ehabkost
On Mon, 27 Jul 2020 16:05:14 +0100
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * David Gibson (david@gibson.dropbear.id.au) wrote:
> > The default behaviour for virtio devices is not to use the platforms normal
> > DMA paths, but instead to use the fact that it's running in a hypervisor
> > to directly access guest memory. That doesn't work if the guest's memory
> > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> >
> > So, if a host trust limitation mechanism is enabled, then apply the
> > iommu_platform=on option so it will go through normal DMA mechanisms.
> > Those will presumably have some way of marking memory as shared with the
> > hypervisor or hardware so that DMA will work.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Good, it's just too easy to forget them at the moment and get hopelessly
> confused.
>
>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>
> > ---
> > hw/core/machine.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index b599b0ba65..2a723bf07b 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -28,6 +28,8 @@
> > #include "hw/mem/nvdimm.h"
> > #include "migration/vmstate.h"
> > #include "exec/host-trust-limitation.h"
> > +#include "hw/virtio/virtio.h"
> > +#include "hw/virtio/virtio-pci.h"
> >
> > GlobalProperty hw_compat_5_0[] = {
> > { "virtio-balloon-device", "page-poison", "false" },
> > @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> > * areas.
> > */
> > machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> > +
> > + /*
> > + * Virtio devices can't count on directly accessing guest
> > + * memory, so they need iommu_platform=on to use normal DMA
> > + * mechanisms. That requires disabling legacy virtio support
> > + * for virtio pci devices
> > + */
> > + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
What about non-transitional devices (eg. vhost-user-fs-pci) ? They don't know
about "disable-legacy" since they don't need it.
> > + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> > }
> >
> > machine_class->init(machine);
> > --
> > 2.26.2
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
@ 2020-08-13 7:43 ` Greg Kurz
0 siblings, 0 replies; 66+ messages in thread
From: Greg Kurz @ 2020-08-13 7:43 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
Cornelia Huck, David Hildenbrand, qemu-devel, ehabkost, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc, pbonzini,
Thomas Huth, Daniel P. Berrangé,
Richard Henderson, David Gibson
On Mon, 27 Jul 2020 16:05:14 +0100
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * David Gibson (david@gibson.dropbear.id.au) wrote:
> > The default behaviour for virtio devices is not to use the platforms normal
> > DMA paths, but instead to use the fact that it's running in a hypervisor
> > to directly access guest memory. That doesn't work if the guest's memory
> > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> >
> > So, if a host trust limitation mechanism is enabled, then apply the
> > iommu_platform=on option so it will go through normal DMA mechanisms.
> > Those will presumably have some way of marking memory as shared with the
> > hypervisor or hardware so that DMA will work.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Good, it's just too easy to forget them at the moment and get hopelessly
> confused.
>
>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>
> > ---
> > hw/core/machine.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index b599b0ba65..2a723bf07b 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -28,6 +28,8 @@
> > #include "hw/mem/nvdimm.h"
> > #include "migration/vmstate.h"
> > #include "exec/host-trust-limitation.h"
> > +#include "hw/virtio/virtio.h"
> > +#include "hw/virtio/virtio-pci.h"
> >
> > GlobalProperty hw_compat_5_0[] = {
> > { "virtio-balloon-device", "page-poison", "false" },
> > @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> > * areas.
> > */
> > machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> > +
> > + /*
> > + * Virtio devices can't count on directly accessing guest
> > + * memory, so they need iommu_platform=on to use normal DMA
> > + * mechanisms. That requires disabling legacy virtio support
> > + * for virtio pci devices
> > + */
> > + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
What about non-transitional devices (eg. vhost-user-fs-pci) ? They don't know
about "disable-legacy" since they don't need it.
> > + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> > }
> >
> > machine_class->init(machine);
> > --
> > 2.26.2
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
2020-08-13 7:43 ` Greg Kurz
@ 2020-08-13 8:19 ` Greg Kurz
-1 siblings, 0 replies; 66+ messages in thread
From: Greg Kurz @ 2020-08-13 8:19 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
Cornelia Huck, David Hildenbrand, qemu-devel, ehabkost, mdroth,
pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
marcel.apfelbaum, pbonzini, Thomas Huth, Daniel P.Berrangé,
Richard Henderson, David Gibson
On Thu, 13 Aug 2020 09:43:56 +0200
Greg Kurz <groug@kaod.org> wrote:
> On Mon, 27 Jul 2020 16:05:14 +0100
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
>
> > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > The default behaviour for virtio devices is not to use the platforms normal
> > > DMA paths, but instead to use the fact that it's running in a hypervisor
> > > to directly access guest memory. That doesn't work if the guest's memory
> > > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> > >
> > > So, if a host trust limitation mechanism is enabled, then apply the
> > > iommu_platform=on option so it will go through normal DMA mechanisms.
> > > Those will presumably have some way of marking memory as shared with the
> > > hypervisor or hardware so that DMA will work.
> > >
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Good, it's just too easy to forget them at the moment and get hopelessly
> > confused.
> >
> >
> > Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> >
> > > ---
> > > hw/core/machine.c | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > index b599b0ba65..2a723bf07b 100644
> > > --- a/hw/core/machine.c
> > > +++ b/hw/core/machine.c
> > > @@ -28,6 +28,8 @@
> > > #include "hw/mem/nvdimm.h"
> > > #include "migration/vmstate.h"
> > > #include "exec/host-trust-limitation.h"
> > > +#include "hw/virtio/virtio.h"
> > > +#include "hw/virtio/virtio-pci.h"
> > >
> > > GlobalProperty hw_compat_5_0[] = {
> > > { "virtio-balloon-device", "page-poison", "false" },
> > > @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> > > * areas.
> > > */
> > > machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> > > +
> > > + /*
> > > + * Virtio devices can't count on directly accessing guest
> > > + * memory, so they need iommu_platform=on to use normal DMA
> > > + * mechanisms. That requires disabling legacy virtio support
> > > + * for virtio pci devices
> > > + */
> > > + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
>
> What about non-transitional devices (eg. vhost-user-fs-pci) ? They don't know
> about "disable-legacy" since they don't need it.
>
Ok, it looks like we should add a bool argument to object_register_sugar_prop()
that sets the .optional field of GlobalProperty.
> > > + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> > > }
> > >
> > > machine_class->init(machine);
> > > --
> > > 2.26.2
> > >
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> >
> >
>
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
@ 2020-08-13 8:19 ` Greg Kurz
0 siblings, 0 replies; 66+ messages in thread
From: Greg Kurz @ 2020-08-13 8:19 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
David Gibson, Cornelia Huck, David Hildenbrand, qemu-devel,
mdroth, pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P.Berrangé,
Thomas Huth, pbonzini, Richard Henderson, ehabkost
On Thu, 13 Aug 2020 09:43:56 +0200
Greg Kurz <groug@kaod.org> wrote:
> On Mon, 27 Jul 2020 16:05:14 +0100
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
>
> > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > The default behaviour for virtio devices is not to use the platforms normal
> > > DMA paths, but instead to use the fact that it's running in a hypervisor
> > > to directly access guest memory. That doesn't work if the guest's memory
> > > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> > >
> > > So, if a host trust limitation mechanism is enabled, then apply the
> > > iommu_platform=on option so it will go through normal DMA mechanisms.
> > > Those will presumably have some way of marking memory as shared with the
> > > hypervisor or hardware so that DMA will work.
> > >
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Good, it's just too easy to forget them at the moment and get hopelessly
> > confused.
> >
> >
> > Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> >
> > > ---
> > > hw/core/machine.c | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > index b599b0ba65..2a723bf07b 100644
> > > --- a/hw/core/machine.c
> > > +++ b/hw/core/machine.c
> > > @@ -28,6 +28,8 @@
> > > #include "hw/mem/nvdimm.h"
> > > #include "migration/vmstate.h"
> > > #include "exec/host-trust-limitation.h"
> > > +#include "hw/virtio/virtio.h"
> > > +#include "hw/virtio/virtio-pci.h"
> > >
> > > GlobalProperty hw_compat_5_0[] = {
> > > { "virtio-balloon-device", "page-poison", "false" },
> > > @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> > > * areas.
> > > */
> > > machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> > > +
> > > + /*
> > > + * Virtio devices can't count on directly accessing guest
> > > + * memory, so they need iommu_platform=on to use normal DMA
> > > + * mechanisms. That requires disabling legacy virtio support
> > > + * for virtio pci devices
> > > + */
> > > + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
>
> What about non-transitional devices (eg. vhost-user-fs-pci) ? They don't know
> about "disable-legacy" since they don't need it.
>
Ok, it looks like we should add a bool argument to object_register_sugar_prop()
that sets the .optional field of GlobalProperty.
> > > + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> > > }
> > >
> > > machine_class->init(machine);
> > > --
> > > 2.26.2
> > >
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> >
> >
>
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
2020-07-24 2:57 ` David Gibson
@ 2020-09-07 15:10 ` Halil Pasic
-1 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-07 15:10 UTC (permalink / raw)
To: David Gibson
Cc: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh,
ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Boris Fiuczynski,
Bjoern Walk
On Fri, 24 Jul 2020 12:57:43 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> The default behaviour for virtio devices is not to use the platforms normal
> DMA paths, but instead to use the fact that it's running in a hypervisor
> to directly access guest memory. That doesn't work if the guest's memory
> is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
>
> So, if a host trust limitation mechanism is enabled, then apply the
> iommu_platform=on option so it will go through normal DMA mechanisms.
> Those will presumably have some way of marking memory as shared with the
> hypervisor or hardware so that DMA will work.
Sorry for being this late. I had to do some high priority debugging,
which made me drop everything else, and after that I had some vacation.
I have some questions about the bigger picture. The promised benefit of
this patch for users that invoke QEMU manually is relatively clear: it
alters the default value of some virtio properties, so that using the
defaults does not result in a bugous configuration.
This comes at a price. I used to think of device property default values
like this. If I don't specify it and I use the default machine, I will
effectively get the the default value of of the property (as reported by
qemu -device dev-name,?). If I use a compat machine, then I will get the
compatibility default value: i.e. the what is reported as the default
value, if I invoke the binary whose default machine is my compat machine.
With this patch, that reasoning is not valid any more. Did we do
something like this before, or is this the first time we introduce this
complication?
In any case, I suppose, this change needs a documentation update, which I
could not find in the series.
How are things supposed to pan out when QEMU is used with management
software?
I was told that libvirt's policy is to be explicit and not let QEMU use
defaults. But this policy does not seem to apply to iommu_platform -- at
least not on s390x. Why is this? Is this likely to change in the future?
Furthermore, the libvirt documentation is IMHO not that great when it
comes to iommu_platform. All I've found is
"""
Virtio-related options
QEMU's virtio devices have some attributes related to the virtio transport under the driver element: The iommu attribute enables the use of emulated IOMMU by the device.
"""
which:
* Is not explicit about the default, but suggests that default is off
(because it needs to be enabled), which would reflect the current state
of affairs (without this patch).
* Makes me wonder, to what extent does the libvirt concept correspond
to the virtio semantics of _F_ACCESS_PLATFORM. I.e. we don't really
do any IOMMU emulation with virtio-ccw.
I guess host trust limitation is something that is to be expressed in
libvirt, or? Do we have a design for that?
I was also reflecting on how does this patch compare to on/off/auto, but
this email is already too long, so decided keep my thoughts for myself
-- for now.
Regards,
Halil
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> hw/core/machine.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index b599b0ba65..2a723bf07b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -28,6 +28,8 @@
> #include "hw/mem/nvdimm.h"
> #include "migration/vmstate.h"
> #include "exec/host-trust-limitation.h"
> +#include "hw/virtio/virtio.h"
> +#include "hw/virtio/virtio-pci.h"
>
> GlobalProperty hw_compat_5_0[] = {
> { "virtio-balloon-device", "page-poison", "false" },
> @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> * areas.
> */
> machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> +
> + /*
> + * Virtio devices can't count on directly accessing guest
> + * memory, so they need iommu_platform=on to use normal DMA
> + * mechanisms. That requires disabling legacy virtio support
> + * for virtio pci devices
> + */
> + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
> + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> }
>
> machine_class->init(machine);
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
@ 2020-09-07 15:10 ` Halil Pasic
0 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-07 15:10 UTC (permalink / raw)
To: David Gibson
Cc: pair, Cornelia Huck, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, David Hildenbrand, qemu-devel, dgilbert,
Christian Borntraeger, qemu-s390x, Boris Fiuczynski, qemu-ppc,
Daniel P. Berrangé,
Bjoern Walk, Thomas Huth, pbonzini, Richard Henderson, mdroth,
ehabkost
On Fri, 24 Jul 2020 12:57:43 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> The default behaviour for virtio devices is not to use the platforms normal
> DMA paths, but instead to use the fact that it's running in a hypervisor
> to directly access guest memory. That doesn't work if the guest's memory
> is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
>
> So, if a host trust limitation mechanism is enabled, then apply the
> iommu_platform=on option so it will go through normal DMA mechanisms.
> Those will presumably have some way of marking memory as shared with the
> hypervisor or hardware so that DMA will work.
Sorry for being this late. I had to do some high priority debugging,
which made me drop everything else, and after that I had some vacation.
I have some questions about the bigger picture. The promised benefit of
this patch for users that invoke QEMU manually is relatively clear: it
alters the default value of some virtio properties, so that using the
defaults does not result in a bugous configuration.
This comes at a price. I used to think of device property default values
like this. If I don't specify it and I use the default machine, I will
effectively get the the default value of of the property (as reported by
qemu -device dev-name,?). If I use a compat machine, then I will get the
compatibility default value: i.e. the what is reported as the default
value, if I invoke the binary whose default machine is my compat machine.
With this patch, that reasoning is not valid any more. Did we do
something like this before, or is this the first time we introduce this
complication?
In any case, I suppose, this change needs a documentation update, which I
could not find in the series.
How are things supposed to pan out when QEMU is used with management
software?
I was told that libvirt's policy is to be explicit and not let QEMU use
defaults. But this policy does not seem to apply to iommu_platform -- at
least not on s390x. Why is this? Is this likely to change in the future?
Furthermore, the libvirt documentation is IMHO not that great when it
comes to iommu_platform. All I've found is
"""
Virtio-related options
QEMU's virtio devices have some attributes related to the virtio transport under the driver element: The iommu attribute enables the use of emulated IOMMU by the device.
"""
which:
* Is not explicit about the default, but suggests that default is off
(because it needs to be enabled), which would reflect the current state
of affairs (without this patch).
* Makes me wonder, to what extent does the libvirt concept correspond
to the virtio semantics of _F_ACCESS_PLATFORM. I.e. we don't really
do any IOMMU emulation with virtio-ccw.
I guess host trust limitation is something that is to be expressed in
libvirt, or? Do we have a design for that?
I was also reflecting on how does this patch compare to on/off/auto, but
this email is already too long, so decided keep my thoughts for myself
-- for now.
Regards,
Halil
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> hw/core/machine.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index b599b0ba65..2a723bf07b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -28,6 +28,8 @@
> #include "hw/mem/nvdimm.h"
> #include "migration/vmstate.h"
> #include "exec/host-trust-limitation.h"
> +#include "hw/virtio/virtio.h"
> +#include "hw/virtio/virtio-pci.h"
>
> GlobalProperty hw_compat_5_0[] = {
> { "virtio-balloon-device", "page-poison", "false" },
> @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> * areas.
> */
> machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> +
> + /*
> + * Virtio devices can't count on directly accessing guest
> + * memory, so they need iommu_platform=on to use normal DMA
> + * mechanisms. That requires disabling legacy virtio support
> + * for virtio pci devices
> + */
> + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
> + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> }
>
> machine_class->init(machine);
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-07-24 2:57 ` David Gibson
@ 2020-09-07 15:22 ` Halil Pasic
-1 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-07 15:22 UTC (permalink / raw)
To: David Gibson
Cc: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh,
ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck
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
^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-09-07 15:22 ` Halil Pasic
0 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-07 15:22 UTC (permalink / raw)
To: David Gibson
Cc: pair, Cornelia Huck, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, David Hildenbrand, qemu-devel, dgilbert,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, ehabkost
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
^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-09-07 15:22 ` Halil Pasic
@ 2020-09-10 11:36 ` Cornelia Huck
-1 siblings, 0 replies; 66+ messages in thread
From: Cornelia Huck @ 2020-09-10 11:36 UTC (permalink / raw)
To: Halil Pasic
Cc: David Gibson, dgilbert, frankja, pair, qemu-devel, pbonzini,
brijesh.singh, ehabkost, marcel.apfelbaum, Michael S. Tsirkin,
qemu-ppc, kvm, qemu-s390x, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth
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?
> + }
> if (vdc->realize != NULL) {
> vdc->realize(dev, &err);
> if (err != NULL) {
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-09-10 11:36 ` Cornelia Huck
0 siblings, 0 replies; 66+ messages in thread
From: Cornelia Huck @ 2020-09-10 11:36 UTC (permalink / raw)
To: Halil Pasic
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
David Hildenbrand, qemu-devel, ehabkost, dgilbert,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, David Gibson
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?
> + }
> if (vdc->realize != NULL) {
> vdc->realize(dev, &err);
> if (err != NULL) {
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-09-10 11:36 ` Cornelia Huck
@ 2020-09-10 18:29 ` Halil Pasic
-1 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-10 18:29 UTC (permalink / raw)
To: Cornelia Huck
Cc: David Gibson, dgilbert, frankja, pair, qemu-devel, pbonzini,
brijesh.singh, ehabkost, marcel.apfelbaum, Michael S. Tsirkin,
qemu-ppc, kvm, qemu-s390x, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth
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
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-09-10 18:29 ` Halil Pasic
0 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-10 18:29 UTC (permalink / raw)
To: Cornelia Huck
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
David Hildenbrand, qemu-devel, ehabkost, dgilbert,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, David Gibson
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
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-09-10 18:29 ` Halil Pasic
@ 2020-09-11 0:07 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-09-11 0:07 UTC (permalink / raw)
To: Halil Pasic
Cc: Cornelia Huck, dgilbert, frankja, pair, qemu-devel, pbonzini,
brijesh.singh, ehabkost, marcel.apfelbaum, Michael S. Tsirkin,
qemu-ppc, kvm, qemu-s390x, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth
[-- Attachment #1: Type: text/plain, Size: 4222 bytes --]
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.
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-09-11 0:07 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-09-11 0:07 UTC (permalink / raw)
To: Halil Pasic
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
Cornelia Huck, David Hildenbrand, qemu-devel, dgilbert,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, ehabkost
[-- Attachment #1: Type: text/plain, Size: 4222 bytes --]
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.
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
2020-09-07 15:10 ` Halil Pasic
@ 2020-09-11 2:04 ` David Gibson
-1 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-09-11 2:04 UTC (permalink / raw)
To: Halil Pasic
Cc: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh,
ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Boris Fiuczynski,
Bjoern Walk
[-- Attachment #1: Type: text/plain, Size: 6331 bytes --]
On Mon, Sep 07, 2020 at 05:10:46PM +0200, Halil Pasic wrote:
> On Fri, 24 Jul 2020 12:57:43 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > The default behaviour for virtio devices is not to use the platforms normal
> > DMA paths, but instead to use the fact that it's running in a hypervisor
> > to directly access guest memory. That doesn't work if the guest's memory
> > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> >
> > So, if a host trust limitation mechanism is enabled, then apply the
> > iommu_platform=on option so it will go through normal DMA mechanisms.
> > Those will presumably have some way of marking memory as shared with the
> > hypervisor or hardware so that DMA will work.
>
> Sorry for being this late. I had to do some high priority debugging,
> which made me drop everything else, and after that I had some vacation.
>
> I have some questions about the bigger picture. The promised benefit of
> this patch for users that invoke QEMU manually is relatively clear: it
> alters the default value of some virtio properties, so that using the
> defaults does not result in a bugous configuration.
Right.
> This comes at a price. I used to think of device property default values
> like this. If I don't specify it and I use the default machine, I will
> effectively get the the default value of of the property (as reported by
> qemu -device dev-name,?). If I use a compat machine, then I will get the
> compatibility default value: i.e. the what is reported as the default
> value, if I invoke the binary whose default machine is my compat machine.
Hm, ok. My mental model has always been that defaults were
essentially per-machine-type. Which, I grant you isn't really
consistent with the existence of the -device dev,? probing. On the
other hand, it's possible for a machine/platforms to impose
restrictions on almost any property of almost any device, and it would
suck for the user to have to know all of them just in order to start
things up with default options.
Given that model, extending that to per-machine-variant, including
machine options like htl seemed natural.
> With this patch, that reasoning is not valid any more. Did we do
> something like this before, or is this the first time we introduce this
> complication?
I don't know off hand if we have per-machine differences for certain
options in practice, or only in theory.
> In any case, I suppose, this change needs a documentation update, which I
> could not find in the series.
Uh.. fair enough.. I just need to figure out where.
> How are things supposed to pan out when QEMU is used with management
> software?
>
> I was told that libvirt's policy is to be explicit and not let QEMU use
> defaults. But this policy does not seem to apply to iommu_platform -- at
> least not on s390x. Why is this? Is this likely to change in the future?
Ugh.. so. That policy of libvirt's is very double edged. It's there
because it allows libvirt to create consistent machines that can be
migrated properly and so forth. However, it basically locks libvirt
into having to know about every option of qemu, ever. Unsurprisingly
there are some gaps, hence things like this.
Unfortunately that can't be fixed without substantially redesigning
libvirt in a way that can't maintain compatibility.
> Furthermore, the libvirt documentation is IMHO not that great when it
> comes to iommu_platform. All I've found is
>
> """
> Virtio-related options
>
>
> QEMU's virtio devices have some attributes related to the virtio transport under the driver element: The iommu attribute enables the use of emulated IOMMU by the device.
> """
>
> which:
> * Is not explicit about the default, but suggests that default is off
> (because it needs to be enabled), which would reflect the current state
> of affairs (without this patch).
> * Makes me wonder, to what extent does the libvirt concept correspond
> to the virtio semantics of _F_ACCESS_PLATFORM. I.e. we don't really
> do any IOMMU emulation with virtio-ccw.
>
> I guess host trust limitation is something that is to be expressed in
> libvirt, or? Do we have a design for that?
Yeah, I guess we'd need to. See "having to know about every option"
above :/. No, I haven't thought about a design for that.
> I was also reflecting on how does this patch compare to on/off/auto, but
> this email is already too long, so decided keep my thoughts for myself
> -- for now.
on/off/auto works for your case on s390, but I don't think it works
for POWER, though I forget the details, so maybe I'm wrong about that.
>
> Regards,
> Halil
>
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > hw/core/machine.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index b599b0ba65..2a723bf07b 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -28,6 +28,8 @@
> > #include "hw/mem/nvdimm.h"
> > #include "migration/vmstate.h"
> > #include "exec/host-trust-limitation.h"
> > +#include "hw/virtio/virtio.h"
> > +#include "hw/virtio/virtio-pci.h"
> >
> > GlobalProperty hw_compat_5_0[] = {
> > { "virtio-balloon-device", "page-poison", "false" },
> > @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> > * areas.
> > */
> > machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> > +
> > + /*
> > + * Virtio devices can't count on directly accessing guest
> > + * memory, so they need iommu_platform=on to use normal DMA
> > + * mechanisms. That requires disabling legacy virtio support
> > + * for virtio pci devices
> > + */
> > + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
> > + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> > }
> >
> > machine_class->init(machine);
>
>
>
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
@ 2020-09-11 2:04 ` David Gibson
0 siblings, 0 replies; 66+ messages in thread
From: David Gibson @ 2020-09-11 2:04 UTC (permalink / raw)
To: Halil Pasic
Cc: pair, Cornelia Huck, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, David Hildenbrand, qemu-devel, dgilbert,
Christian Borntraeger, qemu-s390x, Boris Fiuczynski, qemu-ppc,
Daniel P. Berrangé,
Bjoern Walk, Thomas Huth, pbonzini, Richard Henderson, mdroth,
ehabkost
[-- Attachment #1: Type: text/plain, Size: 6331 bytes --]
On Mon, Sep 07, 2020 at 05:10:46PM +0200, Halil Pasic wrote:
> On Fri, 24 Jul 2020 12:57:43 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > The default behaviour for virtio devices is not to use the platforms normal
> > DMA paths, but instead to use the fact that it's running in a hypervisor
> > to directly access guest memory. That doesn't work if the guest's memory
> > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> >
> > So, if a host trust limitation mechanism is enabled, then apply the
> > iommu_platform=on option so it will go through normal DMA mechanisms.
> > Those will presumably have some way of marking memory as shared with the
> > hypervisor or hardware so that DMA will work.
>
> Sorry for being this late. I had to do some high priority debugging,
> which made me drop everything else, and after that I had some vacation.
>
> I have some questions about the bigger picture. The promised benefit of
> this patch for users that invoke QEMU manually is relatively clear: it
> alters the default value of some virtio properties, so that using the
> defaults does not result in a bugous configuration.
Right.
> This comes at a price. I used to think of device property default values
> like this. If I don't specify it and I use the default machine, I will
> effectively get the the default value of of the property (as reported by
> qemu -device dev-name,?). If I use a compat machine, then I will get the
> compatibility default value: i.e. the what is reported as the default
> value, if I invoke the binary whose default machine is my compat machine.
Hm, ok. My mental model has always been that defaults were
essentially per-machine-type. Which, I grant you isn't really
consistent with the existence of the -device dev,? probing. On the
other hand, it's possible for a machine/platforms to impose
restrictions on almost any property of almost any device, and it would
suck for the user to have to know all of them just in order to start
things up with default options.
Given that model, extending that to per-machine-variant, including
machine options like htl seemed natural.
> With this patch, that reasoning is not valid any more. Did we do
> something like this before, or is this the first time we introduce this
> complication?
I don't know off hand if we have per-machine differences for certain
options in practice, or only in theory.
> In any case, I suppose, this change needs a documentation update, which I
> could not find in the series.
Uh.. fair enough.. I just need to figure out where.
> How are things supposed to pan out when QEMU is used with management
> software?
>
> I was told that libvirt's policy is to be explicit and not let QEMU use
> defaults. But this policy does not seem to apply to iommu_platform -- at
> least not on s390x. Why is this? Is this likely to change in the future?
Ugh.. so. That policy of libvirt's is very double edged. It's there
because it allows libvirt to create consistent machines that can be
migrated properly and so forth. However, it basically locks libvirt
into having to know about every option of qemu, ever. Unsurprisingly
there are some gaps, hence things like this.
Unfortunately that can't be fixed without substantially redesigning
libvirt in a way that can't maintain compatibility.
> Furthermore, the libvirt documentation is IMHO not that great when it
> comes to iommu_platform. All I've found is
>
> """
> Virtio-related options
>
>
> QEMU's virtio devices have some attributes related to the virtio transport under the driver element: The iommu attribute enables the use of emulated IOMMU by the device.
> """
>
> which:
> * Is not explicit about the default, but suggests that default is off
> (because it needs to be enabled), which would reflect the current state
> of affairs (without this patch).
> * Makes me wonder, to what extent does the libvirt concept correspond
> to the virtio semantics of _F_ACCESS_PLATFORM. I.e. we don't really
> do any IOMMU emulation with virtio-ccw.
>
> I guess host trust limitation is something that is to be expressed in
> libvirt, or? Do we have a design for that?
Yeah, I guess we'd need to. See "having to know about every option"
above :/. No, I haven't thought about a design for that.
> I was also reflecting on how does this patch compare to on/off/auto, but
> this email is already too long, so decided keep my thoughts for myself
> -- for now.
on/off/auto works for your case on s390, but I don't think it works
for POWER, though I forget the details, so maybe I'm wrong about that.
>
> Regards,
> Halil
>
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > hw/core/machine.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index b599b0ba65..2a723bf07b 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -28,6 +28,8 @@
> > #include "hw/mem/nvdimm.h"
> > #include "migration/vmstate.h"
> > #include "exec/host-trust-limitation.h"
> > +#include "hw/virtio/virtio.h"
> > +#include "hw/virtio/virtio-pci.h"
> >
> > GlobalProperty hw_compat_5_0[] = {
> > { "virtio-balloon-device", "page-poison", "false" },
> > @@ -1161,6 +1163,15 @@ void machine_run_board_init(MachineState *machine)
> > * areas.
> > */
> > machine_set_mem_merge(OBJECT(machine), false, &error_abort);
> > +
> > + /*
> > + * Virtio devices can't count on directly accessing guest
> > + * memory, so they need iommu_platform=on to use normal DMA
> > + * mechanisms. That requires disabling legacy virtio support
> > + * for virtio pci devices
> > + */
> > + object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy", "on");
> > + object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform", "on");
> > }
> >
> > machine_class->init(machine);
>
>
>
--
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 --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-09-11 0:07 ` David Gibson
@ 2020-09-11 6:25 ` Greg Kurz
-1 siblings, 0 replies; 66+ messages in thread
From: Greg Kurz @ 2020-09-11 6:25 UTC (permalink / raw)
To: David Gibson
Cc: Halil Pasic, pair, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, Cornelia Huck, David Hildenbrand, qemu-devel,
dgilbert, Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
marcel.apfelbaum, Thomas Huth, pbonzini, Richard Henderson,
mdroth, ehabkost
[-- Attachment #1: Type: text/plain, Size: 4487 bytes --]
On Fri, 11 Sep 2020 10:07:18 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> 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.
>
I guess this deserves at least a warning for the case of someone that
doesn't really know what they're doing, eg. borrowing a complex QEMU
command line or libvirt XML from somewhere else ?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-09-11 6:25 ` Greg Kurz
0 siblings, 0 replies; 66+ messages in thread
From: Greg Kurz @ 2020-09-11 6:25 UTC (permalink / raw)
To: David Gibson
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
Cornelia Huck, David Hildenbrand, qemu-devel, ehabkost, dgilbert,
Halil Pasic, Christian Borntraeger, qemu-s390x, qemu-ppc,
pbonzini, Thomas Huth, Daniel P. Berrangé,
mdroth, Richard Henderson
[-- Attachment #1: Type: text/plain, Size: 4487 bytes --]
On Fri, 11 Sep 2020 10:07:18 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> 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.
>
I guess this deserves at least a warning for the case of someone that
doesn't really know what they're doing, eg. borrowing a complex QEMU
command line or libvirt XML from somewhere else ?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
2020-09-11 0:07 ` David Gibson
@ 2020-09-11 12:45 ` Halil Pasic
-1 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-11 12:45 UTC (permalink / raw)
To: David Gibson
Cc: Cornelia Huck, dgilbert, frankja, pair, qemu-devel, pbonzini,
brijesh.singh, ehabkost, marcel.apfelbaum, Michael S. Tsirkin,
qemu-ppc, kvm, qemu-s390x, David Hildenbrand,
Christian Borntraeger, Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth
[-- Attachment #1: Type: text/plain, Size: 5041 bytes --]
On Fri, 11 Sep 2020 10:07:18 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> 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.
>
According to Michael, the correctness of a hypervisor is depending on
this (if device has restricted access to guest memory, but does not
present F_ACCESS_PLATFORM then the hypervisor is buggy).
Also a hotplug of such a misconfigured device is at the moment likely
bring down the guest on s390x.
The only scenario in which the guest has protected memory and the device
is able to access it, is a trusted HW device. But then we would need
F_ACCESS_PLATFORM because it is a HW device. So I consider this combination
doing something useful very unlikely. Does anybody have a scenario where
this combination is legit and useful?
If such a scenario emerges later, I think the check can be refined or
dropped.
Regards,
Halil
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
@ 2020-09-11 12:45 ` Halil Pasic
0 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-11 12:45 UTC (permalink / raw)
To: David Gibson
Cc: pair, brijesh.singh, frankja, kvm, Michael S. Tsirkin,
Cornelia Huck, David Hildenbrand, qemu-devel, dgilbert,
Christian Borntraeger, qemu-s390x, qemu-ppc,
Daniel P. Berrangé,
Thomas Huth, pbonzini, Richard Henderson, mdroth, ehabkost
[-- Attachment #1: Type: text/plain, Size: 5041 bytes --]
On Fri, 11 Sep 2020 10:07:18 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> 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.
>
According to Michael, the correctness of a hypervisor is depending on
this (if device has restricted access to guest memory, but does not
present F_ACCESS_PLATFORM then the hypervisor is buggy).
Also a hotplug of such a misconfigured device is at the moment likely
bring down the guest on s390x.
The only scenario in which the guest has protected memory and the device
is able to access it, is a trusted HW device. But then we would need
F_ACCESS_PLATFORM because it is a HW device. So I consider this combination
doing something useful very unlikely. Does anybody have a scenario where
this combination is legit and useful?
If such a scenario emerges later, I think the check can be refined or
dropped.
Regards,
Halil
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
2020-09-11 2:04 ` David Gibson
@ 2020-09-11 13:49 ` Halil Pasic
-1 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-11 13:49 UTC (permalink / raw)
To: David Gibson
Cc: dgilbert, frankja, pair, qemu-devel, pbonzini, brijesh.singh,
ehabkost, marcel.apfelbaum, Michael S. Tsirkin, qemu-ppc, kvm,
qemu-s390x, David Hildenbrand, Christian Borntraeger,
Richard Henderson, Daniel P. Berrangé,
mdroth, Thomas Huth, Cornelia Huck, Boris Fiuczynski,
Bjoern Walk
[-- Attachment #1: Type: text/plain, Size: 7793 bytes --]
On Fri, 11 Sep 2020 12:04:42 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Sep 07, 2020 at 05:10:46PM +0200, Halil Pasic wrote:
> > On Fri, 24 Jul 2020 12:57:43 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > The default behaviour for virtio devices is not to use the platforms normal
> > > DMA paths, but instead to use the fact that it's running in a hypervisor
> > > to directly access guest memory. That doesn't work if the guest's memory
> > > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> > >
> > > So, if a host trust limitation mechanism is enabled, then apply the
> > > iommu_platform=on option so it will go through normal DMA mechanisms.
> > > Those will presumably have some way of marking memory as shared with the
> > > hypervisor or hardware so that DMA will work.
> >
> > Sorry for being this late. I had to do some high priority debugging,
> > which made me drop everything else, and after that I had some vacation.
> >
> > I have some questions about the bigger picture. The promised benefit of
> > this patch for users that invoke QEMU manually is relatively clear: it
> > alters the default value of some virtio properties, so that using the
> > defaults does not result in a bugous configuration.
>
> Right.
>
> > This comes at a price. I used to think of device property default values
> > like this. If I don't specify it and I use the default machine, I will
> > effectively get the the default value of of the property (as reported by
> > qemu -device dev-name,?). If I use a compat machine, then I will get the
> > compatibility default value: i.e. the what is reported as the default
> > value, if I invoke the binary whose default machine is my compat machine.
>
> Hm, ok. My mental model has always been that defaults were
> essentially per-machine-type. Which, I grant you isn't really
> consistent with the existence of the -device dev,? probing. On the
> other hand, it's possible for a machine/platforms to impose
> restrictions on almost any property of almost any device, and it would
> suck for the user to have to know all of them just in order to start
> things up with default options.
>
> Given that model, extending that to per-machine-variant, including
> machine options like htl seemed natural.
>
Yesterday I got some more education on the matters of Libvirt by Boris.
I think now we both agree that this complicates the mental model, but
that it simplifies usage, and is worth it.
> > With this patch, that reasoning is not valid any more. Did we do
> > something like this before, or is this the first time we introduce this
> > complication?
>
> I don't know off hand if we have per-machine differences for certain
> options in practice, or only in theory.
>
> > In any case, I suppose, this change needs a documentation update, which I
> > could not find in the series.
>
> Uh.. fair enough.. I just need to figure out where.
>
> > How are things supposed to pan out when QEMU is used with management
> > software?
> >
> > I was told that libvirt's policy is to be explicit and not let QEMU use
> > defaults. But this policy does not seem to apply to iommu_platform -- at
> > least not on s390x. Why is this? Is this likely to change in the future?
>
> Ugh.. so. That policy of libvirt's is very double edged. It's there
> because it allows libvirt to create consistent machines that can be
> migrated properly and so forth. However, it basically locks libvirt
> into having to know about every option of qemu, ever. Unsurprisingly
> there are some gaps, hence things like this.
>
> Unfortunately that can't be fixed without substantially redesigning
> libvirt in a way that can't maintain compatibility.
>
Boris told me that virtio properties are a notable exception from the
aforementioned Libvirt rule. He showed me the code, and libvirt seems to
be intentionally non-explicit on iommu and other virtio properties, in a
sense that if nothing is specified in the xml, nothing is specified on
the generated command line, and we get the default. Unfortunately, we
didn't manage to figure out the reason.
> > Furthermore, the libvirt documentation is IMHO not that great when it
> > comes to iommu_platform. All I've found is
> >
> > """
> > Virtio-related options
> >
> >
> > QEMU's virtio devices have some attributes related to the virtio transport under the driver element: The iommu attribute enables the use of emulated IOMMU by the device.
> > """
> >
> > which:
> > * Is not explicit about the default, but suggests that default is off
> > (because it needs to be enabled), which would reflect the current state
> > of affairs (without this patch).
> > * Makes me wonder, to what extent does the libvirt concept correspond
> > to the virtio semantics of _F_ACCESS_PLATFORM. I.e. we don't really
> > do any IOMMU emulation with virtio-ccw.
> >
> > I guess host trust limitation is something that is to be expressed in
> > libvirt, or? Do we have a design for that?
>
> Yeah, I guess we'd need to. See "having to know about every option"
> above :/. No, I haven't thought about a design for that.
>
> > I was also reflecting on how does this patch compare to on/off/auto, but
> > this email is already too long, so decided keep my thoughts for myself
> > -- for now.
>
> on/off/auto works for your case on s390, but I don't think it works
> for POWER, though I forget the details, so maybe I'm wrong about that.
>
If management software/libvirt will let us use the defaults, I see this
patch as a big usability improvement. Thus
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
I believe on/off/auto could work for POWER as well, just not the way I
intended it to work for s390, which is basically changing the value as
we transition the plain VM to a PV VM.
I see a potential semantic benefit to on/off/auto, compared to some
machine properties affecting the default value of some device properties.
The semantic I would like to have for on/off/auto seems to be a bit
different than the semantic the community seems to associate with auto
right now.
What I would like to have is a 'be as intelligent about it as you can'
type of 'auto'. Let me bring some examples outside QEMU. For instance
the intel_gpu_frequency tool lets one lock the GPU frequency to certain
values
(http://manpages.ubuntu.com/manpages/xenial/man1/intel_gpu_frequency.1.html).
I guess there are scenarios where that can be useful. But for normal
usage, I guess both for CPU and GPU frequency the user does not want to
have a rigid value, but it expects the system to balance the trade-offs
and tweak the frequency according to the current situation.
So in by book, auto would allow libvirt and the user to be explicit
about not wanting to control that aspect of the VM, and QEMU to step
beyond 'sane defaults'.
The current semantics of auto seems to be: if you specify auto you may
end up with something different that if you specify default, possibly
based on some environment considerations, but the 'auto' seems to be
resolved to 'on' or 'off' once, and (it seems preferably) at
initialization time.
Given all that, I'm pretty happy with your current solution. Doing
on/off/auto and resolving 'auto' based on host_trust_limitation_enabled()
would IMHO not be much different from your current solution, so I see no
big benefit to that. Maybe a tad cleaner UI, but more code, and more
complicated initialization interdependency (we would need to have
host_trust_limitation_enabled() armed when we resolve iommu_platform,
don't know if that's natural).
Regards,
Halil
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests
@ 2020-09-11 13:49 ` Halil Pasic
0 siblings, 0 replies; 66+ messages in thread
From: Halil Pasic @ 2020-09-11 13:49 UTC (permalink / raw)
To: David Gibson
Cc: pair, Cornelia Huck, brijesh.singh, frankja, kvm,
Michael S. Tsirkin, David Hildenbrand, qemu-devel, dgilbert,
Christian Borntraeger, qemu-s390x, Boris Fiuczynski, qemu-ppc,
Daniel P. Berrangé,
Bjoern Walk, Thomas Huth, pbonzini, Richard Henderson, mdroth,
ehabkost
[-- Attachment #1: Type: text/plain, Size: 7793 bytes --]
On Fri, 11 Sep 2020 12:04:42 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Sep 07, 2020 at 05:10:46PM +0200, Halil Pasic wrote:
> > On Fri, 24 Jul 2020 12:57:43 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > The default behaviour for virtio devices is not to use the platforms normal
> > > DMA paths, but instead to use the fact that it's running in a hypervisor
> > > to directly access guest memory. That doesn't work if the guest's memory
> > > is protected from hypervisor access, such as with AMD's SEV or POWER's PEF.
> > >
> > > So, if a host trust limitation mechanism is enabled, then apply the
> > > iommu_platform=on option so it will go through normal DMA mechanisms.
> > > Those will presumably have some way of marking memory as shared with the
> > > hypervisor or hardware so that DMA will work.
> >
> > Sorry for being this late. I had to do some high priority debugging,
> > which made me drop everything else, and after that I had some vacation.
> >
> > I have some questions about the bigger picture. The promised benefit of
> > this patch for users that invoke QEMU manually is relatively clear: it
> > alters the default value of some virtio properties, so that using the
> > defaults does not result in a bugous configuration.
>
> Right.
>
> > This comes at a price. I used to think of device property default values
> > like this. If I don't specify it and I use the default machine, I will
> > effectively get the the default value of of the property (as reported by
> > qemu -device dev-name,?). If I use a compat machine, then I will get the
> > compatibility default value: i.e. the what is reported as the default
> > value, if I invoke the binary whose default machine is my compat machine.
>
> Hm, ok. My mental model has always been that defaults were
> essentially per-machine-type. Which, I grant you isn't really
> consistent with the existence of the -device dev,? probing. On the
> other hand, it's possible for a machine/platforms to impose
> restrictions on almost any property of almost any device, and it would
> suck for the user to have to know all of them just in order to start
> things up with default options.
>
> Given that model, extending that to per-machine-variant, including
> machine options like htl seemed natural.
>
Yesterday I got some more education on the matters of Libvirt by Boris.
I think now we both agree that this complicates the mental model, but
that it simplifies usage, and is worth it.
> > With this patch, that reasoning is not valid any more. Did we do
> > something like this before, or is this the first time we introduce this
> > complication?
>
> I don't know off hand if we have per-machine differences for certain
> options in practice, or only in theory.
>
> > In any case, I suppose, this change needs a documentation update, which I
> > could not find in the series.
>
> Uh.. fair enough.. I just need to figure out where.
>
> > How are things supposed to pan out when QEMU is used with management
> > software?
> >
> > I was told that libvirt's policy is to be explicit and not let QEMU use
> > defaults. But this policy does not seem to apply to iommu_platform -- at
> > least not on s390x. Why is this? Is this likely to change in the future?
>
> Ugh.. so. That policy of libvirt's is very double edged. It's there
> because it allows libvirt to create consistent machines that can be
> migrated properly and so forth. However, it basically locks libvirt
> into having to know about every option of qemu, ever. Unsurprisingly
> there are some gaps, hence things like this.
>
> Unfortunately that can't be fixed without substantially redesigning
> libvirt in a way that can't maintain compatibility.
>
Boris told me that virtio properties are a notable exception from the
aforementioned Libvirt rule. He showed me the code, and libvirt seems to
be intentionally non-explicit on iommu and other virtio properties, in a
sense that if nothing is specified in the xml, nothing is specified on
the generated command line, and we get the default. Unfortunately, we
didn't manage to figure out the reason.
> > Furthermore, the libvirt documentation is IMHO not that great when it
> > comes to iommu_platform. All I've found is
> >
> > """
> > Virtio-related options
> >
> >
> > QEMU's virtio devices have some attributes related to the virtio transport under the driver element: The iommu attribute enables the use of emulated IOMMU by the device.
> > """
> >
> > which:
> > * Is not explicit about the default, but suggests that default is off
> > (because it needs to be enabled), which would reflect the current state
> > of affairs (without this patch).
> > * Makes me wonder, to what extent does the libvirt concept correspond
> > to the virtio semantics of _F_ACCESS_PLATFORM. I.e. we don't really
> > do any IOMMU emulation with virtio-ccw.
> >
> > I guess host trust limitation is something that is to be expressed in
> > libvirt, or? Do we have a design for that?
>
> Yeah, I guess we'd need to. See "having to know about every option"
> above :/. No, I haven't thought about a design for that.
>
> > I was also reflecting on how does this patch compare to on/off/auto, but
> > this email is already too long, so decided keep my thoughts for myself
> > -- for now.
>
> on/off/auto works for your case on s390, but I don't think it works
> for POWER, though I forget the details, so maybe I'm wrong about that.
>
If management software/libvirt will let us use the defaults, I see this
patch as a big usability improvement. Thus
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
I believe on/off/auto could work for POWER as well, just not the way I
intended it to work for s390, which is basically changing the value as
we transition the plain VM to a PV VM.
I see a potential semantic benefit to on/off/auto, compared to some
machine properties affecting the default value of some device properties.
The semantic I would like to have for on/off/auto seems to be a bit
different than the semantic the community seems to associate with auto
right now.
What I would like to have is a 'be as intelligent about it as you can'
type of 'auto'. Let me bring some examples outside QEMU. For instance
the intel_gpu_frequency tool lets one lock the GPU frequency to certain
values
(http://manpages.ubuntu.com/manpages/xenial/man1/intel_gpu_frequency.1.html).
I guess there are scenarios where that can be useful. But for normal
usage, I guess both for CPU and GPU frequency the user does not want to
have a rigid value, but it expects the system to balance the trade-offs
and tweak the frequency according to the current situation.
So in by book, auto would allow libvirt and the user to be explicit
about not wanting to control that aspect of the VM, and QEMU to step
beyond 'sane defaults'.
The current semantics of auto seems to be: if you specify auto you may
end up with something different that if you specify default, possibly
based on some environment considerations, but the 'auto' seems to be
resolved to 'on' or 'off' once, and (it seems preferably) at
initialization time.
Given all that, I'm pretty happy with your current solution. Doing
on/off/auto and resolving 'auto' based on host_trust_limitation_enabled()
would IMHO not be much different from your current solution, so I see no
big benefit to that. Maybe a tad cleaner UI, but more code, and more
complicated initialization interdependency (we would need to have
host_trust_limitation_enabled() armed when we resolve iommu_platform,
don't know if that's natural).
Regards,
Halil
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2020-09-11 16:16 UTC | newest]
Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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.