How to use the -certs option in launch-qemu.sh for extended attestation with snp-latest?

[rmerz]

Hello,
I've build snp-latest branch and successfully tested it with a 6.11-rc5 kernel on Ubuntu 24.04. I'm able to validate standard attestation workflow.
I want to validate extended attestation, and if my understanding is right, I need to use the -certs option of launch-qemu.sh.

I have a hard time finding a description of the format of the certificate blob (I've tried with snphost import). And when trying out with launch-qemu.sh I get

qemu-system-x86_64: -object sev-snp-guest,id=sev0,policy=0xb0000,cbitpos=51,reduced-phys-bits=1,certs-path=cert-file.bin: Invalid parameter 'certs-path'

What am I missing?
Thanks for pointers

---

More specifically

sudo ./launch-qemu.sh -hda img-ubuntu-2404.qcow2 -sev-snp -certs cert-file.bin 
32+0 records in
1+0 records out
512 bytes copied, 0.000159521 s, 3.2 MB/s
/home/ubuntu/src/AMDSEV/usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4 -machine q35 -smp 4,maxcpus=255 -m 2048M,slots=5,maxmem=10240M -no-reboot -bios /home/ubuntu/src/AMDSEV/usr/local/share/qemu/OVMF.fd -drive file=/home/ubuntu/src/AMDSEV/img-ubuntu-2404.qcow2,if=none,id=disk0,format=qcow2 -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -machine memory-encryption=sev0,vmport=off -object memory-backend-memfd,id=ram1,size=2048M,share=true,prealloc=false -machine memory-backend=ram1 -object sev-snp-guest,id=sev0,policy=0xb0000,cbitpos=51,reduced-phys-bits=1,certs-path=cert-file.bin -nographic -monitor pty -monitor unix:monitor,server,nowait 
Mapping CTRL-C to CTRL-]
Launching VM ...
  /tmp/cmdline.432179
qemu-system-x86_64: -object sev-snp-guest,id=sev0,policy=0xb0000,cbitpos=51,reduced-phys-bits=1,certs-path=cert-file.bin: Invalid parameter 'certs-path'

[mdroth]

The -cert option is not required for attestation, it's more of a convenient way to provide that information to the guest so it doesn't need to fetch it through other means. But what the guest ends up doing with the certificates, or how it fetches them, is up to the guest owner and not strictly enforced/required by kernel or SNP spec.

Also, -cert is no longer available since upstream is going a different direction on how that support will eventually be implemented, so the -cert option is no longer available in snp-latest branch to match more closely with upstream.

[rmerz]

Thanks. Any pointer how to perform the "extended attestation" workflow (as in #212 (comment))? Because I did indeed validate the "standard attestation" workflow

[Doctor-love]

Thanks. Any pointer how to perform the "extended attestation" workflow (as in #212 (comment))? Because I did indeed validate the "standard attestation" workflow

Also interested in this :-)

[Doctor-love]

To clarify: what is the current upstream approach - how is the previous method for "extended attestation" replaced?

An alternative/modifications would be needed to use the Trustee KBS without it AFAIK, according to this issue

[mdroth]

This is essentially a back-channel to additionally-provide a certificate blob alongside the attestation report supplied to the guest. The guest is free to fetch the certificates through other means however, e.g. scp'ing it from a local cache or some other facility provided by the guest's attestation stack/service. The KVM support is only to provide additional flexibility with various deployment models

[Doctor-love]

Thanks for the prompt clarification!

[rmerz]

Yep, thanks