qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Gibson
Subject: Re: [for-6.0 v5 00/13] Generalize memory encryption models
Date: Tue, 8 Dec 2020 13:54:27 +1100

On Fri, Dec 04, 2020 at 02:02:05PM +0100, Cornelia Huck 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.

That's a good point.  I've focused on the memory aspect because that's
what's most immediately relevant to qemu - the fact that we can't
directly access guest memory is something we have to deal with, and
has some uniformity regardless of the details of the protection scheme.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]