| Message ID | 20200521034304.340040-1-david@gibson.dropbear.id.au (mailing list archive) |
|---|---|
| Headers | show |
| Series | Refactor configuration of guest memory protection | expand |
On Thu, May 21, 2020 at 01:42:46PM +1000, 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. > > 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. > > Note: I'm using the term "guest memory protection" throughout to refer > to mechanisms like this. I don't particular like the term, it's both > long and not really precise. If someone can think of a succinct way > of saying "a means of protecting guest memory from a possibly > compromised hypervisor", I'd be grateful for the suggestion. Many of the features are also going far beyond just protecting memory, so even the "memory" part feels wrong. Maybe something like protected-guest or secure-guest? A little imprecision isn't necessarily a bad thing, e.g. memory-encryption is quite precise, but also wrong once it encompasses anything beyond plain old encryption.
* Sean Christopherson (sean.j.christopherson@intel.com) wrote: > On Thu, May 21, 2020 at 01:42:46PM +1000, 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. > > > > 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. > > > > Note: I'm using the term "guest memory protection" throughout to refer > > to mechanisms like this. I don't particular like the term, it's both > > long and not really precise. If someone can think of a succinct way > > of saying "a means of protecting guest memory from a possibly > > compromised hypervisor", I'd be grateful for the suggestion. > > Many of the features are also going far beyond just protecting memory, so > even the "memory" part feels wrong. Maybe something like protected-guest > or secure-guest? > > A little imprecision isn't necessarily a bad thing, e.g. memory-encryption > is quite precise, but also wrong once it encompasses anything beyond plain > old encryption. The common thread I think is 'untrusted host' - but I don't know of a better way to describe that. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Fri, May 29, 2020 at 03:19:26PM -0700, Sean Christopherson wrote: > On Thu, May 21, 2020 at 01:42:46PM +1000, 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. > > > > 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. > > > > Note: I'm using the term "guest memory protection" throughout to refer > > to mechanisms like this. I don't particular like the term, it's both > > long and not really precise. If someone can think of a succinct way > > of saying "a means of protecting guest memory from a possibly > > compromised hypervisor", I'd be grateful for the suggestion. > > Many of the features are also going far beyond just protecting memory, so > even the "memory" part feels wrong. Maybe something like protected-guest > or secure-guest? I think those are too vague. There are *heaps* of things related to protecting or securing guests, the relevance of this stuff is that it's protecting it from a compromised hypervisor. > A little imprecision isn't necessarily a bad thing, e.g. memory-encryption > is quite precise, but also wrong once it encompasses anything beyond plain > old encryption.
On Mon, Jun 01, 2020 at 10:16:18AM +0100, Dr. David Alan Gilbert wrote: > * Sean Christopherson (sean.j.christopherson@intel.com) wrote: > > On Thu, May 21, 2020 at 01:42:46PM +1000, 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. > > > > > > 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. > > > > > > Note: I'm using the term "guest memory protection" throughout to refer > > > to mechanisms like this. I don't particular like the term, it's both > > > long and not really precise. If someone can think of a succinct way > > > of saying "a means of protecting guest memory from a possibly > > > compromised hypervisor", I'd be grateful for the suggestion. > > > > Many of the features are also going far beyond just protecting memory, so > > even the "memory" part feels wrong. Maybe something like protected-guest > > or secure-guest? > > > > A little imprecision isn't necessarily a bad thing, e.g. memory-encryption > > is quite precise, but also wrong once it encompasses anything beyond plain > > old encryption. > > The common thread I think is 'untrusted host' - but I don't know of a > better way to describe that. Hrm.. UntrustedHost? CompromisedHostMitigation? HostTrustMitigation (that way it has the same abbreviation as hardware transactional memory for extra confusion)? HypervisorPowerLimitation? HostTrustLimitation? "HTL". That's not too bad, actually, I might go with that unless someone suggests something better.
Hello David, David Gibson <david@gibson.dropbear.id.au> writes: > 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 Thank you very much for this series! Using a machine property is a nice way of configuring this. From an end-user perspective, `-M pseries,guest-memory-protection` in the command line already expresses everything that QEMU needs to know, so having to add `-object pef-guest,id=pef0` seems a bit redundant. Is it possible to make QEMU create the pef-guest object behind the scenes when the guest-memory-protection property is specified? Regardless, I was able to successfuly launch POWER PEF guests using these patches: Tested-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> > can be extended to cover the Intel and s390 mechanisms as well, > though. > > Note: I'm using the term "guest memory protection" throughout to refer > to mechanisms like this. I don't particular like the term, it's both > long and not really precise. If someone can think of a succinct way > of saying "a means of protecting guest memory from a possibly > compromised hypervisor", I'd be grateful for the suggestion. Is "opaque guest memory" any better? It's slightly shorter, and slightly more precise about what the main characteristic this guest property conveys. -- Thiago Jung Bauermann IBM Linux Technology Center
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > Hello David, > > David Gibson <david@gibson.dropbear.id.au> writes: > > > 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 > > Thank you very much for this series! Using a machine property is a nice > way of configuring this. > > >From an end-user perspective, `-M pseries,guest-memory-protection` in > the command line already expresses everything that QEMU needs to know, > so having to add `-object pef-guest,id=pef0` seems a bit redundant. Is > it possible to make QEMU create the pef-guest object behind the scenes > when the guest-memory-protection property is specified? Not exactly - the object needs to exist for the QOM core to resolve it before we'd have a chance to look at the value to conditionally create the object. What we could do, however, is always create a PEF object in the machine, and it would just have no effect if the machine parameter wasn't specified. I did consider that option, but left it this way for greater consistency with AMD SEV - there the object can't be auto-created, since it has mandatory parameters needed to configure the encryption. I'm open to persuasion about changing that, though. > Regardless, I was able to successfuly launch POWER PEF guests using > these patches: > > Tested-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Ah, great. > > can be extended to cover the Intel and s390 mechanisms as well, > > though. > > > > Note: I'm using the term "guest memory protection" throughout to refer > > to mechanisms like this. I don't particular like the term, it's both > > long and not really precise. If someone can think of a succinct way > > of saying "a means of protecting guest memory from a possibly > > compromised hypervisor", I'd be grateful for the suggestion. > > Is "opaque guest memory" any better? It's slightly shorter, and slightly > more precise about what the main characteristic this guest property conveys. >
On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > Hello David, > > David Gibson <david@gibson.dropbear.id.au> writes: > > > 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 > > Thank you very much for this series! Using a machine property is a nice > way of configuring this. > > >From an end-user perspective, `-M pseries,guest-memory-protection` in > the command line already expresses everything that QEMU needs to know, > so having to add `-object pef-guest,id=pef0` seems a bit redundant. Is > it possible to make QEMU create the pef-guest object behind the scenes > when the guest-memory-protection property is specified? > > Regardless, I was able to successfuly launch POWER PEF guests using > these patches: > > Tested-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> > > > can be extended to cover the Intel and s390 mechanisms as well, > > though. > > > > Note: I'm using the term "guest memory protection" throughout to refer > > to mechanisms like this. I don't particular like the term, it's both > > long and not really precise. If someone can think of a succinct way > > of saying "a means of protecting guest memory from a possibly > > compromised hypervisor", I'd be grateful for the suggestion. > > Is "opaque guest memory" any better? It's slightly shorter, and slightly > more precise about what the main characteristic this guest property conveys. That's not a bad one, but for now I'm going with "host trust limitation", since this might end up covering things other than just memory protection.
On Thu, 4 Jun 2020 16:44:14 +1000 David Gibson <david@gibson.dropbear.id.au> wrote: > On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > > > Hello David, > > > > David Gibson <david@gibson.dropbear.id.au> writes: > > > > > 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 > > > > Thank you very much for this series! Using a machine property is a nice > > way of configuring this. > > > > >From an end-user perspective, `-M pseries,guest-memory-protection` in > > the command line already expresses everything that QEMU needs to know, > > so having to add `-object pef-guest,id=pef0` seems a bit redundant. Is > > it possible to make QEMU create the pef-guest object behind the scenes > > when the guest-memory-protection property is specified? > > > > Regardless, I was able to successfuly launch POWER PEF guests using > > these patches: > > > > Tested-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> > > > > > can be extended to cover the Intel and s390 mechanisms as well, > > > though. > > > > > > Note: I'm using the term "guest memory protection" throughout to refer > > > to mechanisms like this. I don't particular like the term, it's both > > > long and not really precise. If someone can think of a succinct way > > > of saying "a means of protecting guest memory from a possibly > > > compromised hypervisor", I'd be grateful for the suggestion. > > > > Is "opaque guest memory" any better? It's slightly shorter, and slightly > > more precise about what the main characteristic this guest property conveys. > > That's not a bad one, but for now I'm going with "host trust > limitation", since this might end up covering things other than just > memory protection. > Any idea what these other things might be ? It seems a bit hard to decide of a proper name without a broader picture at this point.
On Thu, Jun 04, 2020 at 01:11:29PM +1000, David Gibson wrote: > On Mon, Jun 01, 2020 at 10:16:18AM +0100, Dr. David Alan Gilbert wrote: > > * Sean Christopherson (sean.j.christopherson@intel.com) wrote: > > > On Thu, May 21, 2020 at 01:42:46PM +1000, David Gibson wrote: > > > > Note: I'm using the term "guest memory protection" throughout to refer > > > > to mechanisms like this. I don't particular like the term, it's both > > > > long and not really precise. If someone can think of a succinct way > > > > of saying "a means of protecting guest memory from a possibly > > > > compromised hypervisor", I'd be grateful for the suggestion. > > > > > > Many of the features are also going far beyond just protecting memory, so > > > even the "memory" part feels wrong. Maybe something like protected-guest > > > or secure-guest? > > > > > > A little imprecision isn't necessarily a bad thing, e.g. memory-encryption > > > is quite precise, but also wrong once it encompasses anything beyond plain > > > old encryption. > > > > The common thread I think is 'untrusted host' - but I don't know of a > > better way to describe that. > > Hrm.. UntrustedHost? CompromisedHostMitigation? HostTrustMitigation > (that way it has the same abbreviation as hardware transactional > memory for extra confusion)? HypervisorPowerLimitation? GuestWithTrustIssues? Then we can shorten it to InsecureGuest and cause all kinds of confusion :-D. > HostTrustLimitation? "HTL". That's not too bad, actually, I might go > with that unless someone suggests something better. DePrivelegedHost? "DPH". The "de-privelege" phrase seems to be another recurring theme.
David Gibson <david@gibson.dropbear.id.au> writes: > On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: >> >> Hello David, >> >> David Gibson <david@gibson.dropbear.id.au> writes: >> >> > 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 >> >> Thank you very much for this series! Using a machine property is a nice >> way of configuring this. >> >> >From an end-user perspective, `-M pseries,guest-memory-protection` in >> the command line already expresses everything that QEMU needs to know, >> so having to add `-object pef-guest,id=pef0` seems a bit redundant. Is >> it possible to make QEMU create the pef-guest object behind the scenes >> when the guest-memory-protection property is specified? > > Not exactly - the object needs to exist for the QOM core to resolve it > before we'd have a chance to look at the value to conditionally create > the object. > > What we could do, however, is always create a PEF object in the > machine, and it would just have no effect if the machine parameter > wasn't specified. > > I did consider that option, but left it this way for greater > consistency with AMD SEV - there the object can't be auto-created, > since it has mandatory parameters needed to configure the encryption. > > I'm open to persuasion about changing that, though. What about having it both ways? QEMU could always create a PEF object, and if the command line defines one, it will correspond to it. And if the command line doesn't define one, then it would also work because the PEF object is already there. That way, compatibility with AMD SEV is preserved but we also get command line simplicity where it is not needed.
On 04/06/20 23:54, Thiago Jung Bauermann wrote: > QEMU could always create a PEF object, and if the command line defines > one, it will correspond to it. And if the command line doesn't define one, > then it would also work because the PEF object is already there. How would you start a non-protected VM? Currently it's the "-machine" property that decides that, and the argument requires an id corresponding to "-object". Paolo > That way, compatibility with AMD SEV is preserved but we also get > command line simplicity where it is not needed.
Paolo Bonzini <pbonzini@redhat.com> writes: > On 04/06/20 23:54, Thiago Jung Bauermann wrote: >> QEMU could always create a PEF object, and if the command line defines >> one, it will correspond to it. And if the command line doesn't define one, >> then it would also work because the PEF object is already there. > > How would you start a non-protected VM? In the case of POWER PEF even with the machine property and the pef-guest object it's not guaranteed that the VM will be protected. They allow the possibility of the VM being protected. The decision lies with the guest. The Linux kernel will request being moved to "secure memory" when the `svm=on` parameter is passed in the kernel command line. To start a VM that doesn't have the possibility of being protected, one would simply not use the guest-memory-protection property (or host-trust-limitation, if that ends up being its name). Regardless of whether there's a pef-guest object. Sorry if the above is pedantic. I just want to make sure we're communicating clearly. > Currently it's the "-machine" > property that decides that, and the argument requires an id > corresponding to "-object". If there's only one object, there's no need to specify its id. I have the feeling I didn't understand your point. I hope these answers clarify what I'm suggesting. -- Thiago Jung Bauermann IBM Linux Technology Center
On 05/06/20 01:30, Thiago Jung Bauermann wrote: > Paolo Bonzini <pbonzini@redhat.com> writes: >> On 04/06/20 23:54, Thiago Jung Bauermann wrote: >>> QEMU could always create a PEF object, and if the command line defines >>> one, it will correspond to it. And if the command line doesn't define one, >>> then it would also work because the PEF object is already there. >> >> How would you start a non-protected VM? >> Currently it's the "-machine" >> property that decides that, and the argument requires an id >> corresponding to "-object". > > If there's only one object, there's no need to specify its id. This answers my question. However, the property is defined for all machines (it's in the "machine" class), so if it takes the id for one machine it does so for all of them. Paolo
On Thu, 21 May 2020 13:42:46 +1000 David Gibson <david@gibson.dropbear.id.au> 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? > > Note: I'm using the term "guest memory protection" throughout to refer > to mechanisms like this. I don't particular like the term, it's both > long and not really precise. If someone can think of a succinct way > of saying "a means of protecting guest memory from a possibly > compromised hypervisor", I'd be grateful for the suggestion. > > Changes since v1: > * Rebased > * Fixed some errors pointed out by Dave Gilbert > > David Gibson (18): > target/i386: sev: Remove unused QSevGuestInfoClass > target/i386: sev: Move local structure definitions into .c file > target/i386: sev: Rename QSevGuestInfo > target/i386: sev: Embed SEVState in SevGuestState > target/i386: sev: Partial cleanup to sev_state global > target/i386: sev: Remove redundant cbitpos and reduced_phys_bits > fields > target/i386: sev: Remove redundant policy field > target/i386: sev: Remove redundant handle field > target/i386: sev: Unify SEVState and SevGuestState > guest memory protection: Add guest memory protection interface > guest memory protection: Handle memory encrption via interface > guest memory protection: Perform KVM init via interface > guest memory protection: Move side effect out of > machine_set_memory_encryption() > guest memory protection: Rework the "memory-encryption" property > guest memory protection: Decouple kvm_memcrypt_*() helpers from KVM > guest memory protection: Add Error ** to > GuestMemoryProtection::kvm_init > spapr: Added PEF based guest memory protection > guest memory protection: Alter virtio default properties for protected > guests > > accel/kvm/kvm-all.c | 40 +-- > accel/kvm/sev-stub.c | 5 - > accel/stubs/kvm-stub.c | 10 - > backends/Makefile.objs | 2 + > backends/guest-memory-protection.c | 29 ++ > hw/core/machine.c | 61 ++++- > hw/i386/pc_sysfw.c | 6 +- > include/exec/guest-memory-protection.h | 77 ++++++ > include/hw/boards.h | 4 +- > include/sysemu/kvm.h | 17 -- > include/sysemu/sev.h | 6 +- > target/i386/sev.c | 351 +++++++++++++------------ > target/i386/sev_i386.h | 49 ---- > target/ppc/Makefile.objs | 2 +- > target/ppc/pef.c | 81 ++++++ > 15 files changed, 441 insertions(+), 299 deletions(-) > create mode 100644 backends/guest-memory-protection.c > create mode 100644 include/exec/guest-memory-protection.h > create mode 100644 target/ppc/pef.c >
Paolo Bonzini <pbonzini@redhat.com> writes: > On 05/06/20 01:30, Thiago Jung Bauermann wrote: >> Paolo Bonzini <pbonzini@redhat.com> writes: >>> On 04/06/20 23:54, Thiago Jung Bauermann wrote: >>>> QEMU could always create a PEF object, and if the command line defines >>>> one, it will correspond to it. And if the command line doesn't define one, >>>> then it would also work because the PEF object is already there. >>> >>> How would you start a non-protected VM? >>> Currently it's the "-machine" >>> property that decides that, and the argument requires an id >>> corresponding to "-object". >> >> If there's only one object, there's no need to specify its id. > > This answers my question. However, the property is defined for all > machines (it's in the "machine" class), so if it takes the id for one > machine it does so for all of them. I don't understand much about QEMU internals, so perhaps it's not practical to implement but from an end-user perspective I think this logic can apply to all architectures (since my understanding is that all of them use only one object): make the id optional. If it's not specified, then there must be only one object, and the property will implicitly refer to it. Then, if an architecture doesn't need to specify parameters at object creation time, it can be implicitly created and the user doesn't have to worry about this detail. -- Thiago Jung Bauermann IBM Linux Technology Center
On Fri, Jun 05, 2020 at 05:01:07PM -0300, Thiago Jung Bauermann wrote: > > Paolo Bonzini <pbonzini@redhat.com> writes: > > > On 05/06/20 01:30, Thiago Jung Bauermann wrote: > >> Paolo Bonzini <pbonzini@redhat.com> writes: > >>> On 04/06/20 23:54, Thiago Jung Bauermann wrote: > >>>> QEMU could always create a PEF object, and if the command line defines > >>>> one, it will correspond to it. And if the command line doesn't define one, > >>>> then it would also work because the PEF object is already there. > >>> > >>> How would you start a non-protected VM? > >>> Currently it's the "-machine" > >>> property that decides that, and the argument requires an id > >>> corresponding to "-object". > >> > >> If there's only one object, there's no need to specify its id. > > > > This answers my question. However, the property is defined for all > > machines (it's in the "machine" class), so if it takes the id for one > > machine it does so for all of them. > > I don't understand much about QEMU internals, so perhaps it's not > practical to implement but from an end-user perspective I think this > logic can apply to all architectures (since my understanding is that all > of them use only one object): make the id optional. If it's not > specified, then there must be only one object, and the property will > implicitly refer to it. > > Then, if an architecture doesn't need to specify parameters at object > creation time, it can be implicitly created and the user doesn't have to > worry about this detail. Seems overly complicated to me. We could just have it always take an ID, but for platforms with no extra configuration make the pre-fabricated object available under a well-known name. That's essentially the same as the way you can add a device to the "pci.0" bus without having to instantiate and name that bus yourself.
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@gibson.dropbear.id.au> 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.
On Thu, Jun 04, 2020 at 11:08:21AM +0200, Greg Kurz wrote: > On Thu, 4 Jun 2020 16:44:14 +1000 > David Gibson <david@gibson.dropbear.id.au> wrote: > > > On Thu, Jun 04, 2020 at 01:39:22AM -0300, Thiago Jung Bauermann wrote: > > > > > > Hello David, > > > > > > David Gibson <david@gibson.dropbear.id.au> writes: > > > > > > > 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 > > > > > > Thank you very much for this series! Using a machine property is a nice > > > way of configuring this. > > > > > > >From an end-user perspective, `-M pseries,guest-memory-protection` in > > > the command line already expresses everything that QEMU needs to know, > > > so having to add `-object pef-guest,id=pef0` seems a bit redundant. Is > > > it possible to make QEMU create the pef-guest object behind the scenes > > > when the guest-memory-protection property is specified? > > > > > > Regardless, I was able to successfuly launch POWER PEF guests using > > > these patches: > > > > > > Tested-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> > > > > > > > can be extended to cover the Intel and s390 mechanisms as well, > > > > though. > > > > > > > > Note: I'm using the term "guest memory protection" throughout to refer > > > > to mechanisms like this. I don't particular like the term, it's both > > > > long and not really precise. If someone can think of a succinct way > > > > of saying "a means of protecting guest memory from a possibly > > > > compromised hypervisor", I'd be grateful for the suggestion. > > > > > > Is "opaque guest memory" any better? It's slightly shorter, and slightly > > > more precise about what the main characteristic this guest property conveys. > > > > That's not a bad one, but for now I'm going with "host trust > > limitation", since this might end up covering things other than just > > memory protection. > > Any idea what these other things might be ? It seems a bit hard to > decide of a proper name without a broader picture at this point. Well, at the very least there needs to be protection of the guest's register state from the hypervisor (which may be indirectly implied by protection of memory).
David Gibson <david@gibson.dropbear.id.au> writes: > On Fri, Jun 05, 2020 at 05:01:07PM -0300, Thiago Jung Bauermann wrote: >> >> Paolo Bonzini <pbonzini@redhat.com> writes: >> >> > On 05/06/20 01:30, Thiago Jung Bauermann wrote: >> >> Paolo Bonzini <pbonzini@redhat.com> writes: >> >>> On 04/06/20 23:54, Thiago Jung Bauermann wrote: >> >>>> QEMU could always create a PEF object, and if the command line defines >> >>>> one, it will correspond to it. And if the command line doesn't define one, >> >>>> then it would also work because the PEF object is already there. >> >>> >> >>> How would you start a non-protected VM? >> >>> Currently it's the "-machine" >> >>> property that decides that, and the argument requires an id >> >>> corresponding to "-object". >> >> >> >> If there's only one object, there's no need to specify its id. >> > >> > This answers my question. However, the property is defined for all >> > machines (it's in the "machine" class), so if it takes the id for one >> > machine it does so for all of them. >> >> I don't understand much about QEMU internals, so perhaps it's not >> practical to implement but from an end-user perspective I think this >> logic can apply to all architectures (since my understanding is that all >> of them use only one object): make the id optional. If it's not >> specified, then there must be only one object, and the property will >> implicitly refer to it. >> >> Then, if an architecture doesn't need to specify parameters at object >> creation time, it can be implicitly created and the user doesn't have to >> worry about this detail. > > Seems overly complicated to me. We could just have it always take an > ID, but for platforms with no extra configuration make the > pre-fabricated object available under a well-known name. > > That's essentially the same as the way you can add a device to the > "pci.0" bus without having to instantiate and name that bus yourself. Ok, that sounds good to me.
On Sat, 6 Jun 2020 18:44:09 +1000 David Gibson <david@gibson.dropbear.id.au> 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@gibson.dropbear.id.au> 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
On Tue, Jun 09, 2020 at 12:11:05PM +0200, Halil Pasic wrote: > On Sat, 6 Jun 2020 18:44:09 +1000 > David Gibson <david@gibson.dropbear.id.au> 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@gibson.dropbear.id.au> 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? Ah, sorry, my mistake. If it's all based on a cpu model facility that must be explicitly selected by the user (not based on host capbilities) then that's ok as well. The problem comes if you base guest availability on host availability, which early proposals for the POWER version did involve.
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. Note: I'm using the term "guest memory protection" throughout to refer to mechanisms like this. I don't particular like the term, it's both long and not really precise. If someone can think of a succinct way of saying "a means of protecting guest memory from a possibly compromised hypervisor", I'd be grateful for the suggestion. Changes since v1: * Rebased * Fixed some errors pointed out by Dave Gilbert David Gibson (18): target/i386: sev: Remove unused QSevGuestInfoClass target/i386: sev: Move local structure definitions into .c file target/i386: sev: Rename QSevGuestInfo target/i386: sev: Embed SEVState in SevGuestState target/i386: sev: Partial cleanup to sev_state global target/i386: sev: Remove redundant cbitpos and reduced_phys_bits fields target/i386: sev: Remove redundant policy field target/i386: sev: Remove redundant handle field target/i386: sev: Unify SEVState and SevGuestState guest memory protection: Add guest memory protection interface guest memory protection: Handle memory encrption via interface guest memory protection: Perform KVM init via interface guest memory protection: Move side effect out of machine_set_memory_encryption() guest memory protection: Rework the "memory-encryption" property guest memory protection: Decouple kvm_memcrypt_*() helpers from KVM guest memory protection: Add Error ** to GuestMemoryProtection::kvm_init spapr: Added PEF based guest memory protection guest memory protection: Alter virtio default properties for protected guests accel/kvm/kvm-all.c | 40 +-- accel/kvm/sev-stub.c | 5 - accel/stubs/kvm-stub.c | 10 - backends/Makefile.objs | 2 + backends/guest-memory-protection.c | 29 ++ hw/core/machine.c | 61 ++++- hw/i386/pc_sysfw.c | 6 +- include/exec/guest-memory-protection.h | 77 ++++++ include/hw/boards.h | 4 +- include/sysemu/kvm.h | 17 -- include/sysemu/sev.h | 6 +- target/i386/sev.c | 351 +++++++++++++------------ target/i386/sev_i386.h | 49 ---- target/ppc/Makefile.objs | 2 +- target/ppc/pef.c | 81 ++++++ 15 files changed, 441 insertions(+), 299 deletions(-) create mode 100644 backends/guest-memory-protection.c create mode 100644 include/exec/guest-memory-protection.h create mode 100644 target/ppc/pef.c