On 24.03.25 16:48, Gerd Hoffman wrote:
On Mon, Mar 24, 2025 at 04:42:28PM +0530, Ani Sinha wrote:
On Mon, Mar 24, 2025 at 1:13 PM Gerd Hoffman <kra...@redhat.com> wrote:
Hi,
Going ship the distro kernel as igvm image would work too. Will
simplify the measurement pre-calculation. Also there is no need to pass
around any parameters, everything (how the firmware finds the UKI etc)
can be arranged at igvm build time then. Disadvantage: This introduces
a completely new boot workflow. Will probably need a new set of cloud
images exclusively for the BYOF case.
What does all this mean for the hypervisor interface ?
That means we'll go scratch the region list idea and depend on igvm
instead.
Which means we are back to the single firmware image.
So in this model, how are we passing the hashes of kernel, initrd and cmdline?
Are they going to be part of the firmware image as was previously thought?
Either scratch the idea of using hashes to verify kernel + initrd +
cmdline and use a secure boot signed UKI instead, or use IGVM firmware
images and add the kernel hashes page to the igvm.
It's a nice idea to have a firmware IGVM file that contains a signature,
so you can for example have a RHEL provided IGVM that only runs UKIs
that are signed by Red Hat.
Unfortunately, it does not address some of the other interesting use cases:
- Attestable Bootable Containers. In that case, the command line
contains a hash of the target fs-verity protected partition. Red Hat can
not be the entity signing that UKI. It must be the user.
- Add-ons. How do you provide a "debug add-on" and prevent it to gain
any access to confidential data?
So we need some equivalent of a hash page. That can absolutely integrate
more deeply into UEFI and be actual PE hashes rather than the icky thing
the OVMF code does today. But we need to support a way to embed the hash
in the ukify.py generated IGVM on the fly. With add-ons, maybe even
multiple ones.
Alex
