From: Janosch Frank <frankja@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Cc: pair@us.ibm.com, brijesh.singh@amd.com, ehabkost@redhat.com,
kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
dgilbert@redhat.com, qemu-devel@nongnu.org, pasic@linux.ibm.com,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, qemu-ppc@nongnu.org,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
pbonzini@redhat.com, mdroth@linux.vnet.ibm.com,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option
Date: Mon, 3 Aug 2020 09:40:29 +0200 [thread overview]
Message-ID: <2967ea9e-9d6d-51bd-bf0e-4aae15c63fbb@linux.ibm.com> (raw)
In-Reply-To: <20200727175040.7beca3dd.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 5130 bytes --]
On 7/27/20 5:50 PM, Cornelia Huck wrote:
> On Fri, 24 Jul 2020 12:57:44 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> At least some s390 cpu models support "Protected Virtualization" (PV),
>> a mechanism to protect guests from eavesdropping by a compromised
>> hypervisor.
>>
>> This is similar in function to other mechanisms like AMD's SEV and
>> POWER's PEF, which are controlled bythe "host-trust-limitation"
>> machine option. s390 is a slightly special case, because we already
>> supported PV, simply by using a CPU model with the required feature
>> (S390_FEAT_UNPACK).
>>
>> To integrate this with the option used by other platforms, we
>> implement the following compromise:
>>
>> - When the host-trust-limitation option is set, s390 will recognize
>> it, verify that the CPU can support PV (failing if not) and set
>> virtio default options necessary for encrypted or protected guests,
>> as on other platforms. i.e. if host-trust-limitation is set, we
>> will either create a guest capable of entering PV mode, or fail
>> outright
>>
>> - If host-trust-limitation is not set, guest's might still be able to
>> enter PV mode, if the CPU has the right model. This may be a
>> little surprising, but shouldn't actually be harmful.
>
> This could be workable, I guess. Would like a second opinion, though.
>
>>
>> To start a guest supporting Protected Virtualization using the new
>> option use the command line arguments:
>> -object s390-pv-guest,id=pv0 -machine host-trust-limitation=pv0
>>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>> ---
>> hw/s390x/pv.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 61 insertions(+)
>>
>> diff --git a/hw/s390x/pv.c b/hw/s390x/pv.c
>> index ab3a2482aa..4bf3b345b6 100644
>> --- a/hw/s390x/pv.c
>> +++ b/hw/s390x/pv.c
>> @@ -14,8 +14,11 @@
>> #include <linux/kvm.h>
>>
>> #include "cpu.h"
>> +#include "qapi/error.h"
>> #include "qemu/error-report.h"
>> #include "sysemu/kvm.h"
>> +#include "qom/object_interfaces.h"
>> +#include "exec/host-trust-limitation.h"
>> #include "hw/s390x/ipl.h"
>> #include "hw/s390x/pv.h"
>>
>> @@ -111,3 +114,61 @@ void s390_pv_inject_reset_error(CPUState *cs)
>> /* Report that we are unable to enter protected mode */
>> env->regs[r1 + 1] = DIAG_308_RC_INVAL_FOR_PV;
>> }
>> +
>> +#define TYPE_S390_PV_GUEST "s390-pv-guest"
>> +#define S390_PV_GUEST(obj) \
>> + OBJECT_CHECK(S390PVGuestState, (obj), TYPE_S390_PV_GUEST)
>> +
>> +typedef struct S390PVGuestState S390PVGuestState;
>> +
>> +/**
>> + * S390PVGuestState:
>> + *
>> + * The S390PVGuestState object is basically a dummy used to tell the
>> + * host trust limitation system to use s390's PV mechanism. guest.
>> + *
>> + * # $QEMU \
>> + * -object s390-pv-guest,id=pv0 \
>> + * -machine ...,host-trust-limitation=pv0
>> + */
>> +struct S390PVGuestState {
>> + Object parent_obj;
>> +};
>> +
>> +static int s390_pv_kvm_init(HostTrustLimitation *gmpo, Error **errp)
>> +{
>> + if (!s390_has_feat(S390_FEAT_UNPACK)) {
>> + error_setg(errp,
>> + "CPU model does not support Protected Virtualization");
>> + return -1;
>> + }
>> +
>> + return 0;
>> +}
>
> So here's where I'm confused: If I follow the code correctly, the
> ->kvm_init callback is invoked before kvm_arch_init() is called. The
> kvm_arch_init() implementation for s390x checks whether
> KVM_CAP_S390_PROTECTED is available, which is a pre-req for
> S390_FEAT_UNPACK. Am I missing something? Can someone with access to PV
> hardware check whether this works as intended?
Doesn't look good:
./s390x-run s390x/stsi.img -object s390-pv-guest,id=pv0 -machine
host-trust-limitation=pv0
/usr/local/bin/qemu-system-s390x -nodefaults -nographic -machine
s390-ccw-virtio,accel=kvm -chardev stdio,id=con0 -device
sclpconsole,chardev=con0 -kernel s390x/stsi.img -object
s390-pv-guest,id=pv0 -machine host-trust-limitation=pv0 # -initrd
/tmp/tmp.uacr85fJnw
qemu-system-s390x: CPU model does not support Protected Virtualization
qemu-system-s390x: failed to initialize kvm: Operation not permitted
Without the htl it's happy.
>
>> +
>> +static void s390_pv_guest_class_init(ObjectClass *oc, void *data)
>> +{
>> + HostTrustLimitationClass *gmpc = HOST_TRUST_LIMITATION_CLASS(oc);
>> +
>> + gmpc->kvm_init = s390_pv_kvm_init;
>> +}
>> +
>> +static const TypeInfo s390_pv_guest_info = {
>> + .parent = TYPE_OBJECT,
>> + .name = TYPE_S390_PV_GUEST,
>> + .instance_size = sizeof(S390PVGuestState),
>> + .class_init = s390_pv_guest_class_init,
>> + .interfaces = (InterfaceInfo[]) {
>> + { TYPE_HOST_TRUST_LIMITATION },
>> + { TYPE_USER_CREATABLE },
>> + { }
>> + }
>> +};
>> +
>> +static void
>> +s390_pv_register_types(void)
>> +{
>> + type_register_static(&s390_pv_guest_info);
>> +}
>> +
>> +type_init(s390_pv_register_types);
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-03 7:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 2:57 [for-5.2 v4 00/10] Generalize memory encryption models David Gibson
2020-07-24 2:57 ` [for-5.2 v4 01/10] host trust limitation: Introduce new host trust limitation interface David Gibson
2020-07-24 2:57 ` [for-5.2 v4 02/10] host trust limitation: Handle memory encryption via interface David Gibson
2020-07-24 2:57 ` [for-5.2 v4 03/10] host trust limitation: Move side effect out of machine_set_memory_encryption() David Gibson
2020-07-24 2:57 ` [for-5.2 v4 04/10] host trust limitation: Rework the "memory-encryption" property David Gibson
2020-07-24 2:57 ` [for-5.2 v4 05/10] host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM David Gibson
2020-07-24 2:57 ` [for-5.2 v4 06/10] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init David Gibson
2020-07-24 2:57 ` [for-5.2 v4 07/10] spapr: Add PEF based host trust limitation David Gibson
2020-07-24 2:57 ` [for-5.2 v4 08/10] spapr: PEF: block migration David Gibson
2020-07-27 15:01 ` Dr. David Alan Gilbert
2020-07-24 2:57 ` [for-5.2 v4 09/10] host trust limitation: Alter virtio default properties for protected guests David Gibson
2020-07-27 15:05 ` Dr. David Alan Gilbert
2020-08-13 7:43 ` Greg Kurz
2020-08-13 8:19 ` Greg Kurz
2020-09-07 15:10 ` Halil Pasic
2020-09-11 2:04 ` David Gibson
2020-09-11 13:49 ` Halil Pasic
2020-07-24 2:57 ` [for-5.2 v4 10/10] s390: Recognize host-trust-limitation option David Gibson
2020-07-27 15:50 ` Cornelia Huck
2020-08-03 7:40 ` Janosch Frank [this message]
2020-08-06 6:14 ` David Gibson
2020-08-06 7:18 ` David Hildenbrand
2020-08-03 7:49 ` Janosch Frank
2020-08-03 7:54 ` David Gibson
2020-08-03 8:07 ` Janosch Frank
2020-08-03 8:14 ` David Gibson
2020-08-03 8:33 ` Cornelia Huck
2020-09-07 15:22 ` Halil Pasic
2020-09-10 11:36 ` Cornelia Huck
2020-09-10 18:29 ` Halil Pasic
2020-09-11 0:07 ` David Gibson
2020-09-11 6:25 ` Greg Kurz
2020-09-11 12:45 ` Halil Pasic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2967ea9e-9d6d-51bd-bf0e-4aae15c63fbb@linux.ibm.com \
--to=frankja@linux.ibm.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=brijesh.singh@amd.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=pair@us.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).