Re: [for-6.0 v5 00/13] Generalize memory encryption models

From: Halil Pasic <pasic@linux.ibm.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	pair@us.ibm.com, brijesh.singh@amd.com, frankja@linux.ibm.com,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	david@redhat.com, qemu-devel@nongnu.org,
	Eduardo Habkost <ehabkost@redhat.com>,
	mdroth@linux.vnet.ibm.com,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, qemu-ppc@nongnu.org, thuth@redhat.com,
	pbonzini@redhat.com, rth@twiddle.net,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [for-6.0 v5 00/13] Generalize memory encryption models
Date: Fri, 4 Dec 2020 14:51:52 +0100	[thread overview]
Message-ID: <20201204145152.097bb217.pasic@linux.ibm.com> (raw)
In-Reply-To: <20201204132500.GI3056135@redhat.com>

On Fri, 4 Dec 2020 13:25:00 +0000
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Fri, Dec 04, 2020 at 01:07:27PM +0000, Dr. David Alan Gilbert 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'.
> 
> I think we shouldn't worry about the specific name too much, as it
> won't be visible much outside QEMU and the internals of the immediate
> layer above such as libvirt. What matters much more is that we have
> documentation that clearly explains what the different levels of
> protection are for each different architecture, and/or generation of
> architecture. Mgmt apps / end users need understand exactly what
> kind of unicorns they are being promised for a given configuration.
> 
>

You are probably right, but I still prefer descriptive names over
misleading ones -- it helps with my cognitive process.

Regards,
Halil