> On 10 Apr 2025, at 4:14 PM, Gerd Hoffmann <kra...@redhat.com> wrote:
>
> On Thu, Apr 10, 2025 at 12:01:18PM +0530, Ani Sinha wrote:
>>
>>
>>> On 9 Apr 2025, at 11:51 AM, Gerd Hoffman <kra...@redhat.com> wrote:
>>>
>>> Hi,
>>>
>>>>> 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.
>>>
>>> It doesn't help indeed. This comes from the original idea by Alex to
>>> simply add a firmware image to the UKI. In that case the firmware is
>>> covered by the signature / hash, even though it is not needed. Quite
>>> the contrary, it complicates things when we want ship db/dbx in the
>>> firmware image.
>>>
>>> So most likely the firmware will not be part of the main UKI. Options
>>> for alternatives are using UKI add-ons,
>>
>> But add-ons are also subjected to signature verification. How does not using
>> the main UKI help?
>
> For the first boot using secure boot doesn't help much, the trust
> in the firmware being loaded for the second boot is established via
> launch measurement not secure boot signature.
>
> For the second boot (with new firmware) you don't need the add-on any
> more.
>
> The main advantage of wrapping the igvm into a uki add-on is that we
> can easily use the hwid matching support of systemd-stub when packaging
> multiple firmware variants (aws, azure, gcp, qemu, ...). Not sure this
> will actually matter in practice though.
This makes sense.
