[PATCH v7 00/13] Generalize memory encryption models

[PATCH v7 00/13] Generalize memory encryption models

[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
"confidential-guest-support" property pointing to a platform specific
object which configures and manages the specific details.

Note to Ram Pai: the documentation I've included for PEF is very
minimal.  If you could send a patch expanding on that, it would be
very helpful.

Changes since v6:
 * Moved to using OBJECT_DECLARE_TYPE and OBJECT_DEFINE_TYPE macros
 * Assorted minor fixes
Changes since v5:
 * Renamed from "securable guest memory" to "confidential guest
   support"
 * Simpler reworking of x86 boot time flash encryption
 * Added a bunch of documentation
 * Fixed some compile errors on POWER
Changes since v4:
 * Renamed from "host trust limitation" to "securable guest memory",
   which I think is marginally more descriptive
 * Re-organized initialization, because the previous model called at
   kvm_init didn't work for s390
 * Assorted fixes to the s390 implementation; rudimentary testing
   (gitlab CI) only
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 (12):
  confidential guest support: Introduce new confidential guest support
    class
  sev: Remove false abstraction of flash encryption
  confidential guest support: Move side effect out of
    machine_set_memory_encryption()
  confidential guest support: Rework the "memory-encryption" property
  sev: Add Error ** to sev_kvm_init()
  confidential guest support: Introduce cgs "ready" flag
  confidential guest support: Move SEV initialization into arch specific
    code
  confidential guest support: Update documentation
  spapr: Add PEF based confidential guest support
  spapr: PEF: prevent migration
  confidential guest support: Alter virtio default properties for
    protected guests
  s390: Recognize confidential-guest-support option

Greg Kurz (1):
  qom: Allow optional sugar props

 accel/kvm/kvm-all.c                       |  38 -------
 accel/kvm/sev-stub.c                      |  10 +-
 accel/stubs/kvm-stub.c                    |  10 --
 backends/confidential-guest-support.c     |  33 ++++++
 backends/meson.build                      |   1 +
 docs/amd-memory-encryption.txt            |   2 +-
 docs/confidential-guest-support.txt       |  49 +++++++++
 docs/papr-pef.txt                         |  30 ++++++
 docs/system/s390x/protvirt.rst            |  19 ++--
 hw/core/machine.c                         |  71 ++++++++++--
 hw/i386/pc_sysfw.c                        |  17 ++-
 hw/ppc/meson.build                        |   1 +
 hw/ppc/pef.c                              | 126 ++++++++++++++++++++++
 hw/ppc/spapr.c                            |   6 ++
 hw/s390x/pv.c                             |  62 +++++++++++
 include/exec/confidential-guest-support.h |  40 +++++++
 include/hw/boards.h                       |   2 +-
 include/hw/ppc/pef.h                      |  25 +++++
 include/hw/s390x/pv.h                     |   1 +
 include/qemu/typedefs.h                   |   1 +
 include/qom/object.h                      |   3 +-
 include/sysemu/kvm.h                      |  16 ---
 include/sysemu/sev.h                      |   4 +-
 qom/object.c                              |   4 +-
 softmmu/rtc.c                             |   3 +-
 softmmu/vl.c                              |  17 +--
 target/i386/kvm/kvm.c                     |  12 +++
 target/i386/sev-stub.c                    |   5 +
 target/i386/sev.c                         |  93 +++++++---------
 target/ppc/kvm.c                          |  18 ----
 target/ppc/kvm_ppc.h                      |   6 --
 target/s390x/kvm.c                        |   3 +
 32 files changed, 539 insertions(+), 189 deletions(-)
 create mode 100644 backends/confidential-guest-support.c
 create mode 100644 docs/confidential-guest-support.txt
 create mode 100644 docs/papr-pef.txt
 create mode 100644 hw/ppc/pef.c
 create mode 100644 include/exec/confidential-guest-support.h
 create mode 100644 include/hw/ppc/pef.h

-- 
2.29.2

[PATCH v7 01/13] qom: Allow optional sugar props

[David Gibson]

From: Greg Kurz <groug@kaod.org>

Global properties have an @optional field, which allows to apply a given
property to a given type even if one of its subclasses doesn't support
it. This is especially used in the compat code when dealing with the
"disable-modern" and "disable-legacy" properties and the "virtio-pci"
type.

Allow object_register_sugar_prop() to set this field as well.

Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <159738953558.377274.16617742952571083440.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 include/qom/object.h |  3 ++-
 qom/object.c         |  4 +++-
 softmmu/rtc.c        |  3 ++-
 softmmu/vl.c         | 17 +++++++++++------
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/include/qom/object.h b/include/qom/object.h
index d378f13a11..6721cd312e 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -638,7 +638,8 @@ bool object_apply_global_props(Object *obj, const GPtrArray *props,
                                Error **errp);
 void object_set_machine_compat_props(GPtrArray *compat_props);
 void object_set_accelerator_compat_props(GPtrArray *compat_props);
-void object_register_sugar_prop(const char *driver, const char *prop, const char *value);
+void object_register_sugar_prop(const char *driver, const char *prop,
+                                const char *value, bool optional);
 void object_apply_compat_props(Object *obj);
 
 /**
diff --git a/qom/object.c b/qom/object.c
index 2fa0119647..491823db4a 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -442,7 +442,8 @@ static GPtrArray *object_compat_props[3];
  * other than "-global".  These are generally used for syntactic
  * sugar and legacy command line options.
  */
-void object_register_sugar_prop(const char *driver, const char *prop, const char *value)
+void object_register_sugar_prop(const char *driver, const char *prop,
+                                const char *value, bool optional)
 {
     GlobalProperty *g;
     if (!object_compat_props[2]) {
@@ -452,6 +453,7 @@ void object_register_sugar_prop(const char *driver, const char *prop, const char
     g->driver = g_strdup(driver);
     g->property = g_strdup(prop);
     g->value = g_strdup(value);
+    g->optional = optional;
     g_ptr_array_add(object_compat_props[2], g);
 }
 
diff --git a/softmmu/rtc.c b/softmmu/rtc.c
index e1e15ef613..5632684fc9 100644
--- a/softmmu/rtc.c
+++ b/softmmu/rtc.c
@@ -179,7 +179,8 @@ void configure_rtc(QemuOpts *opts)
         if (!strcmp(value, "slew")) {
             object_register_sugar_prop("mc146818rtc",
                                        "lost_tick_policy",
-                                       "slew");
+                                       "slew",
+                                       false);
         } else if (!strcmp(value, "none")) {
             /* discard is default */
         } else {
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 7ddf405d76..3f7721b83e 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1663,16 +1663,20 @@ static int machine_set_property(void *opaque,
         return 0;
     }
     if (g_str_equal(qom_name, "igd-passthru")) {
-        object_register_sugar_prop(ACCEL_CLASS_NAME("xen"), qom_name, value);
+        object_register_sugar_prop(ACCEL_CLASS_NAME("xen"), qom_name, value,
+                                   false);
         return 0;
     }
     if (g_str_equal(qom_name, "kvm-shadow-mem")) {
-        object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value);
+        object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value,
+                                   false);
         return 0;
     }
     if (g_str_equal(qom_name, "kernel-irqchip")) {
-        object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value);
-        object_register_sugar_prop(ACCEL_CLASS_NAME("whpx"), qom_name, value);
+        object_register_sugar_prop(ACCEL_CLASS_NAME("kvm"), qom_name, value,
+                                   false);
+        object_register_sugar_prop(ACCEL_CLASS_NAME("whpx"), qom_name, value,
+                                   false);
         return 0;
     }
 
@@ -2297,9 +2301,10 @@ static void qemu_process_sugar_options(void)
 
         val = g_strdup_printf("%d",
                  (uint32_t) qemu_opt_get_number(qemu_find_opts_singleton("smp-opts"), "cpus", 1));
-        object_register_sugar_prop("memory-backend", "prealloc-threads", val);
+        object_register_sugar_prop("memory-backend", "prealloc-threads", val,
+                                   false);
         g_free(val);
-        object_register_sugar_prop("memory-backend", "prealloc", "on");
+        object_register_sugar_prop("memory-backend", "prealloc", "on", false);
     }
 
     if (watchdog) {
-- 
2.29.2

[PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class

[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's MKTME can do
similar things.  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
ConfidentialGuestSupport QOM base class.  "Confidential" is kind of vague,
but "confidential computing" seems to be the buzzword about these schemes,
and "secure" or "protected" are often used in connection to unrelated
things (such as hypervisor-from-guest or guest-from-guest security).

The "support" in the name is significant because in at least some of the
cases it requires the guest to take specific actions in order to protect
itself from hypervisor eavesdropping.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 backends/confidential-guest-support.c     | 33 ++++++++++++++++++++
 backends/meson.build                      |  1 +
 include/exec/confidential-guest-support.h | 38 +++++++++++++++++++++++
 include/qemu/typedefs.h                   |  1 +
 target/i386/sev.c                         |  3 +-
 5 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 backends/confidential-guest-support.c
 create mode 100644 include/exec/confidential-guest-support.h

diff --git a/backends/confidential-guest-support.c b/backends/confidential-guest-support.c
new file mode 100644
index 0000000000..9b0ded0db4
--- /dev/null
+++ b/backends/confidential-guest-support.c
@@ -0,0 +1,33 @@
+/*
+ * QEMU Confidential Guest support
+ *
+ * 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/confidential-guest-support.h"
+
+OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
+                            confidential_guest_support,
+                            CONFIDENTIAL_GUEST_SUPPORT,
+                            OBJECT)
+
+static void confidential_guest_support_class_init(ObjectClass *oc, void *data)
+{
+}
+
+static void confidential_guest_support_init(Object *obj)
+{
+}
+
+static void confidential_guest_support_finalize(Object *obj)
+{
+}
diff --git a/backends/meson.build b/backends/meson.build
index 484456ece7..d4221831fc 100644
--- a/backends/meson.build
+++ b/backends/meson.build
@@ -6,6 +6,7 @@ softmmu_ss.add([files(
   'rng-builtin.c',
   'rng-egd.c',
   'rng.c',
+  'confidential-guest-support.c',
 ), numa])
 
 softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
new file mode 100644
index 0000000000..5f131023ba
--- /dev/null
+++ b/include/exec/confidential-guest-support.h
@@ -0,0 +1,38 @@
+/*
+ * QEMU Confidential Guest support
+ *   This interface describes the common pieces between various
+ *   schemes for protecting guest memory or other state against a
+ *   compromised hypervisor.  This includes memory encryption (AMD's
+ *   SEV and Intel's MKTME) or special protection modes (PEF on POWER,
+ *   or PV on s390x).
+ *
+ * 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_CONFIDENTIAL_GUEST_SUPPORT_H
+#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
+
+#ifndef CONFIG_USER_ONLY
+
+#include "qom/object.h"
+
+#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
+OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
+
+struct ConfidentialGuestSupport {
+    Object parent;
+};
+
+typedef struct ConfidentialGuestSupportClass {
+    ObjectClass parent;
+} ConfidentialGuestSupportClass;
+
+#endif /* !CONFIG_USER_ONLY */
+
+#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 976b529dfb..33685c79ed 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -36,6 +36,7 @@ typedef struct BusState BusState;
 typedef struct Chardev Chardev;
 typedef struct CompatProperty CompatProperty;
 typedef struct CoMutex CoMutex;
+typedef struct ConfidentialGuestSupport ConfidentialGuestSupport;
 typedef struct CPUAddressSpace CPUAddressSpace;
 typedef struct CPUState CPUState;
 typedef struct DeviceListener DeviceListener;
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 1546606811..6b49925f51 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -31,6 +31,7 @@
 #include "qom/object.h"
 #include "exec/address-spaces.h"
 #include "monitor/monitor.h"
+#include "exec/confidential-guest-support.h"
 
 #define TYPE_SEV_GUEST "sev-guest"
 OBJECT_DECLARE_SIMPLE_TYPE(SevGuestState, SEV_GUEST)
@@ -322,7 +323,7 @@ sev_guest_instance_init(Object *obj)
 
 /* sev guest info */
 static const TypeInfo sev_guest_info = {
-    .parent = TYPE_OBJECT,
+    .parent = TYPE_CONFIDENTIAL_GUEST_SUPPORT,
     .name = TYPE_SEV_GUEST,
     .instance_size = sizeof(SevGuestState),
     .instance_finalize = sev_guest_finalize,
-- 
2.29.2

[PATCH v7 03/13] sev: Remove false abstraction of flash encryption

[David Gibson]

When AMD's SEV memory encryption is in use, flash memory banks (which are
initialed by pc_system_flash_map()) need to be encrypted with the guest's
key, so that the guest can read them.

That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM
state.. except, that it doesn't really abstract much at all.

For starters, the only called is in code specific to the 'pc' family of
machine types, so it's obviously specific to those and to x86 to begin
with.  But it makes a bunch of further assumptions that need not be true
about an arbitrary confidential guest system based on memory encryption,
let alone one based on other mechanisms:

 * it assumes that the flash memory is defined to be encrypted with the
   guest key, rather than being shared with hypervisor
 * it assumes that that hypervisor has some mechanism to encrypt data into
   the guest, even though it can't decrypt it out, since that's the whole
   point
 * the interface assumes that this encrypt can be done in place, which
   implies that the hypervisor can write into a confidential guests's
   memory, even if what it writes isn't meaningful

So really, this "abstraction" is actually pretty specific to the way SEV
works.  So, this patch removes it and instead has the PC flash
initialization code call into a SEV specific callback.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 accel/kvm/kvm-all.c    | 31 ++-----------------------------
 accel/kvm/sev-stub.c   |  9 ++-------
 accel/stubs/kvm-stub.c | 10 ----------
 hw/i386/pc_sysfw.c     | 17 ++++++-----------
 include/sysemu/kvm.h   | 16 ----------------
 include/sysemu/sev.h   |  4 ++--
 target/i386/sev-stub.c |  5 +++++
 target/i386/sev.c      | 24 ++++++++++++++----------
 8 files changed, 31 insertions(+), 85 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 389eaace72..260ed73ffe 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -120,10 +120,6 @@ 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);
-
     /* For "info mtree -f" to tell if an MR is registered in KVM */
     int nr_as;
     struct KVMAs {
@@ -222,26 +218,6 @@ int kvm_get_max_memslots(void)
     return s->nr_slots;
 }
 
-bool kvm_memcrypt_enabled(void)
-{
-    if (kvm_state && kvm_state->memcrypt_handle) {
-        return true;
-    }
-
-    return false;
-}
-
-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);
-    }
-
-    return 1;
-}
-
 /* Called with KVMMemoryListener.slots_lock held */
 static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
 {
@@ -2206,13 +2182,10 @@ 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) {
-            ret = -1;
+        ret = sev_guest_init(ms->memory_encryption);
+        if (ret < 0) {
             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..5db9ab8f00 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)
+int sev_guest_init(const char *id)
 {
-    abort();
-}
-
-void *sev_guest_init(const char *id)
-{
-    return NULL;
+    return -1;
 }
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 680e099463..0f17acfac0 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -81,16 +81,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 92e90ff013..11172214f1 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 "sysemu/sev.h"
 
 #define FLASH_SECTOR_SIZE 4096
 
@@ -147,7 +148,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
     PFlashCFI01 *system_flash;
     MemoryRegion *flash_mem;
     void *flash_ptr;
-    int ret, flash_size;
+    int flash_size;
 
     assert(PC_MACHINE_GET_CLASS(pcms)->pci_enabled);
 
@@ -191,16 +192,10 @@ static void pc_system_flash_map(PCMachineState *pcms,
             flash_mem = pflash_cfi01_get_memory(system_flash);
             pc_isa_bios_init(rom_memory, flash_mem, size);
 
-            /* Encrypt the pflash boot ROM */
-            if (kvm_memcrypt_enabled()) {
-                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);
-                if (ret) {
-                    error_report("failed to encrypt pflash rom");
-                    exit(1);
-                }
-            }
+            /* Encrypt the pflash boot ROM, if necessary */
+            flash_ptr = memory_region_get_ram_ptr(flash_mem);
+            flash_size = memory_region_size(flash_mem);
+            sev_encrypt_flash(flash_ptr, flash_size, &error_fatal);
         }
     }
 }
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index bb5d5cf497..11cf0b875d 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -233,22 +233,6 @@ int kvm_has_intx_set_mask(void);
  */
 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"
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 7ab6e3e31d..7335e59867 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -16,8 +16,8 @@
 
 #include "sysemu/kvm.h"
 
