On Fri, Jun 12, 2026 at 7:43 AM Marta Lewandowska <[email protected]> wrote:
> > Since confidential VMs rely on remote attestation, TPM PCR values need >> > to be stable and predictable over long periods of time. Updating the >> > bootloader results in changes to PCRs, and should therefore be avoided >> > if possible. >> >> What is the plan for the grub configuration? One of the big issues when >> it comes to PCR pre-calculation is that grub hashes every config file >> line processed into one of the PCRs. > > > There is a very simple grub.cfg baked into the binary which is just: > timeout=5 > blscfg > > And then in the grub code, logging anything to PCR8 is disabled when the > config file is baked in. So the value of PCR8 stays identically 0. > Right. Currently we basically disable PCR8 at build time but in the near future I plan to do the same at run-time. > > >> > frequent updates need to be. The resulting idea is to create a smaller >> > version of GRUB, the supported bootloader in most Linux environments, >> > for UEFI, which is built as a separate package from the main GRUB >> > build, contains only the modules that are absolutely necessary for >> > VMs, and natively supports UKI loading. >> >> As of today the cc grub does not look very stripped down to me: >> >> kraxel@fedora ~# ll /boot/efi/EFI/fedora/grubaa64* >> -rwxr-xr-x. 1 root root 4473256 Jun 12 12:23 >> /boot/efi/EFI/fedora/grubaa64-cc.efi* >> -rwxr-xr-x. 1 root root 4407720 Jun 4 02:00 >> /boot/efi/EFI/fedora/grubaa64.efi* >> > > yeah, it still needs some work ;) > Indeed, it needs more work. Many modules were removed (link below) but for some reason, the size does not come down. https://redhat.atlassian.net/browse/RHEL-171401 > > >> > The original idea was to use systemd-boot for this application, but >> > this was rejected for a number of reasons: >> >> Nevertheless grub should behave according to the boot loader spec so it >> stays compatible with systemd-boot. >> > > +1 > > >> > * Create BLS entries in that directory for each UKI. Specify the path >> > to the UKI using the `efi` keyword, as you normally would use `linux` >> > for the kernel. A minimal BLS file only needs to have a title and the >> > path to the UKI: >> > >> > <pre> >> > # cat /boot/efi/loader/entries/7.0.10-200-UKI.fc45.x86_64.conf >> > title Fedora 45 UKI (7.0.10-200.fc45.x86_64) >> > efi /EFI/Linux/7.0.10-200.fc45.x86_64.efi >> > </pre> >> >> This should not be needed. According to the boot loader spec a snippet >> is optional for UKIs. The boot loader should pick up all UKI images in >> EFI/Linux without config entries. It is allowed to add a snippet if >> needed, for example to add command line arguments. >> > > So, the `uki` keyword also works in GRUB, so if it is added to the cfg > file, > it picks up the images, as you mentioned. CoreOS specifically wanted to > use BLS snippets. > > >> > The generic UKI that fedora ships has only `console=tty0 >> > console=ttyS0` on its kernel command line. In order for it to actually >> > boot on your system, it needs more information, like the root >> > filesystem UUID, >> >> This is not needed. Make sure the 'bli' module is included in the list >> of modules for cc grub. With that the initrd should find the root >> filesystem partition just fine if it is properly tagged: >> >> kraxel@fedora ~# sudo fdisk -l /dev/sda >> [ ... ] >> /dev/sda3 3328000 33552383 30224384 14.4G Linux root (ARM-64) >> ^^^^^^^^^^^^^^^^^^^ >> >> When using btrfs the root sub-volume must be the default volume for that >> to work. >> > > huh, ok...I'm pretty sure bli is being built in but maybe not...? The > generic UKI > was failing to boot for me. > Yes, bli module is in there. > > >> With CoreOS this is probably a bit different because it expects to get >> the ostree root hash (which is not fixed) passed on the kernel command >> line. So CoreOS probably has to actually do the addon signing dance, or >> find some alternative way such as systemd credentials to configure this. > > > ok :) >
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
