[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2 00/18] Refactor configuration of guest memory protection
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [RFC v2 00/18] Refactor configuration of guest memory protection |
Date: |
Mon, 1 Jun 2020 10:16:18 +0100 |
User-agent: |
Mutt/1.13.4 (2020-02-15) |
* Sean Christopherson (sean.j.christopherson@intel.com) wrote:
> On Thu, May 21, 2020 at 01:42:46PM +1000, 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
> > "guest-memory-protection" property pointing to a platform specific
> > object which configures and manages the specific details.
> >
> > For now this series covers just AMD SEV and POWER PEF. I'm hoping it
> > can be extended to cover the Intel and s390 mechanisms as well,
> > though.
> >
> > Note: I'm using the term "guest memory protection" throughout to refer
> > to mechanisms like this. I don't particular like the term, it's both
> > long and not really precise. If someone can think of a succinct way
> > of saying "a means of protecting guest memory from a possibly
> > compromised hypervisor", I'd be grateful for the suggestion.
>
> Many of the features are also going far beyond just protecting memory, so
> even the "memory" part feels wrong. Maybe something like protected-guest
> or secure-guest?
>
> A little imprecision isn't necessarily a bad thing, e.g. memory-encryption
> is quite precise, but also wrong once it encompasses anything beyond plain
> old encryption.
The common thread I think is 'untrusted host' - but I don't know of a
better way to describe that.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection,
Dr. David Alan Gilbert <=
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, David Gibson, 2020/06/04
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, Thiago Jung Bauermann, 2020/06/04
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, David Gibson, 2020/06/04
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, Thiago Jung Bauermann, 2020/06/04
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, Paolo Bonzini, 2020/06/04
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, Thiago Jung Bauermann, 2020/06/04
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, Paolo Bonzini, 2020/06/04
- Re: [RFC v2 00/18] Refactor configuration of guest memory protection, Thiago Jung Bauermann, 2020/06/05