On Fri, 19 Jun 2020 10:28:22 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote: > 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? Hm... we could have a property that accepts bits indicating where the actual limitation lies. Different parts of the code could then make more fine-grained decisions of what needs to be done. Feels a bit overengineered today; but maybe there's already stuff with different semantics in the pipeline somewhere? > > > 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. Yuck. We still need to provide the cpu feature to the *guest* in any case, no? > > How do upper layers actually figure out if memory encryption etc is > available? on s390x, it's simply via the expanded host CPU model. >
