[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [for-6.0 v5 00/13] Generalize memory encryption models
From: |
Cornelia Huck |
Subject: |
Re: [for-6.0 v5 00/13] Generalize memory encryption models |
Date: |
Thu, 17 Dec 2020 12:43:13 +0100 |
On Thu, 17 Dec 2020 17:21:16 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Tue, Dec 08, 2020 at 01:43:08PM +0100, Cornelia Huck wrote:
> > On Tue, 8 Dec 2020 13:57:28 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > On Fri, Dec 04, 2020 at 02:12:29PM +0100, Cornelia Huck wrote:
> > > > On Fri, 4 Dec 2020 13:07:27 +0000
> > > > "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> > > >
> > > > > * Cornelia Huck (cohuck@redhat.com) wrote:
> > > > > > On Fri, 4 Dec 2020 09:06:50 +0100
> > > > > > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> > > > > >
> > > > > > > On 04.12.20 06:44, 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
> > > > > > > > "securable-guest-memory" property pointing to a platform
> > > > > > > > specific
> > > > > > >
> > > > > > > Can we do "securable-guest" ?
> > > > > > > s390x also protects registers and integrity. memory is only one
> > > > > > > piece
> > > > > > > of the puzzle and what we protect might differ from platform to
> > > > > > > platform.
> > > > > > >
> > > > > >
> > > > > > I agree. Even technologies that currently only do memory encryption
> > > > > > may
> > > > > > be enhanced with more protections later.
> > > > >
> > > > > There's already SEV-ES patches onlist for this on the SEV side.
> > > > >
> > > > > <sigh on haggling over the name>
> > > > >
> > > > > Perhaps 'confidential guest' is actually what we need, since the
> > > > > marketing folks seem to have started labelling this whole idea
> > > > > 'confidential computing'.
> > >
> > > That's not a bad idea, much as I usually hate marketing terms. But it
> > > does seem to be becoming a general term for this style of thing, and
> > > it doesn't overlap too badly with other terms ("secure" and
> > > "protected" are also used for hypervisor-from-guest and
> > > guest-from-guest protection).
> > >
> > > > It's more like a 'possibly confidential guest', though.
> > >
> > > Hmm. What about "Confidential Guest Facility" or "Confidential Guest
> > > Mechanism"? The implication being that the facility is there, whether
> > > or not the guest actually uses it.
> > >
> >
> > "Confidential Guest Enablement"? The others generally sound fine to me
> > as well, though; not sure if "Facility" might be a bit confusing, as
> > that term is already a bit overloaded.
>
> Well, "facility" is a bit overloaded, but IMO "enablement" is even
> more so. I think I'll go with "confidential guest support" in the
> next spin.
>
Works for me.
pgpsJXQB0ipeV.pgp
Description: OpenPGP digital signature
- [for-6.0 v5 13/13] s390: Recognize securable-guest-memory option, (continued)
- [for-6.0 v5 13/13] s390: Recognize securable-guest-memory option, David Gibson, 2020/12/04
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, Christian Borntraeger, 2020/12/04
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, Cornelia Huck, 2020/12/04
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, Dr. David Alan Gilbert, 2020/12/04
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, Cornelia Huck, 2020/12/04
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, David Gibson, 2020/12/07
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, Cornelia Huck, 2020/12/08
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, David Gibson, 2020/12/17
- Re: [for-6.0 v5 00/13] Generalize memory encryption models,
Cornelia Huck <=
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, Daniel P . Berrangé, 2020/12/04
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, Halil Pasic, 2020/12/04
- Re: [for-6.0 v5 00/13] Generalize memory encryption models, David Gibson, 2020/12/07
Re: [for-6.0 v5 00/13] Generalize memory encryption models, Daniel P . Berrangé, 2020/12/04