qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).