-void *sev_guest_init(const char *id);
-int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+int sev_guest_init(const char *id);
+int sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp);
 int sev_inject_launch_secret(const char *hdr, const char *secret,
                              uint64_t gpa, Error **errp);
 #endif
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index c1fecc2101..1ac1fd5b94 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -54,3 +54,8 @@ int sev_inject_launch_secret(const char *hdr, const char *secret,
 {
     return 1;
 }
+
+int sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp)
+{
+    return 0;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 6b49925f51..2a4b2187d6 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -682,7 +682,7 @@ sev_vm_state_change(void *opaque, int running, RunState state)
     }
 }
 
-void *
+int
 sev_guest_init(const char *id)
 {
     SevGuestState *sev;
@@ -695,7 +695,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;
+        return -1;
     }
 
     sev = lookup_sev_guest_info(id);
@@ -766,23 +766,27 @@ 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)
+sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp)
 {
-    SevGuestState *sev = handle;
-
-    assert(sev);
+    if (!sev_guest) {
+        return 0;
+    }
 
     /* if SEV is in update state then encrypt the data else do nothing */
-    if (sev_check_state(sev, SEV_STATE_LAUNCH_UPDATE)) {
-        return sev_launch_update_data(sev, ptr, len);
+    if (sev_check_state(sev_guest, SEV_STATE_LAUNCH_UPDATE)) {
+        int ret = sev_launch_update_data(sev_guest, ptr, len);
+        if (ret < 0) {
+            error_setg(errp, "failed to encrypt pflash rom");
+            return ret;
+        }
     }
 
     return 0;
-- 
2.29.2

[PATCH v7 04/13] confidential guest support: Move side effect out of machine_set_memory_encryption()

[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>
Reviewed-by: Greg Kurz <groug@kaod.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 de3b8f1b31..8909117d80 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -437,14 +437,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)
@@ -1166,6 +1158,15 @@ void machine_run_board_init(MachineState *machine)
                     cc->deprecation_note);
     }
 
+    if (machine->memory_encryption) {
+        /*
+         * With memory encryption, 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);
     phase_advance(PHASE_MACHINE_INITIALIZED);
 }
-- 
2.29.2

[PATCH v7 05/13] confidential guest support: Rework the "memory-encryption" property

[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 "confidential-guest-support" 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: Greg Kurz <groug@kaod.org>
---
 accel/kvm/kvm-all.c  |  5 +++--
 accel/kvm/sev-stub.c |  5 +++--
 hw/core/machine.c    | 43 +++++++++++++++++++++++++++++++++++++------
 include/hw/boards.h  |  2 +-
 include/sysemu/sev.h |  2 +-
 target/i386/sev.c    | 32 ++------------------------------
 6 files changed, 47 insertions(+), 42 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 260ed73ffe..28ab126f70 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2181,8 +2181,9 @@ static int kvm_init(MachineState *ms)
      * if memory encryption object is specified then initialize the memory
      * encryption context.
      */
-    if (ms->memory_encryption) {
-        ret = sev_guest_init(ms->memory_encryption);
+    if (ms->cgs) {
+        /* FIXME handle mechanisms other than SEV */
+        ret = sev_kvm_init(ms->cgs);
         if (ret < 0) {
             goto err;
         }
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 5db9ab8f00..3d4787ae4a 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -15,7 +15,8 @@
 #include "qemu-common.h"
 #include "sysemu/sev.h"
 
-int sev_guest_init(const char *id)
+int sev_kvm_init(ConfidentialGuestSupport *cgs)
 {
-    return -1;
+    /* SEV can't be selected if it's not compiled */
+    g_assert_not_reached();
 }
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 8909117d80..94194ab82d 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -32,6 +32,7 @@
 #include "hw/mem/nvdimm.h"
 #include "migration/global_state.h"
 #include "migration/vmstate.h"
+#include "exec/confidential-guest-support.h"
 
 GlobalProperty hw_compat_5_2[] = {};
 const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
@@ -427,16 +428,37 @@ static char *machine_get_memory_encryption(Object *obj, Error **errp)
 {
     MachineState *ms = MACHINE(obj);
 
-    return g_strdup(ms->memory_encryption);
+    if (ms->cgs) {
+        return g_strdup(object_get_canonical_path_component(OBJECT(ms->cgs)));
+    }
+
+    return NULL;
 }
 
 static void machine_set_memory_encryption(Object *obj, const char *value,
                                         Error **errp)
 {
-    MachineState *ms = MACHINE(obj);
+    Object *cgs =
+        object_resolve_path_component(object_get_objects_root(), value);
+
+    if (!cgs) {
+        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, "confidential-guest-support", cgs, errp);
+}
+
+static void machine_check_confidential_guest_support(const Object *obj,
+                                                     const char *name,
+                                                     Object *new_target,
+                                                     Error **errp)
+{
+    /*
+     * So far the only constraint is that the target has the
+     * TYPE_CONFIDENTIAL_GUEST_SUPPORT interface, and that's checked
+     * by the QOM core
+     */
 }
 
 static bool machine_get_nvdimm(Object *obj, Error **errp)
@@ -836,6 +858,15 @@ static void machine_class_init(ObjectClass *oc, void *data)
     object_class_property_set_description(oc, "suppress-vmdesc",
         "Set on to disable self-describing migration");
 
+    object_class_property_add_link(oc, "confidential-guest-support",
+                                   TYPE_CONFIDENTIAL_GUEST_SUPPORT,
+                                   offsetof(MachineState, cgs),
+                                   machine_check_confidential_guest_support,
+                                   OBJ_PROP_LINK_STRONG);
+    object_class_property_set_description(oc, "confidential-guest-support",
+                                          "Set confidential guest scheme to support");
+
+    /* 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",
@@ -1158,9 +1189,9 @@ void machine_run_board_init(MachineState *machine)
                     cc->deprecation_note);
     }
 
-    if (machine->memory_encryption) {
+    if (machine->cgs) {
         /*
-         * With memory encryption, the host can't see the real
+         * With confidential guests, the host can't see the real
          * contents of RAM, so there's no point in it trying to merge
          * areas.
          */
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 17b1f3f0b9..1acd662fa5 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -270,7 +270,7 @@ struct MachineState {
     bool iommu;
     bool suppress_vmdesc;
     bool enable_graphics;
-    char *memory_encryption;
+    ConfidentialGuestSupport *cgs;
     char *ram_memdev_id;
     /*
      * convenience alias to ram_memdev_id backend memory region
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 7335e59867..3b5b1aacf1 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -16,7 +16,7 @@
 
 #include "sysemu/kvm.h"
 
-int sev_guest_init(const char *id);
+int sev_kvm_init(ConfidentialGuestSupport *cgs);
 int sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp);
 int sev_inject_launch_secret(const char *hdr, const char *secret,
                              uint64_t gpa, Error **errp);
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 2a4b2187d6..5399a136ad 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -335,26 +335,6 @@ static const TypeInfo sev_guest_info = {
     }
 };
 
-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)
 {
@@ -682,10 +662,9 @@ sev_vm_state_change(void *opaque, int running, RunState state)
     }
 }
 
-int
-sev_guest_init(const char *id)
+int sev_kvm_init(ConfidentialGuestSupport *cgs)
 {
-    SevGuestState *sev;
+    SevGuestState *sev = SEV_GUEST(cgs);
     char *devname;
     int ret, fw_error;
     uint32_t ebx;
@@ -698,13 +677,6 @@ sev_guest_init(const char *id)
         return -1;
     }
 
-    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;
-    }
-
     sev_guest = sev;
     sev->state = SEV_STATE_UNINIT;
 
-- 
2.29.2

[PATCH v7 06/13] sev: Add Error ** to sev_kvm_init()

[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>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---
 accel/kvm/kvm-all.c  |  4 +++-
 accel/kvm/sev-stub.c |  2 +-
 include/sysemu/sev.h |  2 +-
 target/i386/sev.c    | 31 +++++++++++++++----------------
 4 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 28ab126f70..c5b0750fd0 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2182,9 +2182,11 @@ static int kvm_init(MachineState *ms)
      * encryption context.
      */
     if (ms->cgs) {
+        Error *local_err = NULL;
         /* FIXME handle mechanisms other than SEV */
-        ret = sev_kvm_init(ms->cgs);
+        ret = sev_kvm_init(ms->cgs, &local_err);
         if (ret < 0) {
+            error_report_err(local_err);
             goto err;
         }
     }
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 3d4787ae4a..512e205f7f 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -15,7 +15,7 @@
 #include "qemu-common.h"
 #include "sysemu/sev.h"
 
-int sev_kvm_init(ConfidentialGuestSupport *cgs)
+int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
     /* SEV can't be selected if it's not compiled */
     g_assert_not_reached();
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 3b5b1aacf1..5c5a13c6ca 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -16,7 +16,7 @@
 
 #include "sysemu/kvm.h"
 
-int sev_kvm_init(ConfidentialGuestSupport *cgs);
+int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp);
 int sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp);
 int sev_inject_launch_secret(const char *hdr, const char *secret,
                              uint64_t gpa, Error **errp);
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 5399a136ad..e2b41ef342 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -662,7 +662,7 @@ sev_vm_state_change(void *opaque, int running, RunState state)
     }
 }
 
-int sev_kvm_init(ConfidentialGuestSupport *cgs)
+int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
     SevGuestState *sev = SEV_GUEST(cgs);
     char *devname;
@@ -684,14 +684,14 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs)
     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;
     }
 
@@ -700,20 +700,19 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs)
     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;
@@ -723,14 +722,14 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs)
     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.29.2

[PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag

[David Gibson]

The platform specific details of mechanisms for implementing
confidential guest support may require setup at various points during
initialization.  Thus, it's not really feasible to have a single cgs
initialization hook, but instead each mechanism needs its own
initialization calls in arch or machine specific code.

However, to make it harder to have a bug where a mechanism isn't
properly initialized under some circumstances, we want to have a
common place, relatively late in boot, where we verify that cgs has
been initialized if it was requested.

This patch introduces a ready flag to the ConfidentialGuestSupport
base type to accomplish this, which we verify just before the machine
specific initialization function.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/core/machine.c                         | 8 ++++++++
 include/exec/confidential-guest-support.h | 2 ++
 target/i386/sev.c                         | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 94194ab82d..5a7433332b 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -1190,6 +1190,14 @@ void machine_run_board_init(MachineState *machine)
     }
 
     if (machine->cgs) {
+        /*
+         * Where confidential guest support is initialized depends on
+         * the specific mechanism in use.  But, we need to make sure
+         * it's ready by now.  If it isn't, that's a bug in the
+         * implementation of that cgs mechanism.
+         */
+        assert(machine->cgs->ready);
+
         /*
          * With confidential guests, the host can't see the real
          * contents of RAM, so there's no point in it trying to merge
diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
index 5f131023ba..bcaf6c9f49 100644
--- a/include/exec/confidential-guest-support.h
+++ b/include/exec/confidential-guest-support.h
@@ -27,6 +27,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
 
 struct ConfidentialGuestSupport {
     Object parent;
+
+    bool ready;
 };
 
 typedef struct ConfidentialGuestSupportClass {
diff --git a/target/i386/sev.c b/target/i386/sev.c
index e2b41ef342..3d94635397 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -737,6 +737,8 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
     qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
     qemu_add_vm_change_state_handler(sev_vm_state_change, sev);
 
+    cgs->ready = true;
+
     return 0;
 err:
     sev_guest = NULL;
-- 
2.29.2

[PATCH v7 08/13] confidential guest support: Move SEV initialization into arch specific code

[David Gibson]

While we've abstracted some (potential) differences between mechanisms for
securing guest memory, the initialization is still specific to SEV.  Given
that, move it into x86's kvm_arch_init() code, rather than the generic
kvm_init() code.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 accel/kvm/kvm-all.c   | 14 --------------
 accel/kvm/sev-stub.c  |  4 ++--
 target/i386/kvm/kvm.c | 12 ++++++++++++
 target/i386/sev.c     |  7 ++++++-
 4 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index c5b0750fd0..adf27c1864 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2177,20 +2177,6 @@ static int kvm_init(MachineState *ms)
 
     kvm_state = s;
 
-    /*
-     * if memory encryption object is specified then initialize the memory
-     * encryption context.
-     */
-    if (ms->cgs) {
-        Error *local_err = NULL;
-        /* FIXME handle mechanisms other than SEV */
-        ret = sev_kvm_init(ms->cgs, &local_err);
-        if (ret < 0) {
-            error_report_err(local_err);
-            goto err;
-        }
-    }
-
     ret = kvm_arch_init(ms, s);
     if (ret < 0) {
         goto err;
diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
index 512e205f7f..9587d1b2a3 100644
--- a/accel/kvm/sev-stub.c
+++ b/accel/kvm/sev-stub.c
@@ -17,6 +17,6 @@
 
 int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
-    /* SEV can't be selected if it's not compiled */
-    g_assert_not_reached();
+    /* If we get here, cgs must be some non-SEV thing */
+    return 0;
 }
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 6dc1ee052d..e8b9dc48a2 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -42,6 +42,7 @@
 #include "hw/i386/intel_iommu.h"
 #include "hw/i386/x86-iommu.h"
 #include "hw/i386/e820_memory_layout.h"
+#include "sysemu/sev.h"
 
 #include "hw/pci/pci.h"
 #include "hw/pci/msi.h"
@@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
     uint64_t shadow_mem;
     int ret;
     struct utsname utsname;
+    Error *local_err = NULL;
+
+    /*
+     * if memory encryption object is specified then initialize the
+     * memory encryption context (no-op otherwise)
+     */
+    ret = sev_kvm_init(ms->cgs, &local_err);
+    if (ret < 0) {
+        error_report_err(local_err);
+        return ret;
+    }
 
     if (!kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) {
         error_report("kvm: KVM_CAP_IRQ_ROUTING not supported by KVM");
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 3d94635397..aa79cacabe 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -664,13 +664,18 @@ sev_vm_state_change(void *opaque, int running, RunState state)
 
 int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
 {
-    SevGuestState *sev = SEV_GUEST(cgs);
+    SevGuestState *sev
+        = (SevGuestState *)object_dynamic_cast(OBJECT(cgs), TYPE_SEV_GUEST);
     char *devname;
     int ret, fw_error;
     uint32_t ebx;
     uint32_t host_cbitpos;
     struct sev_user_data_status status = {};
 
+    if (!sev) {
+        return 0;
+    }
+
     ret = ram_block_discard_disable(true);
     if (ret) {
         error_report("%s: cannot disable RAM discard", __func__);
-- 
2.29.2

[PATCH v7 09/13] confidential guest support: Update documentation

[David Gibson]

Now that we've implemented a generic machine option for configuring various
confidential guest support mechanisms:
  1. Update docs/amd-memory-encryption.txt to reference this rather than
     the earlier SEV specific option
  2. Add a docs/confidential-guest-support.txt to cover the generalities of
     the confidential guest support scheme

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 docs/amd-memory-encryption.txt      |  2 +-
 docs/confidential-guest-support.txt | 43 +++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 docs/confidential-guest-support.txt

diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index 80b8eb00e9..145896aec7 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryption.txt
@@ -73,7 +73,7 @@ complete flow chart.
 To launch a SEV guest
 
 # ${QEMU} \
-    -machine ...,memory-encryption=sev0 \
+    -machine ...,confidential-guest-support=sev0 \
     -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
 
 Debugging
diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
new file mode 100644
index 0000000000..2790425b38
--- /dev/null
+++ b/docs/confidential-guest-support.txt
@@ -0,0 +1,43 @@
+Confidential Guest Support
+==========================
+
+Traditionally, hypervisors such as qemu have complete access to a
+guest's memory and other state, meaning that a compromised hypervisor
+can compromise any of its guests.  A number of platforms have added
+mechanisms in hardware and/or firmware which give guests at least some
+protection from a compromised hypervisor.  This is obviously
+especially desirable for public cloud environments.
+
+These mechanisms have different names and different modes of
+operation, but are often referred to as Secure Guests or Confidential
+Guests.  We use the term "Confidential Guest Support" to distinguish
+this from other aspects of guest security (such as security against
+attacks from other guests, or from network sources).
+
+Running a Confidential Guest
+----------------------------
+
+To run a confidential guest you need to add two command line parameters:
+
+1. Use "-object" to create a "confidential guest support" object.  The
+   type and parameters will vary with the specific mechanism to be
+   used
+2. Set the "confidential-guest-support" machine parameter to the ID of
+   the object from (1).
+
+Example (for AMD SEV)::
+
+    qemu-system-x86_64 \
+        <other parameters> \
+        -machine ...,confidential-guest-support=sev0 \
+        -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
+
+Supported mechanisms
+--------------------
+
+Currently supported confidential guest mechanisms are:
+
+AMD Secure Encrypted Virtualization (SEV)
+    docs/amd-memory-encryption.txt
+
+Other mechanisms may be supported in future.
-- 
2.29.2

[PATCH v7 10/13] spapr: Add PEF based confidential guest support

[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 confidential-guest-support
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 directl 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 confidential-guest-support=pef0

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 docs/confidential-guest-support.txt |   3 +
 docs/papr-pef.txt                   |  30 +++++++
 hw/ppc/meson.build                  |   1 +
 hw/ppc/pef.c                        | 119 ++++++++++++++++++++++++++++
 hw/ppc/spapr.c                      |   6 ++
 include/hw/ppc/pef.h                |  25 ++++++
 target/ppc/kvm.c                    |  18 -----
 target/ppc/kvm_ppc.h                |   6 --
 8 files changed, 184 insertions(+), 24 deletions(-)
 create mode 100644 docs/papr-pef.txt
 create mode 100644 hw/ppc/pef.c
 create mode 100644 include/hw/ppc/pef.h

diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
index 2790425b38..f0801814ff 100644
--- a/docs/confidential-guest-support.txt
+++ b/docs/confidential-guest-support.txt
@@ -40,4 +40,7 @@ Currently supported confidential guest mechanisms are:
 AMD Secure Encrypted Virtualization (SEV)
     docs/amd-memory-encryption.txt
 
+POWER Protected Execution Facility (PEF)
+    docs/papr-pef.txt
+
 Other mechanisms may be supported in future.
diff --git a/docs/papr-pef.txt b/docs/papr-pef.txt
new file mode 100644
index 0000000000..6419e995cf
--- /dev/null
+++ b/docs/papr-pef.txt
@@ -0,0 +1,30 @@
+POWER (PAPR) Protected Execution Facility (PEF)
+===============================================
+
+Protected Execution Facility (PEF), also known as Secure Guest support
+is a feature found on IBM POWER9 and POWER10 processors.
+
+If a suitable firmware including an Ultravisor is installed, it adds
+an extra memory protection mode to the CPU.  The ultravisor manages a
+pool of secure memory which cannot be accessed by the hypervisor.
+
+When this feature is enabled in qemu, a guest can use ultracalls to
+enter "secure mode".  This transfers most of its memory to secure
+memory, where it cannot be eavesdropped by a compromised hypervisor.
+
+Launching
+---------
+
+To launch a guest which will be permitted to enter PEF secure mode:
+
+# ${QEMU} \
+    -object pef-guest,id=pef0 \
+    -machine confidential-guest-support=pef0 \
+    ...
+
+Live Migration
+----------------
+
+Live migration is not yet implemented for PEF guests.  For
+consistency, we currently prevent migration if the PEF feature is
+enabled, whether or not the guest has actually entered secure mode.
diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
index ffa2ec37fa..218631c883 100644
--- a/hw/ppc/meson.build
+++ b/hw/ppc/meson.build
@@ -27,6 +27,7 @@ ppc_ss.add(when: 'CONFIG_PSERIES', if_true: files(
   'spapr_nvdimm.c',
   'spapr_rtas_ddw.c',
   'spapr_numa.c',
+  'pef.c',
 ))
 ppc_ss.add(when: 'CONFIG_SPAPR_RNG', if_true: files('spapr_rng.c'))
 ppc_ss.add(when: ['CONFIG_PSERIES', 'CONFIG_LINUX'], if_true: files(
diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c
new file mode 100644
index 0000000000..02b9b3b460
--- /dev/null
+++ b/hw/ppc/pef.c
@@ -0,0 +1,119 @@
+/*
+ * 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/confidential-guest-support.h"
+#include "hw/ppc/pef.h"
+
+#define TYPE_PEF_GUEST "pef-guest"
+OBJECT_DECLARE_SIMPLE_TYPE(PefGuest, PEF_GUEST)
+
+typedef struct PefGuest PefGuest;
+typedef struct PefGuestClass PefGuestClass;
+
+struct PefGuestClass {
+    ConfidentialGuestSupportClass parent_class;
+};
+
+/**
+ * PefGuest:
+ *
+ * The PefGuest object is used for creating and managing a PEF
+ * guest.
+ *
+ * # $QEMU \
+ *         -object pef-guest,id=pef0 \
+ *         -machine ...,confidential-guest-support=pef0
+ */
+struct PefGuest {
+    ConfidentialGuestSupport parent_obj;
+};
+
+#ifdef CONFIG_KVM
+static int kvmppc_svm_init(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;
+}
+
+/*
+ * Don't set error if KVM_PPC_SVM_OFF ioctl is invoked on kernels
+ * that don't support this ioctl.
+ */
+void kvmppc_svm_off(Error **errp)
+{
+    int rc;
+
+    if (!kvm_enabled()) {
+        return;
+    }
+
+    rc = kvm_vm_ioctl(KVM_STATE(current_accel()), KVM_PPC_SVM_OFF);
+    if (rc && rc != -ENOTTY) {
+        error_setg_errno(errp, -rc, "KVM_PPC_SVM_OFF ioctl failed");
+    }
+}
+#else
+static int kvmppc_svm_init(Error **errp)
+{
+    g_assert_not_reached();
+}
+#endif
+
+int pef_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
+{
+    if (!object_dynamic_cast(OBJECT(cgs), TYPE_PEF_GUEST)) {
+        return 0;
+    }
+
+    if (!kvm_enabled()) {
+        error_setg(errp, "PEF requires KVM");
+        return -1;
+    }
+
+    return kvmppc_svm_init(errp);
+}
+
+OBJECT_DEFINE_TYPE_WITH_INTERFACES(PefGuest,
+                                   pef_guest,
+                                   PEF_GUEST,
+                                   CONFIDENTIAL_GUEST_SUPPORT,
+                                   { TYPE_USER_CREATABLE },
+                                   { NULL })
+
+static void pef_guest_class_init(ObjectClass *oc, void *data)
+{
+}
+
+static void pef_guest_init(Object *obj)
+{
+}
+
+static void pef_guest_finalize(Object *obj)
+{
+}
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 2c403b574e..accf7a834b 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -83,6 +83,7 @@
 #include "hw/ppc/spapr_tpm_proxy.h"
 #include "hw/ppc/spapr_nvdimm.h"
 #include "hw/ppc/spapr_numa.h"
+#include "hw/ppc/pef.h"
 
 #include "monitor/monitor.h"
 
@@ -2658,6 +2659,11 @@ static void spapr_machine_init(MachineState *machine)
     char *filename;
     Error *resize_hpt_err = NULL;
 
+    /*
+     * if Secure VM (PEF) support is configured, then initialize it
+     */
+    pef_kvm_init(machine->cgs, &error_fatal);
+
     msi_nonbroken = true;
 
     QLIST_INIT(&spapr->phbs);
diff --git a/include/hw/ppc/pef.h b/include/hw/ppc/pef.h
new file mode 100644
index 0000000000..57d4ec9fe6
--- /dev/null
+++ b/include/hw/ppc/pef.h
@@ -0,0 +1,25 @@
+/*
+ * 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.
+ *
+ */
+
+#ifndef HW_PPC_PEF_H
+#define HW_PPC_PEF_H
+
+int pef_kvm_init(ConfidentialGuestSupport *cgs, Error **errp);
+
+#ifdef CONFIG_KVM
+void kvmppc_svm_off(Error **errp);
+#else
+static inline void kvmppc_svm_off(Error **errp)
+{
+}
+#endif
+
+
+#endif /* HW_PPC_PEF_H */
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index daf690a678..0c5056dd5b 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2929,21 +2929,3 @@ void kvmppc_set_reg_tb_offset(PowerPCCPU *cpu, int64_t tb_offset)
         kvm_set_one_reg(cs, KVM_REG_PPC_TB_OFFSET, &tb_offset);
     }
 }
-
-/*
- * Don't set error if KVM_PPC_SVM_OFF ioctl is invoked on kernels
- * that don't support this ioctl.
- */
-void kvmppc_svm_off(Error **errp)
-{
-    int rc;
-
-    if (!kvm_enabled()) {
-        return;
-    }
-
-    rc = kvm_vm_ioctl(KVM_STATE(current_accel()), KVM_PPC_SVM_OFF);
-    if (rc && rc != -ENOTTY) {
-        error_setg_errno(errp, -rc, "KVM_PPC_SVM_OFF ioctl failed");
-    }
-}
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index 73ce2bc951..989f61ace0 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -39,7 +39,6 @@ int kvmppc_booke_watchdog_enable(PowerPCCPU *cpu);
 target_ulong kvmppc_configure_v3_mmu(PowerPCCPU *cpu,
                                      bool radix, bool gtse,
                                      uint64_t proc_tbl);
-void kvmppc_svm_off(Error **errp);
 #ifndef CONFIG_USER_ONLY
 bool kvmppc_spapr_use_multitce(void);
 int kvmppc_spapr_enable_inkernel_multitce(void);
@@ -216,11 +215,6 @@ static inline target_ulong kvmppc_configure_v3_mmu(PowerPCCPU *cpu,
     return 0;
 }
 
-static inline void kvmppc_svm_off(Error **errp)
-{
-    return;
-}
-
 static inline void kvmppc_set_reg_ppc_online(PowerPCCPU *cpu,
                                              unsigned int online)
 {
-- 
2.29.2

[PATCH v7 11/13] spapr: PEF: prevent migration

[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>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
---
 hw/ppc/pef.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c
index 02b9b3b460..d7a49ef337 100644
--- a/hw/ppc/pef.c
+++ b/hw/ppc/pef.c
@@ -42,6 +42,8 @@ struct PefGuest {
 };
 
 #ifdef CONFIG_KVM
+static Error *pef_mig_blocker;
+
 static int kvmppc_svm_init(Error **errp)
 {
     if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURE_GUEST)) {
@@ -58,6 +60,11 @@ static int kvmppc_svm_init(Error **errp)
         }
     }
 
+    /* add migration blocker */
+    error_setg(&pef_mig_blocker, "PEF: Migration is not implemented");
+    /* NB: This can fail if --only-migratable is used */
+    migrate_add_blocker(pef_mig_blocker, &error_fatal);
+
     return 0;
 }
 
-- 
2.29.2

[PATCH v7 12/13] confidential guest support: Alter virtio default properties for protected guests

[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 confidential guest 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>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
---
 hw/core/machine.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 5a7433332b..61ae363559 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -33,6 +33,8 @@
 #include "migration/global_state.h"
 #include "migration/vmstate.h"
 #include "exec/confidential-guest-support.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-pci.h"
 
 GlobalProperty hw_compat_5_2[] = {};
 const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
@@ -1204,6 +1206,17 @@ 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 also disabling legacy virtio
+         * support for those virtio pci devices which allow it.
+         */
+        object_register_sugar_prop(TYPE_VIRTIO_PCI, "disable-legacy",
+                                   "on", true);
+        object_register_sugar_prop(TYPE_VIRTIO_DEVICE, "iommu_platform",
+                                   "on", false);
     }
 
     machine_class->init(machine);
-- 
2.29.2

[PATCH v7 13/13] s390: Recognize confidential-guest-support option

[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 by the "confidential-guest-support"
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 confidential-guest-support 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 confidential-guest-support
   is set, we will either create a guest capable of entering PV mode,
   or fail outright.

 - If confidential-guest-support is not set, guests 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 confidential-guest-support=pv0

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 docs/confidential-guest-support.txt |  3 ++
 docs/system/s390x/protvirt.rst      | 19 ++++++---
 hw/s390x/pv.c                       | 62 +++++++++++++++++++++++++++++
 include/hw/s390x/pv.h               |  1 +
 target/s390x/kvm.c                  |  3 ++
 5 files changed, 82 insertions(+), 6 deletions(-)

diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
index f0801814ff..50b976a082 100644
--- a/docs/confidential-guest-support.txt
+++ b/docs/confidential-guest-support.txt
@@ -43,4 +43,7 @@ AMD Secure Encrypted Virtualization (SEV)
 POWER Protected Execution Facility (PEF)
     docs/papr-pef.txt
 
+s390x Protected Virtualization (PV)
+    docs/system/s390x/protvirt.rst
+
 Other mechanisms may be supported in future.
diff --git a/docs/system/s390x/protvirt.rst b/docs/system/s390x/protvirt.rst
index 712974ad87..0f481043d9 100644
--- a/docs/system/s390x/protvirt.rst
+++ b/docs/system/s390x/protvirt.rst
@@ -22,15 +22,22 @@ If those requirements are met, the capability `KVM_CAP_S390_PROTECTED`
 will indicate that KVM can support PVMs on that LPAR.
 
 
-QEMU Settings
--------------
+Running a Protected Virtual Machine
+-----------------------------------
 
-To indicate to the VM that it can transition into protected mode, the
+To run a PVM you will need to select a CPU model which includes the
 `Unpack facility` (stfle bit 161 represented by the feature
-`unpack`/`S390_FEAT_UNPACK`) needs to be part of the cpu model of
-the VM.
+`unpack`/`S390_FEAT_UNPACK`), and add these options to the command line::
+
+    -object s390-pv-guest,id=pv0 \
+    -machine confidential-guest-support=pv0
+
+Adding these options will:
+
+* Ensure the `unpack` facility is available
+* Enable the IOMMU by default for all I/O devices
+* Initialize the PV mechanism
 
-All I/O devices need to use the IOMMU.
 Passthrough (vfio) devices are currently not supported.
 
 Host huge page backings are not supported. However guests can use huge
diff --git a/hw/s390x/pv.c b/hw/s390x/pv.c
index ab3a2482aa..319d74dfcf 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/confidential-guest-support.h"
 #include "hw/s390x/ipl.h"
 #include "hw/s390x/pv.h"
 
@@ -111,3 +114,62 @@ 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"
+OBJECT_DECLARE_SIMPLE_TYPE(S390PVGuest, S390_PV_GUEST)
+
+/**
+ * S390PVGuest:
+ *
+ * The S390PVGuest object is basically a dummy used to tell the
+ * confidential guest support system to use s390's PV mechanism.
+ *
+ * # $QEMU \
+ *         -object s390-pv-guest,id=pv0 \
+ *         -machine ...,confidential-guest-support=pv0
+ */
+struct S390PVGuest {
+    ConfidentialGuestSupport parent_obj;
+};
+
+typedef struct S390PVGuestClass S390PVGuestClass;
+
+struct S390PVGuestClass {
+    ConfidentialGuestSupportClass parent_class;
+};
+
+int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
+{
+    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
+        return 0;
+    }
+
+    if (!s390_has_feat(S390_FEAT_UNPACK)) {
+        error_setg(errp,
+                   "CPU model does not support Protected Virtualization");
+        return -1;
+    }
+
+    cgs->ready = true;
+
+    return 0;
+}
+
+OBJECT_DEFINE_TYPE_WITH_INTERFACES(S390PVGuest,
+                                   s390_pv_guest,
+                                   S390_PV_GUEST,
+                                   CONFIDENTIAL_GUEST_SUPPORT,
+                                   { TYPE_USER_CREATABLE },
+                                   { NULL })
+
+static void s390_pv_guest_class_init(ObjectClass *oc, void *data)
+{
+}
+
+static void s390_pv_guest_init(Object *obj)
+{
+}
+
+static void s390_pv_guest_finalize(Object *obj)
+{
+}
diff --git a/include/hw/s390x/pv.h b/include/hw/s390x/pv.h
index aee758bc2d..9bbf66f356 100644
--- a/include/hw/s390x/pv.h
+++ b/include/hw/s390x/pv.h
@@ -43,6 +43,7 @@ void s390_pv_prep_reset(void);
 int s390_pv_verify(void);
 void s390_pv_unshare(void);
 void s390_pv_inject_reset_error(CPUState *cs);
+int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp);
 #else /* CONFIG_KVM */
 static inline bool s390_is_pv(void) { return false; }
 static inline int s390_pv_vm_enable(void) { return 0; }
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index b8385e6b95..d2435664dc 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -387,6 +387,9 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
     }
 
     kvm_set_max_memslot_size(KVM_SLOT_MAX_BYTES);
+
+    s390_pv_init(ms->cgs, &error_fatal);
+
     return 0;
 }
 
