On Fri, Jun 05, 2020 at 12:55:05PM +0200, Cornelia Huck wrote: > On Thu, 21 May 2020 13:42:46 +1000 > David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> 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. > > For s390, there's the 'unpack' cpu facility bit, which is indicated iff > the kernel indicates availability of the feature (depending on hardware > support). If that cpu facility is available, a guest can choose to > transition into protected mode. The current state (protected mode or > not) is tracked in the s390 ccw machine. > > If I understand the series here correctly (I only did a quick > read-through), the user has to instruct QEMU to make protection > available, via a new machine property that links to an object? Correct. We used to have basically the same model for POWER - the guest just talks to the ultravisor to enter secure mode. But we realized that model is broken. You're effectively advertising availability of a guest hardware feature based on host kernel or hardware properties. That means if you try to migrate from a host with the facility to one without, you won't know there's a problem until too late. -- 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
