> It looks like QEMU will expose commands needed for attestation via QMP [3]. > But question then is, how to expose those at Libvirt level? Should we allow > users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in > public APIs, or something completely different? I know you're just thinking out loud here, but IIUC, isn't allowing libvirt API users to communicate directly with QEMU in this case departing from the libvirt norm? (Perhaps there's scope of sensible exceptions ... as the devil is in the specs.) Allowing a way to do it is one thing — which is nice for testing and development — but saying "just directly communicate via QMP passthrough" makes the libvirt API user wonder "why is it okay to passthrough QMP commands in this case, but generally such an action is marked as 'tainted' by libvirt?"

Dear list, in the light of recent development of secure virtualization (for instance AMD SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new technologies and thus would like to discuss our options. So far, I've came across AMD SEV-SNP [2]. While it's true that we do support SEV, we need to adopt its newer version too. Consider the following example: you loan a VM on a public cloud and you want to process some private data there. Of course, the data has to be stored on an encrypted disk/partition. But encrypting guest memory (confidentiality) prevents you only from finding the key in a memory dump. It doesn't help if the guest image, initial guest memory, hypervisor or firmware were tampered with. This is where attestation comes to help - it enables the guest owner (which in this example is different to the one running it) verify - with cryptographic level of confidence - that data confidentiality and integrity can be ensured. Depending on the technology, attestation will be done at different times in the VM lifecycle. When it's done before starting guest vCPUs, it's called pre-attestation and when it's done after the guest has launched, it's called post-attestation. For example, AMD SEV and SEV-ES require pre-attestation. SEV-SNP allows for post attestation. The crux of the issue here is that *when* and *how* the guest owner will interact with the VM for attestation will be different depending on which technology is being used. It looks like QEMU will expose commands needed for attestation via QMP [3].

But question then is, how to expose those at Libvirt level? Should we allow users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in public APIs, or something completely different?

Will those APIs be generic enough to serve other technologies too? For instance, given set of APIs in given order works for SEV but might not work for Intel's TDX.

1: https://kvmforum2019.sched.com/event/Tmwl/improving-and-expanding-sev-sup... 2: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolat... 3: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03689.html Michal

On 5/6/21 6:51 AM, Daniel P. Berrangé wrote: >> It looks like QEMU will expose commands needed for attestation via QMP [3]. > > As mentioned in my reply to that thread, I believe we can already do > pretty much all of that via a combination of libvirt APIs & guest XML. This is not a good user experience. The entire attestation process should be made ephemeral, taking place 100% over a socket. Enabling a fully socket-based attestation workflow will decouple it from the domain XML and the host file system and make it easier for guest-owner tooling to facilitate attestation.

On 5/6/21 8:32 AM, Daniel P. Berrangé wrote: > On Thu, May 06, 2021 at 08:04:44AM -0500, Connor Kuehl wrote: >> On 5/6/21 6:51 AM, Daniel P. Berrangé wrote: >>>> It looks like QEMU will expose commands needed for attestation via QMP [3]. >>> >>> As mentioned in my reply to that thread, I believe we can already do >>> pretty much all of that via a combination of libvirt APIs & guest XML. >> >> This is not a good user experience. The entire attestation process >> should be made ephemeral, taking place 100% over a socket. Enabling a >> fully socket-based attestation workflow will decouple it from the domain >> XML and the host file system and make it easier for guest-owner tooling >> to facilitate attestation. > > The libvirt library is also just a client talking to a socket, so > concept that's no different, just using a protocol libvirt has defined > at a higher level instead of a low level hypervisor specific protocol. > > The tools that are managing the VM lifecycle are already using libvirt > as their API, and already doing several of the steps described wrt to > SEV. It is not realistic to expect them to take a completely different > approach to managing the startup of VMs that have SEV enabled, they > need to have a way to integrate with their existing approach to mgmt. > > The guest owner has to in turn talk to some mechanism that the > management app exposes to them. These management apps are pretty > unlikely to wish to directly expose a low level impl detail of QEMU. > They won't even expose the fact that they're using libvirt in fact, > instead presenting some higher level API again, as they rarely wish > to leak low level hypervisor details outside as that locks them into > supporting specific low level details long term. I see. So it sounds like the way forward for libvirt is that it will need to essentially duplicate the SEV-related QMP message types into its own protocol since expecting the client to understand QMP discloses the fact that the underlying hypervisor is QEMU.

Dear list,

in the light of recent development of secure virtualization (for instance AMD SEV-SNP [1]) I'd like us to be prepared for when QEMU adopts these new technologies and thus would like to discuss our options. So far, I've came across AMD SEV-SNP [2]. While it's true that we do support SEV, we need to adopt its newer version too. Consider the following example: you loan a VM on a public cloud and you want to process some private data there. Of course, the data has to be stored on an encrypted disk/partition. But encrypting guest memory (confidentiality) prevents you only from finding the key in a memory dump. It doesn't help if the guest image, initial guest memory, hypervisor or firmware were tampered with. This is where attestation comes to help - it enables the guest owner (which in this example is different to the one running it) verify - with cryptographic level of confidence - that data confidentiality and integrity can be ensured. Depending on the technology, attestation will be done at different times in the VM lifecycle. When it's done before starting guest vCPUs, it's called pre-attestation and when it's done after the guest has launched, it's called post-attestation. For example, AMD SEV and SEV-ES require pre-attestation. SEV-SNP allows for post attestation. The crux of the issue here is that *when* and *how* the guest owner will interact with the VM for attestation will be different depending on which technology is being used. It looks like QEMU will expose commands needed for attestation via QMP [3]. But question then is, how to expose those at Libvirt level? Should we allow users to bypass Libvirt and communicate to QEMU directly or wrap those QMPs in public APIs, or something completely different? Will those APIs be generic enough to serve other technologies too? For instance, given set of APIs in given order works for SEV but might not work for Intel's TDX. 1: https://kvmforum2019.sched.com/event/Tmwl/improving-and-expanding-sev-sup... 2: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolat... 3: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03689.html Michal

On 5/6/21 04:22, Michal Prívozník wrote: > Dear list, Hi Michal, This thread has been quiet for a long time, but I wanted to check if any work has been done to provide an sev-inject-launch-secret equivalent for libvirt. AFAICT, there was agreement this missing piece is needed to solve the attestation puzzle. Did you make any progress? If so, I can help with testing and review. If not, I can take a stab at it.