On 17.03.25 10:56, Gerd Hoffman wrote:
On Fri, Mar 14, 2025 at 03:50:19PM +0100, Alexander Graf wrote:
On 14.03.25 15:08, Gerd Hoffman wrote:
Hi,
Ok, assuming we allow the guest submit a IGVM image (which makes sense
indeed, otherwise we'll probably end up re-inventing IGVM). How will
the kernel hashes be handled then? I assume they will not be part of
the igvm image, but they must be part of the launch measurement ...
The kernel hashes must be embedded in the IGVM image by the time you invoke
vmfwupdate. That means when you generate the FUKI, you take 4 inputs:
Generic firmware image, kernel, initramfs, cmdline. Out of those, you
generate and embed an IGVM image that consists of the firmware image as well
as the kernel hash page.
If your input firmware image already is an IGVM (say coconut), what is
supposed to happen?
I'll leave the details to Jörg on how he envisions it, but IIUC the flow for
a "readily assembled IGVM" is different. In case of a COCONUT-SVSM IGVM, you
expect chaining of trust. So the SVSM implements a TPM which then the OS
would use with measured boot etc etc.
Well, I don't consider igvm being useful for svsm only. Shipping
standard edk2 as igvm looks useful to me. Main benefit: pre-calculate
launch measurements without having to know qemu internals.
It's a fundamentally different concept from FUKI.
Hmm? IGVM is just a different way to ship the firmware (and optionally
more).
But it could share the same vmfwupdate mechanism to load.
Yep. But we have to sort the details.
(1) How we are going to load kernel + initrd in case the firmware is
igvm? Just update the igvm to also include linux kernel and
initrd (see parallel reply from Jörg)? If so, how does the
launched firmware find the kernel + initrd?
While digging around in the igvm spec I've seen there is the
concept of 'parameters'. Can this be used to pass on the memory
location of kernel + initrd + cmdline? Maybe the kernel hashes too?
I don't know. But even if not, the only thing customers can actually
reason about is a combined hash of firmware + kernel + initrd + cmdline.
Whether we assemble that using an edk2 IGVM plus parameters or by
generating an IGVM from a "proprietary format" such as the edk2 BIOS
blob plus a generated kernel hash page does not really make a difference
from the user's point of view.
The flow will be the same: You use ukify to generate a FUKI from source
files and get a FUKI plus precalculated hashes.
(2) Will the igvm be generated on the fly from FUKI data? Or should
the distros ship igvm images with firmware + kernel + initrd?
If your distro embraces UKIs today, they should IMHO also embrace
prebuilt FUKIs. Whether they are building their IGVM on the fly but
precalculate the hash for that on-the-fly generated image ahead of time
or whether they embed an IGVM is not terribly important I think.
The main difference between the 2 approaches is that dynamic generation
allows you to have multiple different environment builds in a single
FUKI. That way you can for example support UKI addons [1]
(3) How we are going to handle uki add-ons?
You can only (sensibly) handle them with on the fly generation.
(4) Do we want keep the region list? Or declare that igvm should be
used in case a single region is not enough? Or even go all-in and
use IGVM exclusively?
IGVM would replace the region list I think. Before making that jump, I
would like to see it actually work though.
Alex
[1]
https://archive.fosdem.org/2024/events/attachments/fosdem-2024-2024-uki-addons-and-extensions-safely-extending-ukis-kernel-command-line-and-initrd/slides/22125/Uki_addons_O97iYns.pdf
take care,
Gerd
