> On Apr 9, 2025, at 03:12, Dionna Amalie Glaze <dionnagl...@google.com> wrote:
>
> 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.
By "initial measurement" you mean before the VM context is reconstructed, that
is in the first stage boot correct?
>
> 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)
