From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>,
qemu-devel@nongnu.org, brijesh.singh@amd.com, pair@us.ibm.com,
pbonzini@redhat.com, dgilbert@redhat.com, frankja@linux.ibm.com,
Eduardo Habkost <ehabkost@redhat.com>,
kvm@vger.kernel.org, mst@redhat.com, david@redhat.com,
mdroth@linux.vnet.ibm.com, pasic@linux.ibm.com,
qemu-s390x@nongnu.org, qemu-ppc@nongnu.org,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v3 0/9] Generalize memory encryption models
Date: Wed, 24 Jun 2020 09:06:48 +0200 [thread overview]
Message-ID: <20200624090648.6bdf82bd.cohuck@redhat.com> (raw)
In-Reply-To: <2fa7c84a-6929-ef04-1d61-f76a4cac35f5@de.ibm.com>
On Mon, 22 Jun 2020 16:27:28 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> On 19.06.20 04:05, David Gibson wrote:
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate the security impact of a compromised hypervisor.
> >
> > AMD's SEV implements this with in-cpu memory encryption, and Intel has
> > its own memory encryption mechanism. POWER has an upcoming mechanism
> > to accomplish this in a different way, using a new memory protection
> > level plus a small trusted ultravisor. s390 also has a protected
> > execution environment.
> >
> > The current code (committed or draft) for these features has each
> > platform's version configured entirely differently. That doesn't seem
> > ideal for users, or particularly for management layers.
> >
> > AMD SEV introduces a notionally generic machine option
> > "machine-encryption", but it doesn't actually cover any cases other
> > than SEV.
> >
> > This series is a proposal to at least partially unify configuration
> > for these mechanisms, by renaming and generalizing AMD's
> > "memory-encryption" property. It is replaced by a
> > "host-trust-limitation" property pointing to a platform specific
> > object which configures and manages the specific details.
> >
> > For now this series covers just AMD SEV and POWER PEF. I'm hoping it
> > can be extended to cover the Intel and s390 mechanisms as well,
> > though.
>
> Let me try to summarize what I understand what you try to achieve:
> one command line parameter for all platforms that
>
> common across all platforms:
> - disable KSM
> - by default enables iommu_platform
>
>
> per platform:
> - setup the necessary encryption scheme when appropriate
> - block migration
> -....
>
>
> The tricky part is certainly the per platform thing. For example on
> s390 we just have a cpumodel flag that provides interfaces to the guest
> to switch into protected mode via the ultravisor. This works perfectly
> fine with the host model, so no need to configure anything. The platform
> code then disables KSM _on_switchover_ and not in general. Because the
> guest CAN switch into protected, but it does not have to.
>
> So this feels really hard to do right. Would a virtual BoF on KVM forum
> be too late? We had a BoF on protected guests last year and that was
> valuable.
Maybe we can do some kind of call to discuss this earlier? (Maybe in
the KVM call slot on Tuesdays?) I think it would be really helpful if
everybody would have at least a general understanding about how
encryption/protection works on the different architectures.
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: pair@us.ibm.com, brijesh.singh@amd.com, frankja@linux.ibm.com,
kvm@vger.kernel.org, mst@redhat.com, david@redhat.com,
qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>,
dgilbert@redhat.com, pasic@linux.ibm.com, qemu-s390x@nongnu.org,
qemu-ppc@nongnu.org, pbonzini@redhat.com,
Richard Henderson <rth@twiddle.net>,
mdroth@linux.vnet.ibm.com,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v3 0/9] Generalize memory encryption models
Date: Wed, 24 Jun 2020 09:06:48 +0200 [thread overview]
Message-ID: <20200624090648.6bdf82bd.cohuck@redhat.com> (raw)
In-Reply-To: <2fa7c84a-6929-ef04-1d61-f76a4cac35f5@de.ibm.com>
On Mon, 22 Jun 2020 16:27:28 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> On 19.06.20 04:05, David Gibson wrote:
> > A number of hardware platforms are implementing mechanisms whereby the
> > hypervisor does not have unfettered access to guest memory, in order
> > to mitigate the security impact of a compromised hypervisor.
> >
> > AMD's SEV implements this with in-cpu memory encryption, and Intel has
> > its own memory encryption mechanism. POWER has an upcoming mechanism
> > to accomplish this in a different way, using a new memory protection
> > level plus a small trusted ultravisor. s390 also has a protected
> > execution environment.
> >
> > The current code (committed or draft) for these features has each
> > platform's version configured entirely differently. That doesn't seem
> > ideal for users, or particularly for management layers.
> >
> > AMD SEV introduces a notionally generic machine option
> > "machine-encryption", but it doesn't actually cover any cases other
> > than SEV.
> >
> > This series is a proposal to at least partially unify configuration
> > for these mechanisms, by renaming and generalizing AMD's
> > "memory-encryption" property. It is replaced by a
> > "host-trust-limitation" property pointing to a platform specific
> > object which configures and manages the specific details.
> >
> > For now this series covers just AMD SEV and POWER PEF. I'm hoping it
> > can be extended to cover the Intel and s390 mechanisms as well,
> > though.
>
> Let me try to summarize what I understand what you try to achieve:
> one command line parameter for all platforms that
>
> common across all platforms:
> - disable KSM
> - by default enables iommu_platform
>
>
> per platform:
> - setup the necessary encryption scheme when appropriate
> - block migration
> -....
>
>
> The tricky part is certainly the per platform thing. For example on
> s390 we just have a cpumodel flag that provides interfaces to the guest
> to switch into protected mode via the ultravisor. This works perfectly
> fine with the host model, so no need to configure anything. The platform
> code then disables KSM _on_switchover_ and not in general. Because the
> guest CAN switch into protected, but it does not have to.
>
> So this feels really hard to do right. Would a virtual BoF on KVM forum
> be too late? We had a BoF on protected guests last year and that was
> valuable.
Maybe we can do some kind of call to discuss this earlier? (Maybe in
the KVM call slot on Tuesdays?) I think it would be really helpful if
everybody would have at least a general understanding about how
encryption/protection works on the different architectures.
next prev parent reply other threads:[~2020-06-24 7:07 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-19 2:05 [PATCH v3 0/9] Generalize memory encryption models David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 1/9] host trust limitation: Introduce new host trust limitation interface David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-26 11:01 ` Dr. David Alan Gilbert
2020-06-26 11:01 ` Dr. David Alan Gilbert
2020-07-14 19:26 ` Richard Henderson
2020-07-14 19:26 ` Richard Henderson
2020-06-19 2:05 ` [PATCH v3 2/9] host trust limitation: Handle memory encryption via interface David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 3/9] host trust limitation: Move side effect out of machine_set_memory_encryption() David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 4/9] host trust limitation: Rework the "memory-encryption" property David Gibson
2020-06-19 2:05 ` David Gibson
2020-07-14 19:36 ` Richard Henderson
2020-07-14 19:36 ` Richard Henderson
2020-06-19 2:05 ` [PATCH v3 5/9] host trust limitation: Decouple kvm_memcrypt_*() helpers from KVM David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:05 ` [PATCH v3 6/9] host trust limitation: Add Error ** to HostTrustLimitation::kvm_init David Gibson
2020-06-19 2:05 ` David Gibson
2020-06-19 2:06 ` [PATCH v3 7/9] spapr: Add PEF based host trust limitation David Gibson
2020-06-19 2:06 ` David Gibson
2020-06-19 2:06 ` [PATCH v3 8/9] spapr: PEF: block migration David Gibson
2020-06-19 2:06 ` David Gibson
2020-06-26 10:33 ` Dr. David Alan Gilbert
2020-06-26 10:33 ` Dr. David Alan Gilbert
2020-07-05 7:38 ` David Gibson
2020-07-05 7:38 ` David Gibson
2020-06-19 2:06 ` [PATCH v3 9/9] host trust limitation: Alter virtio default properties for protected guests David Gibson
2020-06-19 2:06 ` David Gibson
2020-06-19 10:12 ` Daniel P. Berrangé
2020-06-19 10:12 ` Daniel P. Berrangé
2020-06-19 11:46 ` Michael S. Tsirkin
2020-06-19 11:46 ` Michael S. Tsirkin
2020-06-19 11:47 ` Michael S. Tsirkin
2020-06-19 11:47 ` Michael S. Tsirkin
2020-06-19 12:16 ` Daniel P. Berrangé
2020-06-19 12:16 ` Daniel P. Berrangé
2020-06-19 20:04 ` Halil Pasic
2020-06-19 20:04 ` Halil Pasic
2020-06-24 7:55 ` Michael S. Tsirkin
2020-06-24 7:55 ` Michael S. Tsirkin
2020-06-25 4:57 ` David Gibson
2020-06-25 4:57 ` David Gibson
2020-06-25 5:02 ` David Gibson
2020-06-25 5:02 ` David Gibson
2020-06-19 14:45 ` David Gibson
2020-06-19 14:45 ` David Gibson
2020-06-19 15:05 ` Daniel P. Berrangé
2020-06-19 15:05 ` Daniel P. Berrangé
2020-06-20 8:24 ` David Gibson
2020-06-20 8:24 ` David Gibson
2020-06-22 9:09 ` Daniel P. Berrangé
2020-06-22 9:09 ` Daniel P. Berrangé
2020-06-25 5:06 ` David Gibson
2020-06-25 5:06 ` David Gibson
2020-06-19 2:42 ` [PATCH v3 0/9] Generalize memory encryption models no-reply
2020-06-19 2:42 ` no-reply
2020-06-19 8:28 ` David Hildenbrand
2020-06-19 8:28 ` David Hildenbrand
2020-06-19 9:45 ` Cornelia Huck
2020-06-19 9:45 ` Cornelia Huck
2020-06-19 9:56 ` David Hildenbrand
2020-06-19 9:56 ` David Hildenbrand
2020-06-19 10:05 ` Cornelia Huck
2020-06-19 10:05 ` Cornelia Huck
2020-06-19 10:10 ` David Hildenbrand
2020-06-19 10:10 ` David Hildenbrand
2020-06-22 12:02 ` Cornelia Huck
2020-06-22 12:02 ` Cornelia Huck
2020-06-25 5:25 ` David Gibson
2020-06-25 5:25 ` David Gibson
2020-06-25 7:06 ` David Hildenbrand
2020-06-25 7:06 ` David Hildenbrand
2020-06-26 4:42 ` David Gibson
2020-06-26 4:42 ` David Gibson
2020-06-26 6:53 ` David Hildenbrand
2020-06-26 6:53 ` David Hildenbrand
2020-06-26 9:01 ` Janosch Frank
2020-06-26 9:01 ` Janosch Frank
2020-06-26 9:32 ` Daniel P. Berrangé
2020-06-26 9:32 ` Daniel P. Berrangé
2020-06-26 9:49 ` Janosch Frank
2020-06-26 9:49 ` Janosch Frank
2020-06-26 10:29 ` Dr. David Alan Gilbert
2020-06-26 10:29 ` Dr. David Alan Gilbert
2020-06-26 10:58 ` Daniel P. Berrangé
2020-06-26 10:58 ` Daniel P. Berrangé
2020-06-26 12:49 ` Janosch Frank
2020-06-26 12:49 ` Janosch Frank
2020-07-01 11:59 ` Halil Pasic
2020-07-01 11:59 ` Halil Pasic
2020-06-19 9:48 ` David Gibson
2020-06-19 9:48 ` David Gibson
2020-06-19 10:04 ` David Hildenbrand
2020-06-19 10:04 ` David Hildenbrand
2020-06-25 5:42 ` David Gibson
2020-06-25 5:42 ` David Gibson
2020-06-25 6:59 ` David Hildenbrand
2020-06-25 6:59 ` David Hildenbrand
2020-06-25 9:49 ` Cornelia Huck
2020-06-25 9:49 ` Cornelia Huck
2020-06-22 14:27 ` Christian Borntraeger
2020-06-22 14:27 ` Christian Borntraeger
2020-06-24 7:06 ` Cornelia Huck [this message]
2020-06-24 7:06 ` Cornelia Huck
2020-06-25 5:47 ` David Gibson
2020-06-25 5:47 ` David Gibson
2020-06-25 5:48 ` David Gibson
2020-06-25 5:48 ` David Gibson
2020-06-25 5:44 ` David Gibson
2020-06-25 5:44 ` David Gibson
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=20200624090648.6bdf82bd.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=brijesh.singh@amd.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=pair@us.ibm.com \
--cc=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 \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.