On Fri, 4 Dec 2020 13:25:00 +0000 Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > On Fri, Dec 04, 2020 at 01:07:27PM +0000, Dr. David Alan Gilbert wrote: > > * Cornelia Huck (cohuck@xxxxxxxxxx) wrote: > > > On Fri, 4 Dec 2020 09:06:50 +0100 > > > Christian Borntraeger <borntraeger@xxxxxxxxxx> 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
