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
