[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [for-6.0 v5 00/13] Generalize memory encryption models
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [for-6.0 v5 00/13] Generalize memory encryption models |
Date: |
Fri, 4 Dec 2020 13:07:27 +0000 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
* 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'.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- Re: [for-6.0 v5 12/13] securable guest memory: Alter virtio default properties for protected guests, (continued)
Re: [for-6.0 v5 12/13] securable guest memory: Alter virtio default properties for protected guests, Cornelia Huck, 2020/12/04
[for-6.0 v5 10/13] spapr: Add PEF based securable guest memory, David Gibson, 2020/12/04
[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 <=
- 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, 2020/12/17
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