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. > 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
