On Fri, Jun 19, 2020 at 10:28:22AM +0200, David Hildenbrand 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 :) Well, sure, but that's no *more* true if we start from a common point. > > 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 ... :) ) I don't love the name, it's just the best I've thought of so far. > "host-trust-limitation" sounds like "I am the hypervisor, I configure > limited trust into myself". Which is kind of... accurate... > 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? That's why it takes a parameter. It points to an object which can itself have more properties to configure the details. SEV already needs that set up, though for both PEF and s390 PV we could pre-create a standard htl object. > > 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. I don't really understand why you're so against setting the cpu default parameters from the machine. The machine already sets basic configuration for all sorts of devices in the VM, that's kind of what it's for. > How do upper layers actually figure out if memory encryption etc is > available? on s390x, it's simply via the expanded host CPU model. Haven't really tackled that yet. But one way that works for multiple systems has got to be better than a separate one for each, right? -- 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