-- 
2.29.2

Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag

[Greg Kurz]

On Thu, 14 Jan 2021 10:58:05 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> The platform specific details of mechanisms for implementing
> confidential guest support may require setup at various points during
> initialization.  Thus, it's not really feasible to have a single cgs
> initialization hook, but instead each mechanism needs its own
> initialization calls in arch or machine specific code.
> 
> However, to make it harder to have a bug where a mechanism isn't
> properly initialized under some circumstances, we want to have a
> common place, relatively late in boot, where we verify that cgs has
> been initialized if it was requested.
> 
> This patch introduces a ready flag to the ConfidentialGuestSupport
> base type to accomplish this, which we verify just before the machine
> specific initialization function.
> 

Since this is a strong requirement for any new cgs implementation, I
guess it could be advertised a bit more with some extra documentation
in the confidential-guest-support.h header file as well.

Anyway,

Reviewed-by: Greg Kurz <groug@kaod.org>


Unrelated. I've just spotted mdroth@linux.vnet.ibm.com in the Cc list
of this thread, but, as you know, Mike is now working on other topics
at AMD :)

> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  hw/core/machine.c                         | 8 ++++++++
>  include/exec/confidential-guest-support.h | 2 ++
>  target/i386/sev.c                         | 2 ++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 94194ab82d..5a7433332b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -1190,6 +1190,14 @@ void machine_run_board_init(MachineState *machine)
>      }
>  
>      if (machine->cgs) {
> +        /*
> +         * Where confidential guest support is initialized depends on
> +         * the specific mechanism in use.  But, we need to make sure
> +         * it's ready by now.  If it isn't, that's a bug in the
> +         * implementation of that cgs mechanism.
> +         */
> +        assert(machine->cgs->ready);
> +
>          /*
>           * With confidential guests, the host can't see the real
>           * contents of RAM, so there's no point in it trying to merge
> diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
> index 5f131023ba..bcaf6c9f49 100644
> --- a/include/exec/confidential-guest-support.h
> +++ b/include/exec/confidential-guest-support.h
> @@ -27,6 +27,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
>  
>  struct ConfidentialGuestSupport {
>      Object parent;
> +
> +    bool ready;
>  };
>  
>  typedef struct ConfidentialGuestSupportClass {
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index e2b41ef342..3d94635397 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -737,6 +737,8 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
>      qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
>      qemu_add_vm_change_state_handler(sev_vm_state_change, sev);
>  
> +    cgs->ready = true;
> +
>      return 0;
>  err:
>      sev_guest = NULL;

Re: [PATCH v7 13/13] s390: Recognize confidential-guest-support option

[Christian Borntraeger]

On 14.01.21 00:58, David Gibson wrote:
[...]
> +int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
> +{
> +    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
> +        return 0;
> +    }
> +
> +    if (!s390_has_feat(S390_FEAT_UNPACK)) {
> +        error_setg(errp,
> +                   "CPU model does not support Protected Virtualization");
> +        return -1;
> +    }

I am triggering this and I guess this is because the cpu model is not yet initialized at
this point in time.

Re: [PATCH v7 13/13] s390: Recognize confidential-guest-support option

[Christian Borntraeger]

On 14.01.21 10:10, Christian Borntraeger wrote:
> 
> 
> On 14.01.21 00:58, David Gibson wrote:
> [...]
>> +int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
>> +{
>> +    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
>> +        return 0;
>> +    }
>> +
>> +    if (!s390_has_feat(S390_FEAT_UNPACK)) {
>> +        error_setg(errp,
>> +                   "CPU model does not support Protected Virtualization");
>> +        return -1;
>> +    }
> 
> I am triggering this and I guess this is because the cpu model is not yet initialized at
> this point in time.
> 
When I remove the check, things seems to work though ( I can access virtio-blk devices without
specifying iommu for example)

Re: [PATCH v7 13/13] s390: Recognize confidential-guest-support option

[Christian Borntraeger]

On 14.01.21 10:19, Christian Borntraeger wrote:
> 
> 
> On 14.01.21 10:10, Christian Borntraeger wrote:
>>
>>
>> On 14.01.21 00:58, David Gibson wrote:
>> [...]
>>> +int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
>>> +{
>>> +    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
>>> +        return 0;
>>> +    }
>>> +
>>> +    if (!s390_has_feat(S390_FEAT_UNPACK)) {
>>> +        error_setg(errp,
>>> +                   "CPU model does not support Protected Virtualization");
>>> +        return -1;
>>> +    }
>>
>> I am triggering this and I guess this is because the cpu model is not yet initialized at
>> this point in time.
>>
> When I remove the check, things seems to work though ( I can access virtio-blk devices without
> specifying iommu for example)

Maybe we can turn things around and check in apply_cpu_model if the object exists but
unpack was not specified?

Re: [PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class

[Daniel P. Berrangé]

On Thu, Jan 14, 2021 at 10:58:00AM +1100, David Gibson wrote:
> 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's MKTME can do
> similar things.  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
> ConfidentialGuestSupport QOM base class.  "Confidential" is kind of vague,
> but "confidential computing" seems to be the buzzword about these schemes,
> and "secure" or "protected" are often used in connection to unrelated
> things (such as hypervisor-from-guest or guest-from-guest security).
> 
> The "support" in the name is significant because in at least some of the
> cases it requires the guest to take specific actions in order to protect
> itself from hypervisor eavesdropping.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  backends/confidential-guest-support.c     | 33 ++++++++++++++++++++
>  backends/meson.build                      |  1 +
>  include/exec/confidential-guest-support.h | 38 +++++++++++++++++++++++
>  include/qemu/typedefs.h                   |  1 +
>  target/i386/sev.c                         |  3 +-
>  5 files changed, 75 insertions(+), 1 deletion(-)
>  create mode 100644 backends/confidential-guest-support.c
>  create mode 100644 include/exec/confidential-guest-support.h
> 
> diff --git a/backends/confidential-guest-support.c b/backends/confidential-guest-support.c
> new file mode 100644
> index 0000000000..9b0ded0db4
> --- /dev/null
> +++ b/backends/confidential-guest-support.c
> @@ -0,0 +1,33 @@
> +/*
> + * QEMU Confidential Guest support
> + *
> + * 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/confidential-guest-support.h"
> +
> +OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
> +                            confidential_guest_support,
> +                            CONFIDENTIAL_GUEST_SUPPORT,
> +                            OBJECT)
> +
> +static void confidential_guest_support_class_init(ObjectClass *oc, void *data)
> +{
> +}
> +
> +static void confidential_guest_support_init(Object *obj)
> +{
> +}
> +
> +static void confidential_guest_support_finalize(Object *obj)
> +{
> +}
> diff --git a/backends/meson.build b/backends/meson.build
> index 484456ece7..d4221831fc 100644
> --- a/backends/meson.build
> +++ b/backends/meson.build
> @@ -6,6 +6,7 @@ softmmu_ss.add([files(
>    'rng-builtin.c',
>    'rng-egd.c',
>    'rng.c',
> +  'confidential-guest-support.c',
>  ), numa])
>  
>  softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
> diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
> new file mode 100644
> index 0000000000..5f131023ba
> --- /dev/null
> +++ b/include/exec/confidential-guest-support.h
> @@ -0,0 +1,38 @@
> +/*
> + * QEMU Confidential Guest support
> + *   This interface describes the common pieces between various
> + *   schemes for protecting guest memory or other state against a
> + *   compromised hypervisor.  This includes memory encryption (AMD's
> + *   SEV and Intel's MKTME) or special protection modes (PEF on POWER,
> + *   or PV on s390x).
> + *
> + * 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_CONFIDENTIAL_GUEST_SUPPORT_H
> +#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
> +
> +#ifndef CONFIG_USER_ONLY
> +
> +#include "qom/object.h"
> +
> +#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
> +OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
> +
> +struct ConfidentialGuestSupport {
> +    Object parent;
> +};
> +
> +typedef struct ConfidentialGuestSupportClass {
> +    ObjectClass parent;
> +} ConfidentialGuestSupportClass;
> +
> +#endif /* !CONFIG_USER_ONLY */
> +
> +#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
> diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> index 976b529dfb..33685c79ed 100644
> --- a/include/qemu/typedefs.h
> +++ b/include/qemu/typedefs.h
> @@ -36,6 +36,7 @@ typedef struct BusState BusState;
>  typedef struct Chardev Chardev;
>  typedef struct CompatProperty CompatProperty;
>  typedef struct CoMutex CoMutex;
> +typedef struct ConfidentialGuestSupport ConfidentialGuestSupport;
>  typedef struct CPUAddressSpace CPUAddressSpace;
>  typedef struct CPUState CPUState;
>  typedef struct DeviceListener DeviceListener;
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 1546606811..6b49925f51 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -31,6 +31,7 @@
>  #include "qom/object.h"
>  #include "exec/address-spaces.h"
>  #include "monitor/monitor.h"
> +#include "exec/confidential-guest-support.h"
>  
>  #define TYPE_SEV_GUEST "sev-guest"
>  OBJECT_DECLARE_SIMPLE_TYPE(SevGuestState, SEV_GUEST)
> @@ -322,7 +323,7 @@ sev_guest_instance_init(Object *obj)
>  
>  /* sev guest info */
>  static const TypeInfo sev_guest_info = {
> -    .parent = TYPE_OBJECT,
> +    .parent = TYPE_CONFIDENTIAL_GUEST_SUPPORT,

If you're changing the parent QOM type, then you also need to change
the parent struct field type in SevguestState to match

>      .name = TYPE_SEV_GUEST,
>      .instance_size = sizeof(SevGuestState),
>      .instance_finalize = sev_guest_finalize,

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH v7 09/13] confidential guest support: Update documentation

[Greg Kurz]

On Thu, 14 Jan 2021 10:58:07 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> Now that we've implemented a generic machine option for configuring various
> confidential guest support mechanisms:
>   1. Update docs/amd-memory-encryption.txt to reference this rather than
>      the earlier SEV specific option
>   2. Add a docs/confidential-guest-support.txt to cover the generalities of
>      the confidential guest support scheme
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---

LGTM

Reviewed-by: Greg Kurz <groug@kaod.org>

>  docs/amd-memory-encryption.txt      |  2 +-
>  docs/confidential-guest-support.txt | 43 +++++++++++++++++++++++++++++
>  2 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 docs/confidential-guest-support.txt
> 
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index 80b8eb00e9..145896aec7 100644
> --- a/docs/amd-memory-encryption.txt
> +++ b/docs/amd-memory-encryption.txt
> @@ -73,7 +73,7 @@ complete flow chart.
>  To launch a SEV guest
>  
>  # ${QEMU} \
> -    -machine ...,memory-encryption=sev0 \
> +    -machine ...,confidential-guest-support=sev0 \
>      -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
>  
>  Debugging
> diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
> new file mode 100644
> index 0000000000..2790425b38
> --- /dev/null
> +++ b/docs/confidential-guest-support.txt
> @@ -0,0 +1,43 @@
> +Confidential Guest Support
> +==========================
> +
> +Traditionally, hypervisors such as qemu have complete access to a
> +guest's memory and other state, meaning that a compromised hypervisor
> +can compromise any of its guests.  A number of platforms have added
> +mechanisms in hardware and/or firmware which give guests at least some
> +protection from a compromised hypervisor.  This is obviously
> +especially desirable for public cloud environments.
> +
> +These mechanisms have different names and different modes of
> +operation, but are often referred to as Secure Guests or Confidential
> +Guests.  We use the term "Confidential Guest Support" to distinguish
> +this from other aspects of guest security (such as security against
> +attacks from other guests, or from network sources).
> +
> +Running a Confidential Guest
> +----------------------------
> +
> +To run a confidential guest you need to add two command line parameters:
> +
> +1. Use "-object" to create a "confidential guest support" object.  The
> +   type and parameters will vary with the specific mechanism to be
> +   used
> +2. Set the "confidential-guest-support" machine parameter to the ID of
> +   the object from (1).
> +
> +Example (for AMD SEV)::
> +
> +    qemu-system-x86_64 \
> +        <other parameters> \
> +        -machine ...,confidential-guest-support=sev0 \
> +        -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
> +
> +Supported mechanisms
> +--------------------
> +
> +Currently supported confidential guest mechanisms are:
> +
> +AMD Secure Encrypted Virtualization (SEV)
> +    docs/amd-memory-encryption.txt
> +
> +Other mechanisms may be supported in future.

Re: [PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class

[David Gibson]

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

On Thu, Jan 14, 2021 at 09:34:36AM +0000, Daniel P. Berrangé wrote:
> On Thu, Jan 14, 2021 at 10:58:00AM +1100, David Gibson wrote:
> > 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's MKTME can do
> > similar things.  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
> > ConfidentialGuestSupport QOM base class.  "Confidential" is kind of vague,
> > but "confidential computing" seems to be the buzzword about these schemes,
> > and "secure" or "protected" are often used in connection to unrelated
> > things (such as hypervisor-from-guest or guest-from-guest security).
> > 
> > The "support" in the name is significant because in at least some of the
> > cases it requires the guest to take specific actions in order to protect
> > itself from hypervisor eavesdropping.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  backends/confidential-guest-support.c     | 33 ++++++++++++++++++++
> >  backends/meson.build                      |  1 +
> >  include/exec/confidential-guest-support.h | 38 +++++++++++++++++++++++
> >  include/qemu/typedefs.h                   |  1 +
> >  target/i386/sev.c                         |  3 +-
> >  5 files changed, 75 insertions(+), 1 deletion(-)
> >  create mode 100644 backends/confidential-guest-support.c
> >  create mode 100644 include/exec/confidential-guest-support.h
> > 
> > diff --git a/backends/confidential-guest-support.c b/backends/confidential-guest-support.c
> > new file mode 100644
> > index 0000000000..9b0ded0db4
> > --- /dev/null
> > +++ b/backends/confidential-guest-support.c
> > @@ -0,0 +1,33 @@
> > +/*
> > + * QEMU Confidential Guest support
> > + *
> > + * 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/confidential-guest-support.h"
> > +
> > +OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
> > +                            confidential_guest_support,
> > +                            CONFIDENTIAL_GUEST_SUPPORT,
> > +                            OBJECT)
> > +
> > +static void confidential_guest_support_class_init(ObjectClass *oc, void *data)
> > +{
> > +}
> > +
> > +static void confidential_guest_support_init(Object *obj)
> > +{
> > +}
> > +
> > +static void confidential_guest_support_finalize(Object *obj)
> > +{
> > +}
> > diff --git a/backends/meson.build b/backends/meson.build
> > index 484456ece7..d4221831fc 100644
> > --- a/backends/meson.build
> > +++ b/backends/meson.build
> > @@ -6,6 +6,7 @@ softmmu_ss.add([files(
> >    'rng-builtin.c',
> >    'rng-egd.c',
> >    'rng.c',
> > +  'confidential-guest-support.c',
> >  ), numa])
> >  
> >  softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
> > diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
> > new file mode 100644
> > index 0000000000..5f131023ba
> > --- /dev/null
> > +++ b/include/exec/confidential-guest-support.h
> > @@ -0,0 +1,38 @@
> > +/*
> > + * QEMU Confidential Guest support
> > + *   This interface describes the common pieces between various
> > + *   schemes for protecting guest memory or other state against a
> > + *   compromised hypervisor.  This includes memory encryption (AMD's
> > + *   SEV and Intel's MKTME) or special protection modes (PEF on POWER,
> > + *   or PV on s390x).
> > + *
> > + * 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_CONFIDENTIAL_GUEST_SUPPORT_H
> > +#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
> > +
> > +#ifndef CONFIG_USER_ONLY
> > +
> > +#include "qom/object.h"
> > +
> > +#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
> > +OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
> > +
> > +struct ConfidentialGuestSupport {
> > +    Object parent;
> > +};
> > +
> > +typedef struct ConfidentialGuestSupportClass {
> > +    ObjectClass parent;
> > +} ConfidentialGuestSupportClass;
> > +
> > +#endif /* !CONFIG_USER_ONLY */
> > +
> > +#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
> > diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> > index 976b529dfb..33685c79ed 100644
> > --- a/include/qemu/typedefs.h
> > +++ b/include/qemu/typedefs.h
> > @@ -36,6 +36,7 @@ typedef struct BusState BusState;
> >  typedef struct Chardev Chardev;
> >  typedef struct CompatProperty CompatProperty;
> >  typedef struct CoMutex CoMutex;
> > +typedef struct ConfidentialGuestSupport ConfidentialGuestSupport;
> >  typedef struct CPUAddressSpace CPUAddressSpace;
> >  typedef struct CPUState CPUState;
> >  typedef struct DeviceListener DeviceListener;
> > diff --git a/target/i386/sev.c b/target/i386/sev.c
> > index 1546606811..6b49925f51 100644
> > --- a/target/i386/sev.c
> > +++ b/target/i386/sev.c
> > @@ -31,6 +31,7 @@
> >  #include "qom/object.h"
> >  #include "exec/address-spaces.h"
> >  #include "monitor/monitor.h"
> > +#include "exec/confidential-guest-support.h"
> >  
> >  #define TYPE_SEV_GUEST "sev-guest"
> >  OBJECT_DECLARE_SIMPLE_TYPE(SevGuestState, SEV_GUEST)
> > @@ -322,7 +323,7 @@ sev_guest_instance_init(Object *obj)
> >  
> >  /* sev guest info */
> >  static const TypeInfo sev_guest_info = {
> > -    .parent = TYPE_OBJECT,
> > +    .parent = TYPE_CONFIDENTIAL_GUEST_SUPPORT,
> 
> If you're changing the parent QOM type, then you also need to change
> the parent struct field type in SevguestState to match

Oops, yes.  I checked the rest of the types as I made the
OBJECT_DECLARE_TYPE conversions, but I forgot to go back and check
SEV.

> >      .name = TYPE_SEV_GUEST,
> >      .instance_size = sizeof(SevGuestState),
> >      .instance_finalize = sev_guest_finalize,
> 
> Regards,
> Daniel

-- 
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 --]

Re: [PATCH v7 13/13] s390: Recognize confidential-guest-support option

[David Gibson]

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

On Thu, Jan 14, 2021 at 10:10:02AM +0100, Christian Borntraeger wrote:
> 
> 
> On 14.01.21 00:58, David Gibson wrote:
> [...]
> > +int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
> > +{
> > +    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
> > +        return 0;
> > +    }
> > +
> > +    if (!s390_has_feat(S390_FEAT_UNPACK)) {
> > +        error_setg(errp,
> > +                   "CPU model does not support Protected Virtualization");
> > +        return -1;
> > +    }
> 
> I am triggering this and I guess this is because the cpu model is not yet initialized at
> this point in time.

Bother.  I thought I'd put the s390_pv_init() call late enough to
avoid that, but I guess not.  Any chance you can debug that?  Working
on s390 is far from easy for me.

-- 
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 --]

Re: [PATCH v7 13/13] s390: Recognize confidential-guest-support option

[David Gibson]

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

On Thu, Jan 14, 2021 at 10:24:57AM +0100, Christian Borntraeger wrote:
> 
> 
> On 14.01.21 10:19, Christian Borntraeger wrote:
> > 
> > 
> > On 14.01.21 10:10, Christian Borntraeger wrote:
> >>
> >>
> >> On 14.01.21 00:58, David Gibson wrote:
> >> [...]
> >>> +int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
> >>> +{
> >>> +    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
> >>> +        return 0;
> >>> +    }
> >>> +
> >>> +    if (!s390_has_feat(S390_FEAT_UNPACK)) {
> >>> +        error_setg(errp,
> >>> +                   "CPU model does not support Protected Virtualization");
> >>> +        return -1;
> >>> +    }
> >>
> >> I am triggering this and I guess this is because the cpu model is not yet initialized at
> >> this point in time.
> >>
> > When I remove the check, things seems to work though ( I can access virtio-blk devices without
> > specifying iommu for example)
> 
> Maybe we can turn things around and check in apply_cpu_model if the object exists but
> unpack was not specified?

That might work.  If unpack *is* specified, you'd also need to set the
ready flag there, of course.

-- 
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 --]

