On Tue, Apr 8, 2025 at 1:33 AM Gerd Hoffman <kra...@redhat.com> wrote: > > Hi, > > > > Well. If you want put the db into the igvm and the igvm into the uki > > > you've got a chicken-and-egg problem. Moving the firmware from the main > > > UKI to UKI add-on would solve that. > > > > Why is embedding a public key that will sign the IGVM in the IGVM a > > chicken-and-egg problem? It's only that if db were a list of > > acceptable measurements, which it isn't. > > I'm not sure why relying on secure boot makes any sense for > > confidential computing. I still think that tearing down the VM context > > and rebuilding it is more secure, given > > the need for an honest launch measurement/MRTD. > > Current idea is to allow passing EFI signature databases for db/dbx to > the firmware getting loaded. The signature databases must be part of > the launch measurement. Not clear yet how exactly to handle that, one > idea is to add a special page type to the igvm spec, so a igvm parser > can easily find and update db/dbx. > > So, the VM context will be rebuild, the igvm (including db/dbx) will be > measured, the firmware can verify the payload using db/dbx and standard > secure boot hash/signature. > > This allows to use both signing (pass CA certificate in db) and hashing > (pass authenticode hash(es) in db) for payload verification. > > The chicken-and-egg problem arises if you go for hashing and want embed > the igvm file in the UKI.
I don't really see how signing the IGVM file for secure boot helps anything. The VM context will be reconstructed by the hypervisor, and anything checked or stored before loading the new firmware is suspect. SEV-SNP has IDBLOCK_AUTH to have the SNP firmware check a signature, but TDX has nothing of the sort. Your initial measurement is checked by nothing trusted. Do you need the UEFI_APPLICATION that uses the vmfwupdate interface to be signed for secure boot? Seems unnecessary. > > > Revocation is just not a real thing that works. Short-lived policy is. > > Policy services can be updated more simply than the UEFI variables of > > every node in the fleet. > > In the model outlined above you'll go ship db/dbx in the igvm, so the > launch measurement will tell you what is allowed and what is not. Which > in turn can be used in attestation server policies. > > take care, > Gerd > -- -Dionna Glaze, PhD, CISSP, CCSP (she/her)
