Re: [PATCH v3 0/9] Generalize memory encryption models

[David Hildenbrand]

On 19.06.20 04:05, 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.

Each architecture finds its own way to vandalize the original
architecture, some in more extreme/obscure ways than others. I guess in
the long term we'll regret most of that, but what do I know :)

> 
> 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
> "host-trust-limitation" property pointing to a platform specific
> object which configures and manages the specific details.
> 

I consider the property name sub-optimal. Yes, I am aware that there are
other approaches being discussed on the KVM list to disallow access to
guest memory without memory encryption. (most of them sound like people
are trying to convert KVM into XEN, but again, what do I know ... :)  )

"host-trust-limitation"  sounds like "I am the hypervisor, I configure
limited trust into myself". Also, "untrusted-host" would be a little bit
nicer (I think trust is a black/white thing).

However, once we have multiple options to protect a guest (memory
encryption, unmapping guest pages ,...) the name will no longer really
suffice to configure QEMU, no?

> 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.

The only approach on s390x to not glue command line properties to the
cpu model would be to remove the CPU model feature and replace it by the
command line parameter. But that would, of course, be an incompatible break.

How do upper layers actually figure out if memory encryption etc is
available? on s390x, it's simply via the expanded host CPU model.

-- 
Thanks,

David / dhildenb