Re: [PATCH v7 03/13] sev: Remove false abstraction of flash encryption

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:01 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> When AMD's SEV memory encryption is in use, flash memory banks (which are
> initialed by pc_system_flash_map()) need to be encrypted with the guest's
> key, so that the guest can read them.
> 
> That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM
> state.. except, that it doesn't really abstract much at all.
> 
> For starters, the only called is in code specific to the 'pc' family of

s/called/call site/

> machine types, so it's obviously specific to those and to x86 to begin
> with.  But it makes a bunch of further assumptions that need not be true
> about an arbitrary confidential guest system based on memory encryption,
> let alone one based on other mechanisms:
> 
>  * it assumes that the flash memory is defined to be encrypted with the
>    guest key, rather than being shared with hypervisor
>  * it assumes that that hypervisor has some mechanism to encrypt data into
>    the guest, even though it can't decrypt it out, since that's the whole
>    point
>  * the interface assumes that this encrypt can be done in place, which
>    implies that the hypervisor can write into a confidential guests's
>    memory, even if what it writes isn't meaningful
> 
> So really, this "abstraction" is actually pretty specific to the way SEV
> works.  So, this patch removes it and instead has the PC flash
> initialization code call into a SEV specific callback.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  accel/kvm/kvm-all.c    | 31 ++-----------------------------
>  accel/kvm/sev-stub.c   |  9 ++-------
>  accel/stubs/kvm-stub.c | 10 ----------
>  hw/i386/pc_sysfw.c     | 17 ++++++-----------
>  include/sysemu/kvm.h   | 16 ----------------
>  include/sysemu/sev.h   |  4 ++--
>  target/i386/sev-stub.c |  5 +++++
>  target/i386/sev.c      | 24 ++++++++++++++----------
>  8 files changed, 31 insertions(+), 85 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Re: [PATCH v7 04/13] confidential guest support: Move side effect out of machine_set_memory_encryption()

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:02 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> 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>
> Reviewed-by: Greg Kurz <groug@kaod.org>
> ---
>  hw/core/machine.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Re: [PATCH v7 05/13] confidential guest support: Rework the "memory-encryption" property

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:03 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> 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 "confidential-guest-support" 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: Greg Kurz <groug@kaod.org>
> ---
>  accel/kvm/kvm-all.c  |  5 +++--
>  accel/kvm/sev-stub.c |  5 +++--
>  hw/core/machine.c    | 43 +++++++++++++++++++++++++++++++++++++------
>  include/hw/boards.h  |  2 +-
>  include/sysemu/sev.h |  2 +-
>  target/i386/sev.c    | 32 ++------------------------------
>  6 files changed, 47 insertions(+), 42 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:05 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> The platform specific details of mechanisms for implementing
> confidential guest support may require setup at various points during
> initialization.  Thus, it's not really feasible to have a single cgs
> initialization hook, but instead each mechanism needs its own
> initialization calls in arch or machine specific code.
> 
> However, to make it harder to have a bug where a mechanism isn't
> properly initialized under some circumstances, we want to have a
> common place, relatively late in boot, where we verify that cgs has
> been initialized if it was requested.
> 
> This patch introduces a ready flag to the ConfidentialGuestSupport
> base type to accomplish this, which we verify just before the machine
> specific initialization function.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  hw/core/machine.c                         | 8 ++++++++
>  include/exec/confidential-guest-support.h | 2 ++
>  target/i386/sev.c                         | 2 ++
>  3 files changed, 12 insertions(+)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Re: [PATCH v7 08/13] confidential guest support: Move SEV initialization into arch specific code

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:06 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> While we've abstracted some (potential) differences between mechanisms for
> securing guest memory, the initialization is still specific to SEV.  Given
> that, move it into x86's kvm_arch_init() code, rather than the generic
> kvm_init() code.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  accel/kvm/kvm-all.c   | 14 --------------
>  accel/kvm/sev-stub.c  |  4 ++--
>  target/i386/kvm/kvm.c | 12 ++++++++++++
>  target/i386/sev.c     |  7 ++++++-
>  4 files changed, 20 insertions(+), 17 deletions(-)
> 

(...)

> @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>      uint64_t shadow_mem;
>      int ret;
>      struct utsname utsname;
> +    Error *local_err = NULL;
> +
> +    /*
> +     * if memory encryption object is specified then initialize the
> +     * memory encryption context (no-op otherwise)
> +     */
> +    ret = sev_kvm_init(ms->cgs, &local_err);

Maybe still leave a comment here, as the code will still need to be
modified to handle non-SEV x86 mechanisms?

