On Tue Sep 12, 2023 at 6:32 PM EEST, Jan Hendrik Farr wrote:
> >> The format itself is rather simple. It's just a PE file (as required
> >> by the UEFI spec) that contains a small stub application in the .text,
> >> .data, etc sections that is responsible for invoking the contained
> >> kernel and initrd with the contained cmdline. The kernel image is
> >> placed into a .kernel section, the initrd into a .initrd section, and
> >> the cmdline into a .cmdline section in the PE executable.
> >
> > How does this interact with the existing EFI stub support in linux?
>
> It doesn't. During normal boot of a UKI the stub in it is used
> (systemd-stub, see:
> https://www.freedesktop.org/software/systemd/man/systemd-stub.html).
> The kernel's own EFI stub will still be in the binary inside the
> .linux section but not used.
What sort of bottleneck does the EFI stub have so that we need yet
another envelope?
BR, Jarkko
> What sort of bottleneck does the EFI stub have so that we need yet
> another envelope?
Well I can come up with a few advantages of UKI compared to normal bzImage with builtin initrd and cmdline.
1. You already identified this one. Using addons to adjust your cmdline
2. I can use my normal initramfs generation tooling. Just install my compiled kernel, my distros install script will generate the initramfs. Then I package it up as a UKI. This will be a lot more awkward with a builtin initrd.
3. Measured boot. You can place PCR signatures in the UKI using systemd-measure. This will sign the expected PCR values for booting this UKI. I think with normal bzImage this will be a lot more difficult. If you place those PCR signatures in the builtin initrd this will change the kernel image which means now the values you signed no longer match (depending on how you measure the kernel; I don't think the normal EFI stub even measures the kernel in first place, but I could be mistaken about this)
4. UKIs are automatically recognized by systemd-boot
There's probably more reasons. The main reason for me to go with UKIs initially was the good tooling around them.
You could probably overcome some of these drawbacks in the default kernel EFI stub. For example it could also get a place to put signed PCR values. And it could also do TPM measurements. However in the process all you're doing is rebuilding what already exists today in systemd-stub and the tooling around UKIs.
On Tue Sep 12, 2023 at 9:56 PM EEST, Jan Hendrik Farr wrote:
> > What sort of bottleneck does the EFI stub have so that we need yet
> > another envelope?
>
> Well I can come up with a few advantages of UKI compared to normal bzImage with builtin initrd and cmdline.
>
> 1. You already identified this one. Using addons to adjust your cmdline
It is not a benefit as this is already possible today.
> 2. I can use my normal initramfs generation tooling. Just install my
> compiled kernel, my distros install script will generate the
> initramfs. Then I package it up as a UKI. This will be a lot more
> awkward with a builtin initrd.
> 3. Measured boot. You can place PCR signatures in the UKI using
> systemd-measure. This will sign the expected PCR values for booting
> this UKI. I think with normal bzImage this will be a lot more
> difficult. If you place those PCR signatures in the builtin initrd
> this will change the kernel image which means now the values you
> signed no longer match (depending on how you measure the kernel; I
> don't think the normal EFI stub even measures the kernel in first
> place, but I could be mistaken about this)
> 4. UKIs are automatically recognized by systemd-boot
These are sort of "tautological" arguments. There must be some
objective reasons why this architecture was chosen instead of
other (i.e. using what already pre-exists).
BR, Jarkko