On Mon, Mar 24, 2025 at 06:53:59PM +0100, Gerd Hoffman wrote: > On Mon, Mar 24, 2025 at 05:31:30PM +0100, Alexander Graf wrote: > > > > > > > > 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. > > Yep, that is what should be possible when all this is ready. > > > - 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. > > Well, add-ons have been created to address exactly that: Allow the UKI > being configured without changing it, so the UKI can be signed by redhat. > You'll go add user-signed add-on for the command line. > > > - Add-ons. How do you provide a "debug add-on" and prevent it to gain any > > access to confidential data? > > Not sure I understand the point you are trying to raise. Add-ons > signatures are checked too.
"Debug add-on" is quite a broad concept - some things might be safe for the vendor to ship as pre-built signed add-ons by default, others things may not be safe & require user opt-in, by signing an add-on locally with their MOK and enrolling with it shim. Also UKIs semi-recently gained support for multiple profiles avoiding the need for addons in some cases[1]. A simple use of this might be two cmdlines - one quiet by default and one with verbose kernel messages. A more advanced use would be one "normal" profile, and one "factory reset" profile With regards, Daniel [1] https://github.com/uapi-group/specifications/blob/main/specs/unified_kernel_image.md#multi-profile-ukis -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