> +    if (ret < 0) {
> +        error_report_err(local_err);
> +        return ret;
> +    }
>  
>      if (!kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) {
>          error_report("kvm: KVM_CAP_IRQ_ROUTING not supported by KVM");
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 3d94635397..aa79cacabe 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -664,13 +664,18 @@ sev_vm_state_change(void *opaque, int running, RunState state)
>  
>  int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
>  {
> -    SevGuestState *sev = SEV_GUEST(cgs);
> +    SevGuestState *sev
> +        = (SevGuestState *)object_dynamic_cast(OBJECT(cgs), TYPE_SEV_GUEST);

This looks a bit ugly; maybe we want the generic code to generate a
separate version of the cast macro that doesn't assert? Just cosmetics,
though.

>      char *devname;
>      int ret, fw_error;
>      uint32_t ebx;
>      uint32_t host_cbitpos;
>      struct sev_user_data_status status = {};
>  
> +    if (!sev) {
> +        return 0;
> +    }
> +
>      ret = ram_block_discard_disable(true);
>      if (ret) {
>          error_report("%s: cannot disable RAM discard", __func__);

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

Re: [PATCH v7 09/13] confidential guest support: Update documentation

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:07 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> Now that we've implemented a generic machine option for configuring various
> confidential guest support mechanisms:
>   1. Update docs/amd-memory-encryption.txt to reference this rather than
>      the earlier SEV specific option
>   2. Add a docs/confidential-guest-support.txt to cover the generalities of
>      the confidential guest support scheme
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  docs/amd-memory-encryption.txt      |  2 +-
>  docs/confidential-guest-support.txt | 43 +++++++++++++++++++++++++++++
>  2 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 docs/confidential-guest-support.txt
> 
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index 80b8eb00e9..145896aec7 100644
> --- a/docs/amd-memory-encryption.txt
> +++ b/docs/amd-memory-encryption.txt
> @@ -73,7 +73,7 @@ complete flow chart.
>  To launch a SEV guest
>  
>  # ${QEMU} \
> -    -machine ...,memory-encryption=sev0 \
> +    -machine ...,confidential-guest-support=sev0 \
>      -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
>  
>  Debugging
> diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
> new file mode 100644
> index 0000000000..2790425b38
> --- /dev/null
> +++ b/docs/confidential-guest-support.txt

Maybe make this a proper .rst from the start and hook this up into the
system guide? It is already almost there.

> @@ -0,0 +1,43 @@
> +Confidential Guest Support
> +==========================
> +
> +Traditionally, hypervisors such as qemu have complete access to a

s/qemu/QEMU/ ?

> +guest's memory and other state, meaning that a compromised hypervisor
> +can compromise any of its guests.  A number of platforms have added
> +mechanisms in hardware and/or firmware which give guests at least some
> +protection from a compromised hypervisor.  This is obviously
> +especially desirable for public cloud environments.
> +
> +These mechanisms have different names and different modes of
> +operation, but are often referred to as Secure Guests or Confidential
> +Guests.  We use the term "Confidential Guest Support" to distinguish
> +this from other aspects of guest security (such as security against
> +attacks from other guests, or from network sources).
> +
> +Running a Confidential Guest
> +----------------------------
> +
> +To run a confidential guest you need to add two command line parameters:
> +
> +1. Use "-object" to create a "confidential guest support" object.  The
> +   type and parameters will vary with the specific mechanism to be
> +   used
> +2. Set the "confidential-guest-support" machine parameter to the ID of
> +   the object from (1).
> +
> +Example (for AMD SEV)::
> +
> +    qemu-system-x86_64 \
> +        <other parameters> \
> +        -machine ...,confidential-guest-support=sev0 \
> +        -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
> +
> +Supported mechanisms
> +--------------------
> +
> +Currently supported confidential guest mechanisms are:
> +
> +AMD Secure Encrypted Virtualization (SEV)
> +    docs/amd-memory-encryption.txt
> +
> +Other mechanisms may be supported in future.

LGTM.

Re: [PATCH v7 10/13] spapr: Add PEF based confidential guest support

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:08 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> 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 confidential-guest-support
> 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 directl 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 confidential-guest-support=pef0
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  docs/confidential-guest-support.txt |   3 +
>  docs/papr-pef.txt                   |  30 +++++++
>  hw/ppc/meson.build                  |   1 +
>  hw/ppc/pef.c                        | 119 ++++++++++++++++++++++++++++
>  hw/ppc/spapr.c                      |   6 ++
>  include/hw/ppc/pef.h                |  25 ++++++
>  target/ppc/kvm.c                    |  18 -----
>  target/ppc/kvm_ppc.h                |   6 --
>  8 files changed, 184 insertions(+), 24 deletions(-)
>  create mode 100644 docs/papr-pef.txt
>  create mode 100644 hw/ppc/pef.c
>  create mode 100644 include/hw/ppc/pef.h
> 
> diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
> index 2790425b38..f0801814ff 100644
> --- a/docs/confidential-guest-support.txt
> +++ b/docs/confidential-guest-support.txt
> @@ -40,4 +40,7 @@ Currently supported confidential guest mechanisms are:
>  AMD Secure Encrypted Virtualization (SEV)
>      docs/amd-memory-encryption.txt
>  
> +POWER Protected Execution Facility (PEF)
> +    docs/papr-pef.txt
> +
>  Other mechanisms may be supported in future.
> diff --git a/docs/papr-pef.txt b/docs/papr-pef.txt
> new file mode 100644
> index 0000000000..6419e995cf
> --- /dev/null
> +++ b/docs/papr-pef.txt

Same here, make this .rst and add it to the system guide?

> @@ -0,0 +1,30 @@
> +POWER (PAPR) Protected Execution Facility (PEF)
> +===============================================
> +
> +Protected Execution Facility (PEF), also known as Secure Guest support
> +is a feature found on IBM POWER9 and POWER10 processors.
> +
> +If a suitable firmware including an Ultravisor is installed, it adds
> +an extra memory protection mode to the CPU.  The ultravisor manages a
> +pool of secure memory which cannot be accessed by the hypervisor.
> +
> +When this feature is enabled in qemu, a guest can use ultracalls to

s/qemu/QEMU/

> +enter "secure mode".  This transfers most of its memory to secure
> +memory, where it cannot be eavesdropped by a compromised hypervisor.
> +
> +Launching
> +---------
> +
> +To launch a guest which will be permitted to enter PEF secure mode:
> +
> +# ${QEMU} \
> +    -object pef-guest,id=pef0 \
> +    -machine confidential-guest-support=pef0 \
> +    ...
> +
> +Live Migration
> +----------------
> +
> +Live migration is not yet implemented for PEF guests.  For
> +consistency, we currently prevent migration if the PEF feature is
> +enabled, whether or not the guest has actually entered secure mode.
> diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
> index ffa2ec37fa..218631c883 100644
> --- a/hw/ppc/meson.build
> +++ b/hw/ppc/meson.build
> @@ -27,6 +27,7 @@ ppc_ss.add(when: 'CONFIG_PSERIES', if_true: files(
>    'spapr_nvdimm.c',
>    'spapr_rtas_ddw.c',
>    'spapr_numa.c',
> +  'pef.c',
>  ))
>  ppc_ss.add(when: 'CONFIG_SPAPR_RNG', if_true: files('spapr_rng.c'))
>  ppc_ss.add(when: ['CONFIG_PSERIES', 'CONFIG_LINUX'], if_true: files(
> diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c
> new file mode 100644
> index 0000000000..02b9b3b460
> --- /dev/null
> +++ b/hw/ppc/pef.c
> @@ -0,0 +1,119 @@
> +/*
> + * PEF (Protected Execution Facility) for POWER support
> + *
> + * Copyright David Gibson, Redhat Inc. 2020

2021?

> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +

Re: [PATCH v7 13/13] s390: Recognize confidential-guest-support option

[Cornelia Huck]

On Thu, 14 Jan 2021 10:58:11 +1100
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 by the "confidential-guest-support"
> 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 confidential-guest-support 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 confidential-guest-support
>    is set, we will either create a guest capable of entering PV mode,
>    or fail outright.
> 
>  - If confidential-guest-support is not set, guests 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 confidential-guest-support=pv0
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  docs/confidential-guest-support.txt |  3 ++
>  docs/system/s390x/protvirt.rst      | 19 ++++++---
>  hw/s390x/pv.c                       | 62 +++++++++++++++++++++++++++++
>  include/hw/s390x/pv.h               |  1 +
>  target/s390x/kvm.c                  |  3 ++
>  5 files changed, 82 insertions(+), 6 deletions(-)
> 

(...)

> +int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
> +{
> +    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
> +        return 0;
> +    }
> +
> +    if (!s390_has_feat(S390_FEAT_UNPACK)) {
> +        error_setg(errp,
> +                   "CPU model does not support Protected Virtualization");
> +        return -1;
> +    }
> +
> +    cgs->ready = true;
> +
> +    return 0;
> +}

Do we want to add a migration blocker here? If we keep the one that is
added when the guest transitions, we'll end up with two of them, but
that might be easier than trying to unify it.

Re: [PATCH v7 03/13] sev: Remove false abstraction of flash encryption

[David Gibson]

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

On Fri, Jan 15, 2021 at 01:54:25PM +0100, Cornelia Huck wrote:
> On Thu, 14 Jan 2021 10:58:01 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > When AMD's SEV memory encryption is in use, flash memory banks (which are
> > initialed by pc_system_flash_map()) need to be encrypted with the guest's
> > key, so that the guest can read them.
> > 
> > That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM
> > state.. except, that it doesn't really abstract much at all.
> > 
> > For starters, the only called is in code specific to the 'pc' family of
> 
> s/called/call site/

Fixed, thanks.

> 
> > machine types, so it's obviously specific to those and to x86 to begin
> > with.  But it makes a bunch of further assumptions that need not be true
> > about an arbitrary confidential guest system based on memory encryption,
> > let alone one based on other mechanisms:
> > 
> >  * it assumes that the flash memory is defined to be encrypted with the
> >    guest key, rather than being shared with hypervisor
> >  * it assumes that that hypervisor has some mechanism to encrypt data into
> >    the guest, even though it can't decrypt it out, since that's the whole
> >    point
> >  * the interface assumes that this encrypt can be done in place, which
> >    implies that the hypervisor can write into a confidential guests's
> >    memory, even if what it writes isn't meaningful
> > 
> > So really, this "abstraction" is actually pretty specific to the way SEV
> > works.  So, this patch removes it and instead has the PC flash
> > initialization code call into a SEV specific callback.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  accel/kvm/kvm-all.c    | 31 ++-----------------------------
> >  accel/kvm/sev-stub.c   |  9 ++-------
> >  accel/stubs/kvm-stub.c | 10 ----------
> >  hw/i386/pc_sysfw.c     | 17 ++++++-----------
> >  include/sysemu/kvm.h   | 16 ----------------
> >  include/sysemu/sev.h   |  4 ++--
> >  target/i386/sev-stub.c |  5 +++++
> >  target/i386/sev.c      | 24 ++++++++++++++----------
> >  8 files changed, 31 insertions(+), 85 deletions(-)
> 
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> 

-- 
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 --]

Re: [PATCH v7 08/13] confidential guest support: Move SEV initialization into arch specific code

[David Gibson]

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

On Fri, Jan 15, 2021 at 02:24:25PM +0100, Cornelia Huck wrote:
> On Thu, 14 Jan 2021 10:58:06 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > While we've abstracted some (potential) differences between mechanisms for
> > securing guest memory, the initialization is still specific to SEV.  Given
> > that, move it into x86's kvm_arch_init() code, rather than the generic
> > kvm_init() code.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  accel/kvm/kvm-all.c   | 14 --------------
> >  accel/kvm/sev-stub.c  |  4 ++--
> >  target/i386/kvm/kvm.c | 12 ++++++++++++
> >  target/i386/sev.c     |  7 ++++++-
> >  4 files changed, 20 insertions(+), 17 deletions(-)
> > 
> 
> (...)
> 
> > @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> >      uint64_t shadow_mem;
> >      int ret;
> >      struct utsname utsname;
> > +    Error *local_err = NULL;
> > +
> > +    /*
> > +     * if memory encryption object is specified then initialize the
> > +     * memory encryption context (no-op otherwise)
> > +     */
> > +    ret = sev_kvm_init(ms->cgs, &local_err);
> 
> Maybe still leave a comment here, as the code will still need to be
> modified to handle non-SEV x86 mechanisms?

Uh.. I'm confused.. this hunk is adding a comment, not removing one..

> 
> > +    if (ret < 0) {
> > +        error_report_err(local_err);
> > +        return ret;
> > +    }
> >  
> >      if (!kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) {
> >          error_report("kvm: KVM_CAP_IRQ_ROUTING not supported by KVM");
> > diff --git a/target/i386/sev.c b/target/i386/sev.c
> > index 3d94635397..aa79cacabe 100644
> > --- a/target/i386/sev.c
> > +++ b/target/i386/sev.c
> > @@ -664,13 +664,18 @@ sev_vm_state_change(void *opaque, int running, RunState state)
> >  
> >  int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
> >  {
> > -    SevGuestState *sev = SEV_GUEST(cgs);
> > +    SevGuestState *sev
> > +        = (SevGuestState *)object_dynamic_cast(OBJECT(cgs), TYPE_SEV_GUEST);
> 
> This looks a bit ugly; maybe we want the generic code to generate a
> separate version of the cast macro that doesn't assert? Just cosmetics,
> though.

I tend to the view that the clunkiness of this textually is
outweighted by using object_dynamic_cast() which has well known
semantics, rather than requiring someone reading the code to
understand another intermediate macro.

> >      char *devname;
> >      int ret, fw_error;
> >      uint32_t ebx;
> >      uint32_t host_cbitpos;
> >      struct sev_user_data_status status = {};
> >  
> > +    if (!sev) {
> > +        return 0;
> > +    }
> > +
> >      ret = ram_block_discard_disable(true);
> >      if (ret) {
> >          error_report("%s: cannot disable RAM discard", __func__);
> 
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> 

-- 
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 --]

Re: [PATCH v7 08/13] confidential guest support: Move SEV initialization into arch specific code

[Cornelia Huck]

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

On Mon, 18 Jan 2021 14:03:08 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Fri, Jan 15, 2021 at 02:24:25PM +0100, Cornelia Huck wrote:
> > On Thu, 14 Jan 2021 10:58:06 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > While we've abstracted some (potential) differences between mechanisms for
> > > securing guest memory, the initialization is still specific to SEV.  Given
> > > that, move it into x86's kvm_arch_init() code, rather than the generic
> > > kvm_init() code.
> > > 
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > ---
> > >  accel/kvm/kvm-all.c   | 14 --------------
> > >  accel/kvm/sev-stub.c  |  4 ++--
> > >  target/i386/kvm/kvm.c | 12 ++++++++++++
> > >  target/i386/sev.c     |  7 ++++++-
> > >  4 files changed, 20 insertions(+), 17 deletions(-)
> > >   
> > 
> > (...)
> >   
> > > @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> > >      uint64_t shadow_mem;
> > >      int ret;
> > >      struct utsname utsname;
> > > +    Error *local_err = NULL;
> > > +
> > > +    /*
> > > +     * if memory encryption object is specified then initialize the
> > > +     * memory encryption context (no-op otherwise)
> > > +     */
> > > +    ret = sev_kvm_init(ms->cgs, &local_err);  
> > 
> > Maybe still leave a comment here, as the code will still need to be
> > modified to handle non-SEV x86 mechanisms?  
> 
> Uh.. I'm confused.. this hunk is adding a comment, not removing one..

Yes, but there was a "TODO: handle non-SEV" comment before. This will
probably need some massaging if we add Intel mechanisms?

> 
> >   
> > > +    if (ret < 0) {
> > > +        error_report_err(local_err);
> > > +        return ret;
> > > +    }
> > >  
> > >      if (!kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) {
> > >          error_report("kvm: KVM_CAP_IRQ_ROUTING not supported by KVM");

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

Re: [PATCH v7 13/13] s390: Recognize confidential-guest-support option

[Christian Borntraeger]

On 15.01.21 17:36, Cornelia Huck wrote:
> On Thu, 14 Jan 2021 10:58:11 +1100
> 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 by the "confidential-guest-support"
>> 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 confidential-guest-support 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 confidential-guest-support
>>    is set, we will either create a guest capable of entering PV mode,
>>    or fail outright.
>>
>>  - If confidential-guest-support is not set, guests 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 confidential-guest-support=pv0
>>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>> ---
>>  docs/confidential-guest-support.txt |  3 ++
>>  docs/system/s390x/protvirt.rst      | 19 ++++++---
>>  hw/s390x/pv.c                       | 62 +++++++++++++++++++++++++++++
>>  include/hw/s390x/pv.h               |  1 +
>>  target/s390x/kvm.c                  |  3 ++
>>  5 files changed, 82 insertions(+), 6 deletions(-)
>>
> 
> (...)
> 
>> +int s390_pv_init(ConfidentialGuestSupport *cgs, Error **errp)
>> +{
>> +    if (!object_dynamic_cast(OBJECT(cgs), TYPE_S390_PV_GUEST)) {
>> +        return 0;
>> +    }
>> +
>> +    if (!s390_has_feat(S390_FEAT_UNPACK)) {
>> +        error_setg(errp,
>> +                   "CPU model does not support Protected Virtualization");
>> +        return -1;
>> +    }
>> +
>> +    cgs->ready = true;
>> +
>> +    return 0;
>> +}
> 
> Do we want to add a migration blocker here? If we keep the one that is
> added when the guest transitions, we'll end up with two of them, but
> that might be easier than trying to unify it.

that whould be fine with me. We still need to move things around to
make sure that the cpu model is already in place, though. 

Re: [PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class

[Dr. David Alan Gilbert]

* David Gibson (david@gibson.dropbear.id.au) wrote:
> 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's MKTME can do
                                                           ^^^^^
(and below) My understanding is that it's Intel TDX that's the VM
equivalent.

Dave

> similar things.  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
> ConfidentialGuestSupport QOM base class.  "Confidential" is kind of vague,
> but "confidential computing" seems to be the buzzword about these schemes,
> and "secure" or "protected" are often used in connection to unrelated
> things (such as hypervisor-from-guest or guest-from-guest security).
> 
> The "support" in the name is significant because in at least some of the
> cases it requires the guest to take specific actions in order to protect
> itself from hypervisor eavesdropping.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  backends/confidential-guest-support.c     | 33 ++++++++++++++++++++
>  backends/meson.build                      |  1 +
>  include/exec/confidential-guest-support.h | 38 +++++++++++++++++++++++
>  include/qemu/typedefs.h                   |  1 +
>  target/i386/sev.c                         |  3 +-
>  5 files changed, 75 insertions(+), 1 deletion(-)
>  create mode 100644 backends/confidential-guest-support.c
>  create mode 100644 include/exec/confidential-guest-support.h
> 
> diff --git a/backends/confidential-guest-support.c b/backends/confidential-guest-support.c
> new file mode 100644
> index 0000000000..9b0ded0db4
> --- /dev/null
> +++ b/backends/confidential-guest-support.c
> @@ -0,0 +1,33 @@
> +/*
> + * QEMU Confidential Guest support
> + *
> + * 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/confidential-guest-support.h"
> +
> +OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
> +                            confidential_guest_support,
> +                            CONFIDENTIAL_GUEST_SUPPORT,
> +                            OBJECT)
> +
> +static void confidential_guest_support_class_init(ObjectClass *oc, void *data)
> +{
> +}
> +
> +static void confidential_guest_support_init(Object *obj)
> +{
> +}
> +
> +static void confidential_guest_support_finalize(Object *obj)
> +{
> +}
> diff --git a/backends/meson.build b/backends/meson.build
> index 484456ece7..d4221831fc 100644
> --- a/backends/meson.build
> +++ b/backends/meson.build
> @@ -6,6 +6,7 @@ softmmu_ss.add([files(
>    'rng-builtin.c',
>    'rng-egd.c',
>    'rng.c',
> +  'confidential-guest-support.c',
>  ), numa])
>  
>  softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
> diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
> new file mode 100644
> index 0000000000..5f131023ba
> --- /dev/null
> +++ b/include/exec/confidential-guest-support.h
> @@ -0,0 +1,38 @@
> +/*
> + * QEMU Confidential Guest support
> + *   This interface describes the common pieces between various
> + *   schemes for protecting guest memory or other state against a
> + *   compromised hypervisor.  This includes memory encryption (AMD's
> + *   SEV and Intel's MKTME) or special protection modes (PEF on POWER,
> + *   or PV on s390x).
> + *
> + * 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_CONFIDENTIAL_GUEST_SUPPORT_H
> +#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
> +
> +#ifndef CONFIG_USER_ONLY
> +
> +#include "qom/object.h"
> +
> +#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
> +OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
> +
> +struct ConfidentialGuestSupport {
> +    Object parent;
> +};
> +
> +typedef struct ConfidentialGuestSupportClass {
> +    ObjectClass parent;
> +} ConfidentialGuestSupportClass;
> +
> +#endif /* !CONFIG_USER_ONLY */
> +
> +#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
> diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> index 976b529dfb..33685c79ed 100644
> --- a/include/qemu/typedefs.h
> +++ b/include/qemu/typedefs.h
> @@ -36,6 +36,7 @@ typedef struct BusState BusState;
>  typedef struct Chardev Chardev;
>  typedef struct CompatProperty CompatProperty;
>  typedef struct CoMutex CoMutex;
> +typedef struct ConfidentialGuestSupport ConfidentialGuestSupport;
>  typedef struct CPUAddressSpace CPUAddressSpace;
>  typedef struct CPUState CPUState;
>  typedef struct DeviceListener DeviceListener;
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 1546606811..6b49925f51 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -31,6 +31,7 @@
>  #include "qom/object.h"
>  #include "exec/address-spaces.h"
>  #include "monitor/monitor.h"
> +#include "exec/confidential-guest-support.h"
>  
>  #define TYPE_SEV_GUEST "sev-guest"
>  OBJECT_DECLARE_SIMPLE_TYPE(SevGuestState, SEV_GUEST)
> @@ -322,7 +323,7 @@ sev_guest_instance_init(Object *obj)
>  
>  /* sev guest info */
>  static const TypeInfo sev_guest_info = {
> -    .parent = TYPE_OBJECT,
> +    .parent = TYPE_CONFIDENTIAL_GUEST_SUPPORT,
>      .name = TYPE_SEV_GUEST,
>      .instance_size = sizeof(SevGuestState),
>      .instance_finalize = sev_guest_finalize,
> -- 
> 2.29.2
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag

[Dr. David Alan Gilbert]

* David Gibson (david@gibson.dropbear.id.au) wrote:
> The platform specific details of mechanisms for implementing
> confidential guest support may require setup at various points during
> initialization.  Thus, it's not really feasible to have a single cgs
> initialization hook, but instead each mechanism needs its own
> initialization calls in arch or machine specific code.
> 
> However, to make it harder to have a bug where a mechanism isn't
> properly initialized under some circumstances, we want to have a
> common place, relatively late in boot, where we verify that cgs has
> been initialized if it was requested.
> 
> This patch introduces a ready flag to the ConfidentialGuestSupport
> base type to accomplish this, which we verify just before the machine
> specific initialization function.

You may find you need to define 'ready' and the answer might be a bit
variable; for example, on SEV there's a setup bit and then you may end
up doing an attestation and receiving some data before you actaully let
the guest execute code.   Is it ready before it's received the
attestation response or only when it can run code?
Is a Power or 390 machine 'ready' before it's executed the magic
instruction to enter the confidential mode?

Dave

> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  hw/core/machine.c                         | 8 ++++++++
>  include/exec/confidential-guest-support.h | 2 ++
>  target/i386/sev.c                         | 2 ++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 94194ab82d..5a7433332b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -1190,6 +1190,14 @@ void machine_run_board_init(MachineState *machine)
>      }
>  
>      if (machine->cgs) {
> +        /*
> +         * Where confidential guest support is initialized depends on
> +         * the specific mechanism in use.  But, we need to make sure
> +         * it's ready by now.  If it isn't, that's a bug in the
> +         * implementation of that cgs mechanism.
> +         */
> +        assert(machine->cgs->ready);
> +
>          /*
>           * With confidential guests, the host can't see the real
>           * contents of RAM, so there's no point in it trying to merge
> diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
> index 5f131023ba..bcaf6c9f49 100644
> --- a/include/exec/confidential-guest-support.h
> +++ b/include/exec/confidential-guest-support.h
> @@ -27,6 +27,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
>  
>  struct ConfidentialGuestSupport {
>      Object parent;
> +
> +    bool ready;
>  };
>  
>  typedef struct ConfidentialGuestSupportClass {
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index e2b41ef342..3d94635397 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -737,6 +737,8 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
>      qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
>      qemu_add_vm_change_state_handler(sev_vm_state_change, sev);
>  
> +    cgs->ready = true;
> +
>      return 0;
>  err:
>      sev_guest = NULL;
> -- 
> 2.29.2
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag

[Cornelia Huck]

On Mon, 18 Jan 2021 19:47:30 +0000
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:

> * David Gibson (david@gibson.dropbear.id.au) wrote:
> > The platform specific details of mechanisms for implementing
> > confidential guest support may require setup at various points during
> > initialization.  Thus, it's not really feasible to have a single cgs
> > initialization hook, but instead each mechanism needs its own
> > initialization calls in arch or machine specific code.
> > 
> > However, to make it harder to have a bug where a mechanism isn't
> > properly initialized under some circumstances, we want to have a
> > common place, relatively late in boot, where we verify that cgs has
> > been initialized if it was requested.
> > 
> > This patch introduces a ready flag to the ConfidentialGuestSupport
> > base type to accomplish this, which we verify just before the machine
> > specific initialization function.  
> 
> You may find you need to define 'ready' and the answer might be a bit
> variable; for example, on SEV there's a setup bit and then you may end
> up doing an attestation and receiving some data before you actaully let
> the guest execute code.   Is it ready before it's received the
> attestation response or only when it can run code?
> Is a Power or 390 machine 'ready' before it's executed the magic
> instruction to enter the confidential mode?

I would consider those machines where the guest makes the transition
itself "ready" as soon as everything is set up so that the guest can
actually initiate the transition. Otherwise, those machines would never
be "ready" if the guest does not transition.

Maybe we can define "ready" as "the guest can start to execute in
secure mode", where "guest" includes the bootloader and everything that
runs in a guest context, and "start to execute" implies that some setup
may be done only after the guest has kicked it off?

Re: [PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class

[David Gibson]

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

On Mon, Jan 18, 2021 at 06:51:24PM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (david@gibson.dropbear.id.au) wrote:
> > 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's MKTME can do
>                                                            ^^^^^
> (and below) My understanding is that it's Intel TDX that's the VM
> equivalent.

I thought MKTME could already do memory encryption and TDX extended
that to... more?  I'll adjust the comment to say TDX anyway, since
that seems to be the newer name.

> 
> Dave
> 
> > similar things.  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
> > ConfidentialGuestSupport QOM base class.  "Confidential" is kind of vague,
> > but "confidential computing" seems to be the buzzword about these schemes,
> > and "secure" or "protected" are often used in connection to unrelated
> > things (such as hypervisor-from-guest or guest-from-guest security).
> > 
> > The "support" in the name is significant because in at least some of the
> > cases it requires the guest to take specific actions in order to protect
> > itself from hypervisor eavesdropping.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  backends/confidential-guest-support.c     | 33 ++++++++++++++++++++
> >  backends/meson.build                      |  1 +
> >  include/exec/confidential-guest-support.h | 38 +++++++++++++++++++++++
> >  include/qemu/typedefs.h                   |  1 +
> >  target/i386/sev.c                         |  3 +-
> >  5 files changed, 75 insertions(+), 1 deletion(-)
> >  create mode 100644 backends/confidential-guest-support.c
> >  create mode 100644 include/exec/confidential-guest-support.h
> > 
> > diff --git a/backends/confidential-guest-support.c b/backends/confidential-guest-support.c
> > new file mode 100644
> > index 0000000000..9b0ded0db4
> > --- /dev/null
> > +++ b/backends/confidential-guest-support.c
> > @@ -0,0 +1,33 @@
> > +/*
> > + * QEMU Confidential Guest support
> > + *
> > + * 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/confidential-guest-support.h"
> > +
> > +OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
> > +                            confidential_guest_support,
> > +                            CONFIDENTIAL_GUEST_SUPPORT,
> > +                            OBJECT)
> > +
> > +static void confidential_guest_support_class_init(ObjectClass *oc, void *data)
> > +{
> > +}
> > +
> > +static void confidential_guest_support_init(Object *obj)
> > +{
> > +}
> > +
> > +static void confidential_guest_support_finalize(Object *obj)
> > +{
> > +}
> > diff --git a/backends/meson.build b/backends/meson.build
> > index 484456ece7..d4221831fc 100644
> > --- a/backends/meson.build
> > +++ b/backends/meson.build
> > @@ -6,6 +6,7 @@ softmmu_ss.add([files(
> >    'rng-builtin.c',
> >    'rng-egd.c',
> >    'rng.c',
> > +  'confidential-guest-support.c',
> >  ), numa])
> >  
> >  softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
> > diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
> > new file mode 100644
> > index 0000000000..5f131023ba
> > --- /dev/null
> > +++ b/include/exec/confidential-guest-support.h
> > @@ -0,0 +1,38 @@
> > +/*
> > + * QEMU Confidential Guest support
> > + *   This interface describes the common pieces between various
> > + *   schemes for protecting guest memory or other state against a
> > + *   compromised hypervisor.  This includes memory encryption (AMD's
> > + *   SEV and Intel's MKTME) or special protection modes (PEF on POWER,
> > + *   or PV on s390x).
> > + *
> > + * 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_CONFIDENTIAL_GUEST_SUPPORT_H
> > +#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
> > +
> > +#ifndef CONFIG_USER_ONLY
> > +
> > +#include "qom/object.h"
> > +
> > +#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
> > +OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
> > +
> > +struct ConfidentialGuestSupport {
> > +    Object parent;
> > +};
> > +
> > +typedef struct ConfidentialGuestSupportClass {
> > +    ObjectClass parent;
> > +} ConfidentialGuestSupportClass;
> > +
> > +#endif /* !CONFIG_USER_ONLY */
> > +
> > +#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
> > diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> > index 976b529dfb..33685c79ed 100644
> > --- a/include/qemu/typedefs.h
> > +++ b/include/qemu/typedefs.h
> > @@ -36,6 +36,7 @@ typedef struct BusState BusState;
> >  typedef struct Chardev Chardev;
> >  typedef struct CompatProperty CompatProperty;
> >  typedef struct CoMutex CoMutex;
> > +typedef struct ConfidentialGuestSupport ConfidentialGuestSupport;
> >  typedef struct CPUAddressSpace CPUAddressSpace;
> >  typedef struct CPUState CPUState;
> >  typedef struct DeviceListener DeviceListener;
> > diff --git a/target/i386/sev.c b/target/i386/sev.c
> > index 1546606811..6b49925f51 100644
> > --- a/target/i386/sev.c
> > +++ b/target/i386/sev.c
> > @@ -31,6 +31,7 @@
> >  #include "qom/object.h"
> >  #include "exec/address-spaces.h"
> >  #include "monitor/monitor.h"
> > +#include "exec/confidential-guest-support.h"
> >  
> >  #define TYPE_SEV_GUEST "sev-guest"
> >  OBJECT_DECLARE_SIMPLE_TYPE(SevGuestState, SEV_GUEST)
> > @@ -322,7 +323,7 @@ sev_guest_instance_init(Object *obj)
> >  
> >  /* sev guest info */
> >  static const TypeInfo sev_guest_info = {
> > -    .parent = TYPE_OBJECT,
> > +    .parent = TYPE_CONFIDENTIAL_GUEST_SUPPORT,
> >      .name = TYPE_SEV_GUEST,
> >      .instance_size = sizeof(SevGuestState),
> >      .instance_finalize = sev_guest_finalize,

-- 
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 --]

Re: [PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class

[Dr. David Alan Gilbert]

* David Gibson (david@gibson.dropbear.id.au) wrote:
> On Mon, Jan 18, 2021 at 06:51:24PM +0000, Dr. David Alan Gilbert wrote:
> > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > 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's MKTME can do
> >                                                            ^^^^^
> > (and below) My understanding is that it's Intel TDX that's the VM
> > equivalent.
> 
> I thought MKTME could already do memory encryption and TDX extended
> that to... more?  I'll adjust the comment to say TDX anyway, since
> that seems to be the newer name.

My understanding was MKTME does the memory encryption, but doesn't
explicitly wire that into VMs or attestation of VMs or anything like
that.  TDX wires that encryption to VMs and provides all the other glue
that goes with attestation and the like.

Dave

> > 
> > Dave
> > 
> > > similar things.  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
> > > ConfidentialGuestSupport QOM base class.  "Confidential" is kind of vague,
> > > but "confidential computing" seems to be the buzzword about these schemes,
> > > and "secure" or "protected" are often used in connection to unrelated
> > > things (such as hypervisor-from-guest or guest-from-guest security).
> > > 
> > > The "support" in the name is significant because in at least some of the
> > > cases it requires the guest to take specific actions in order to protect
> > > itself from hypervisor eavesdropping.
> > > 
> > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > ---
> > >  backends/confidential-guest-support.c     | 33 ++++++++++++++++++++
> > >  backends/meson.build                      |  1 +
> > >  include/exec/confidential-guest-support.h | 38 +++++++++++++++++++++++
> > >  include/qemu/typedefs.h                   |  1 +
> > >  target/i386/sev.c                         |  3 +-
> > >  5 files changed, 75 insertions(+), 1 deletion(-)
> > >  create mode 100644 backends/confidential-guest-support.c
> > >  create mode 100644 include/exec/confidential-guest-support.h
> > > 
> > > diff --git a/backends/confidential-guest-support.c b/backends/confidential-guest-support.c
> > > new file mode 100644
> > > index 0000000000..9b0ded0db4
> > > --- /dev/null
> > > +++ b/backends/confidential-guest-support.c
> > > @@ -0,0 +1,33 @@
> > > +/*
> > > + * QEMU Confidential Guest support
> > > + *
> > > + * 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/confidential-guest-support.h"
> > > +
> > > +OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
> > > +                            confidential_guest_support,
> > > +                            CONFIDENTIAL_GUEST_SUPPORT,
> > > +                            OBJECT)
> > > +
> > > +static void confidential_guest_support_class_init(ObjectClass *oc, void *data)
> > > +{
> > > +}
> > > +
> > > +static void confidential_guest_support_init(Object *obj)
> > > +{
> > > +}
> > > +
> > > +static void confidential_guest_support_finalize(Object *obj)
> > > +{
> > > +}
> > > diff --git a/backends/meson.build b/backends/meson.build
> > > index 484456ece7..d4221831fc 100644
> > > --- a/backends/meson.build
> > > +++ b/backends/meson.build
> > > @@ -6,6 +6,7 @@ softmmu_ss.add([files(
> > >    'rng-builtin.c',
> > >    'rng-egd.c',
> > >    'rng.c',
> > > +  'confidential-guest-support.c',
> > >  ), numa])
> > >  
> > >  softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
> > > diff --git a/include/exec/confidential-guest-support.h b/include/exec/confidential-guest-support.h
> > > new file mode 100644
> > > index 0000000000..5f131023ba
> > > --- /dev/null
> > > +++ b/include/exec/confidential-guest-support.h
> > > @@ -0,0 +1,38 @@
> > > +/*
> > > + * QEMU Confidential Guest support
> > > + *   This interface describes the common pieces between various
> > > + *   schemes for protecting guest memory or other state against a
> > > + *   compromised hypervisor.  This includes memory encryption (AMD's
> > > + *   SEV and Intel's MKTME) or special protection modes (PEF on POWER,
> > > + *   or PV on s390x).
> > > + *
> > > + * 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_CONFIDENTIAL_GUEST_SUPPORT_H
> > > +#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
> > > +
> > > +#ifndef CONFIG_USER_ONLY
> > > +
> > > +#include "qom/object.h"
> > > +
> > > +#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
> > > +OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport, CONFIDENTIAL_GUEST_SUPPORT)
> > > +
> > > +struct ConfidentialGuestSupport {
> > > +    Object parent;
> > > +};
> > > +
> > > +typedef struct ConfidentialGuestSupportClass {
> > > +    ObjectClass parent;
> > > +} ConfidentialGuestSupportClass;
> > > +
> > > +#endif /* !CONFIG_USER_ONLY */
> > > +
> > > +#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
> > > diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> > > index 976b529dfb..33685c79ed 100644
> > > --- a/include/qemu/typedefs.h
> > > +++ b/include/qemu/typedefs.h
> > > @@ -36,6 +36,7 @@ typedef struct BusState BusState;
> > >  typedef struct Chardev Chardev;
> > >  typedef struct CompatProperty CompatProperty;
> > >  typedef struct CoMutex CoMutex;
> > > +typedef struct ConfidentialGuestSupport ConfidentialGuestSupport;
> > >  typedef struct CPUAddressSpace CPUAddressSpace;
> > >  typedef struct CPUState CPUState;
> > >  typedef struct DeviceListener DeviceListener;
> > > diff --git a/target/i386/sev.c b/target/i386/sev.c
> > > index 1546606811..6b49925f51 100644
> > > --- a/target/i386/sev.c
> > > +++ b/target/i386/sev.c
> > > @@ -31,6 +31,7 @@
> > >  #include "qom/object.h"
> > >  #include "exec/address-spaces.h"
> > >  #include "monitor/monitor.h"
> > > +#include "exec/confidential-guest-support.h"
> > >  
> > >  #define TYPE_SEV_GUEST "sev-guest"
> > >  OBJECT_DECLARE_SIMPLE_TYPE(SevGuestState, SEV_GUEST)
> > > @@ -322,7 +323,7 @@ sev_guest_instance_init(Object *obj)
> > >  
> > >  /* sev guest info */
> > >  static const TypeInfo sev_guest_info = {
> > > -    .parent = TYPE_OBJECT,
> > > +    .parent = TYPE_CONFIDENTIAL_GUEST_SUPPORT,
> > >      .name = TYPE_SEV_GUEST,
> > >      .instance_size = sizeof(SevGuestState),
> > >      .instance_finalize = sev_guest_finalize,
> 
> -- 
> 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


-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class

[David Gibson]

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

On Thu, Jan 21, 2021 at 09:08:07AM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (david@gibson.dropbear.id.au) wrote:
> > On Mon, Jan 18, 2021 at 06:51:24PM +0000, Dr. David Alan Gilbert wrote:
> > > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > > 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's MKTME can do
> > >                                                            ^^^^^
> > > (and below) My understanding is that it's Intel TDX that's the VM
> > > equivalent.
> > 
> > I thought MKTME could already do memory encryption and TDX extended
> > that to... more?  I'll adjust the comment to say TDX anyway, since
> > that seems to be the newer name.
> 
> My understanding was MKTME does the memory encryption, but doesn't
> explicitly wire that into VMs or attestation of VMs or anything like
> that.  TDX wires that encryption to VMs and provides all the other glue
> that goes with attestation and the like.

Ok.

-- 
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 --]

Re: [PATCH v7 09/13] confidential guest support: Update documentation

[David Gibson]

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

On Fri, Jan 15, 2021 at 04:36:46PM +0100, Cornelia Huck wrote:
> On Thu, 14 Jan 2021 10:58:07 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > Now that we've implemented a generic machine option for configuring various
> > confidential guest support mechanisms:
> >   1. Update docs/amd-memory-encryption.txt to reference this rather than
> >      the earlier SEV specific option
> >   2. Add a docs/confidential-guest-support.txt to cover the generalities of
> >      the confidential guest support scheme
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  docs/amd-memory-encryption.txt      |  2 +-
> >  docs/confidential-guest-support.txt | 43 +++++++++++++++++++++++++++++
> >  2 files changed, 44 insertions(+), 1 deletion(-)
> >  create mode 100644 docs/confidential-guest-support.txt
> > 
> > diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> > index 80b8eb00e9..145896aec7 100644
> > --- a/docs/amd-memory-encryption.txt
> > +++ b/docs/amd-memory-encryption.txt
> > @@ -73,7 +73,7 @@ complete flow chart.
> >  To launch a SEV guest
> >  
> >  # ${QEMU} \
> > -    -machine ...,memory-encryption=sev0 \
> > +    -machine ...,confidential-guest-support=sev0 \
> >      -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
> >  
> >  Debugging
> > diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
> > new file mode 100644
> > index 0000000000..2790425b38
> > --- /dev/null
> > +++ b/docs/confidential-guest-support.txt
> 
> Maybe make this a proper .rst from the start and hook this up into the
> system guide? It is already almost there.

Hrm.  I considered it, but didn't really want to spend the time
integrating it into the overall structure of the system guide.  I kind
of want to get this dang thing wrapped up.

> 
> > @@ -0,0 +1,43 @@
> > +Confidential Guest Support
> > +==========================
> > +
> > +Traditionally, hypervisors such as qemu have complete access to a
> 
> s/qemu/QEMU/ ?

Fixed.

> 
> > +guest's memory and other state, meaning that a compromised hypervisor
> > +can compromise any of its guests.  A number of platforms have added
> > +mechanisms in hardware and/or firmware which give guests at least some
> > +protection from a compromised hypervisor.  This is obviously
> > +especially desirable for public cloud environments.
> > +
> > +These mechanisms have different names and different modes of
> > +operation, but are often referred to as Secure Guests or Confidential
> > +Guests.  We use the term "Confidential Guest Support" to distinguish
> > +this from other aspects of guest security (such as security against
> > +attacks from other guests, or from network sources).
> > +
> > +Running a Confidential Guest
> > +----------------------------
> > +
> > +To run a confidential guest you need to add two command line parameters:
> > +
> > +1. Use "-object" to create a "confidential guest support" object.  The
> > +   type and parameters will vary with the specific mechanism to be
> > +   used
> > +2. Set the "confidential-guest-support" machine parameter to the ID of
> > +   the object from (1).
> > +
> > +Example (for AMD SEV)::
> > +
> > +    qemu-system-x86_64 \
> > +        <other parameters> \
> > +        -machine ...,confidential-guest-support=sev0 \
> > +        -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
> > +
> > +Supported mechanisms
> > +--------------------
> > +
> > +Currently supported confidential guest mechanisms are:
> > +
> > +AMD Secure Encrypted Virtualization (SEV)
> > +    docs/amd-memory-encryption.txt
> > +
> > +Other mechanisms may be supported in future.
> 
> LGTM.
> 

-- 
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 --]

Re: [PATCH v7 10/13] spapr: Add PEF based confidential guest support

[David Gibson]

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

On Fri, Jan 15, 2021 at 04:41:51PM +0100, Cornelia Huck wrote:
> On Thu, 14 Jan 2021 10:58:08 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > 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 confidential-guest-support
> > 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 directl 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 confidential-guest-support=pef0
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  docs/confidential-guest-support.txt |   3 +
> >  docs/papr-pef.txt                   |  30 +++++++
> >  hw/ppc/meson.build                  |   1 +
> >  hw/ppc/pef.c                        | 119 ++++++++++++++++++++++++++++
> >  hw/ppc/spapr.c                      |   6 ++
> >  include/hw/ppc/pef.h                |  25 ++++++
> >  target/ppc/kvm.c                    |  18 -----
> >  target/ppc/kvm_ppc.h                |   6 --
> >  8 files changed, 184 insertions(+), 24 deletions(-)
> >  create mode 100644 docs/papr-pef.txt
> >  create mode 100644 hw/ppc/pef.c
> >  create mode 100644 include/hw/ppc/pef.h
> > 
> > diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt
> > index 2790425b38..f0801814ff 100644
> > --- a/docs/confidential-guest-support.txt
> > +++ b/docs/confidential-guest-support.txt
> > @@ -40,4 +40,7 @@ Currently supported confidential guest mechanisms are:
> >  AMD Secure Encrypted Virtualization (SEV)
> >      docs/amd-memory-encryption.txt
> >  
> > +POWER Protected Execution Facility (PEF)
> > +    docs/papr-pef.txt
> > +
> >  Other mechanisms may be supported in future.
> > diff --git a/docs/papr-pef.txt b/docs/papr-pef.txt
> > new file mode 100644
> > index 0000000000..6419e995cf
> > --- /dev/null
> > +++ b/docs/papr-pef.txt
> 
> Same here, make this .rst and add it to the system guide?

Again, I feel like I'm sufficiently bogged down in bikeshedding the
technical details to feel inclined to block it on a nice-to-have like
this.

> > @@ -0,0 +1,30 @@
> > +POWER (PAPR) Protected Execution Facility (PEF)
> > +===============================================
> > +
> > +Protected Execution Facility (PEF), also known as Secure Guest support
> > +is a feature found on IBM POWER9 and POWER10 processors.
> > +
> > +If a suitable firmware including an Ultravisor is installed, it adds
> > +an extra memory protection mode to the CPU.  The ultravisor manages a
> > +pool of secure memory which cannot be accessed by the hypervisor.
> > +
> > +When this feature is enabled in qemu, a guest can use ultracalls to
> 
> s/qemu/QEMU/

Fixed.

> > +enter "secure mode".  This transfers most of its memory to secure
> > +memory, where it cannot be eavesdropped by a compromised hypervisor.
> > +
> > +Launching
> > +---------
> > +
> > +To launch a guest which will be permitted to enter PEF secure mode:
> > +
> > +# ${QEMU} \
> > +    -object pef-guest,id=pef0 \
> > +    -machine confidential-guest-support=pef0 \
> > +    ...
> > +
> > +Live Migration
> > +----------------
> > +
> > +Live migration is not yet implemented for PEF guests.  For
> > +consistency, we currently prevent migration if the PEF feature is
> > +enabled, whether or not the guest has actually entered secure mode.
> > diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
> > index ffa2ec37fa..218631c883 100644
> > --- a/hw/ppc/meson.build
> > +++ b/hw/ppc/meson.build
> > @@ -27,6 +27,7 @@ ppc_ss.add(when: 'CONFIG_PSERIES', if_true: files(
> >    'spapr_nvdimm.c',
> >    'spapr_rtas_ddw.c',
> >    'spapr_numa.c',
> > +  'pef.c',
> >  ))
> >  ppc_ss.add(when: 'CONFIG_SPAPR_RNG', if_true: files('spapr_rng.c'))
> >  ppc_ss.add(when: ['CONFIG_PSERIES', 'CONFIG_LINUX'], if_true: files(
> > diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c
> > new file mode 100644
> > index 0000000000..02b9b3b460
> > --- /dev/null
> > +++ b/hw/ppc/pef.c
> > @@ -0,0 +1,119 @@
> > +/*
> > + * PEF (Protected Execution Facility) for POWER support
> > + *
> > + * Copyright David Gibson, Redhat Inc. 2020
> 
> 2021?

So, it happens that in the meantime I've had different cause to look
up what Red Hat actually recommends as the copyright notice in open
source files, and it turns out they suggest simply "Copyright Red
Hat", with no names or dates.  So I'll switch to that for all the new
files in the series.

> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> 

-- 
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 --]

Re: [PATCH v7 08/13] confidential guest support: Move SEV initialization into arch specific code

[David Gibson]

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

On Mon, Jan 18, 2021 at 09:03:36AM +0100, Cornelia Huck wrote:
> On Mon, 18 Jan 2021 14:03:08 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Fri, Jan 15, 2021 at 02:24:25PM +0100, Cornelia Huck wrote:
> > > On Thu, 14 Jan 2021 10:58:06 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >   
> > > > While we've abstracted some (potential) differences between mechanisms for
> > > > securing guest memory, the initialization is still specific to SEV.  Given
> > > > that, move it into x86's kvm_arch_init() code, rather than the generic
> > > > kvm_init() code.
> > > > 
> > > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > > ---
> > > >  accel/kvm/kvm-all.c   | 14 --------------
> > > >  accel/kvm/sev-stub.c  |  4 ++--
> > > >  target/i386/kvm/kvm.c | 12 ++++++++++++
> > > >  target/i386/sev.c     |  7 ++++++-
> > > >  4 files changed, 20 insertions(+), 17 deletions(-)
> > > >   
> > > 
> > > (...)
> > >   
> > > > @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> > > >      uint64_t shadow_mem;
> > > >      int ret;
> > > >      struct utsname utsname;
> > > > +    Error *local_err = NULL;
> > > > +
> > > > +    /*
> > > > +     * if memory encryption object is specified then initialize the
> > > > +     * memory encryption context (no-op otherwise)
> > > > +     */
> > > > +    ret = sev_kvm_init(ms->cgs, &local_err);  
> > > 
> > > Maybe still leave a comment here, as the code will still need to be
> > > modified to handle non-SEV x86 mechanisms?  
> > 
> > Uh.. I'm confused.. this hunk is adding a comment, not removing one..
> 
> Yes, but there was a "TODO: handle non-SEV" comment before. This will
> probably need some massaging if we add Intel mechanisms?

Technically, not exactly.  New mechanisms would have their own
initialization, which might go adjacent to this, or could be somewhere
else - the sev_kvm_init() is a no-op if a non-SEV mechanism is
selected (currently impossible).

The distinction is pretty subtle, though, so I've altered the comment
here in a way I hope explains it.

-- 
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 --]

Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag

[David Gibson]

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

On Tue, Jan 19, 2021 at 09:16:08AM +0100, Cornelia Huck wrote:
> On Mon, 18 Jan 2021 19:47:30 +0000
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> 
> > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > The platform specific details of mechanisms for implementing
> > > confidential guest support may require setup at various points during
> > > initialization.  Thus, it's not really feasible to have a single cgs
> > > initialization hook, but instead each mechanism needs its own
> > > initialization calls in arch or machine specific code.
> > > 
> > > However, to make it harder to have a bug where a mechanism isn't
> > > properly initialized under some circumstances, we want to have a
> > > common place, relatively late in boot, where we verify that cgs has
> > > been initialized if it was requested.
> > > 
> > > This patch introduces a ready flag to the ConfidentialGuestSupport
> > > base type to accomplish this, which we verify just before the machine
> > > specific initialization function.  
> > 
> > You may find you need to define 'ready' and the answer might be a bit
> > variable; for example, on SEV there's a setup bit and then you may end
> > up doing an attestation and receiving some data before you actaully let
> > the guest execute code.   Is it ready before it's received the
> > attestation response or only when it can run code?
> > Is a Power or 390 machine 'ready' before it's executed the magic
> > instruction to enter the confidential mode?
> 
> I would consider those machines where the guest makes the transition
> itself "ready" as soon as everything is set up so that the guest can
> actually initiate the transition. Otherwise, those machines would never
> be "ready" if the guest does not transition.
> 
> Maybe we can define "ready" as "the guest can start to execute in
> secure mode", where "guest" includes the bootloader and everything that
> runs in a guest context, and "start to execute" implies that some setup
> may be done only after the guest has kicked it off?

That was pretty much my intention.  I've put a big comment on the
field definition and tweaked things around a bit in the hopes of
making that clearer for the next spin.


-- 
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 --]