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.
Regards,
Jim
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-support-thomas-lendacky-amd
2:
https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf
3: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03689.html
Michal
