On Sat, 6 Jun 2020 18:44:09 +1000 David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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. > Sorry, I don't quite understand the migration problem described here. If you have this modeled via a CPU model facility, then you can't migrate from a host with the facility to one without, except if the user specified CPU model does not include the facility in question. Or am I missing something? Regards, Halil
Attachment:
pgpqauv0ujU8T.pgp
Description: OpenPGP digital signature
