On Mon, Jan 20, 2020 at 5:58 PM Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
>
> I've been thinking about ways to solve this for a while, and I'm coming
> to the conclusion that the best plan is probably to just ship pre-built
> initramfs images. I can think of three main reasons to want to use
> system-specific images:
>
> 1) They're smaller. By default we're already generating a generic image
> for rescue purposes, so disk space isn't the concern here - we're
> largely looking at losing boot speed. As machines have got faster this
> is probably not a huge deal.
What about the on-going cost: downloading ~80M initramfs for each kernel update; systemd-analyze on NVMe says initrd time is 2.5s for a host-only ~25M initramfs. No-host-only initramfs is about 3x bigger. If the size to time relationship is linear, that's a chunk of extra time. Maybe there's a way to improve the read performance in the bootloader to compensate?
Some of the kernel and initramfs time hit comes from xz decompression. I wonder if zstd can also compensate? Getting zstd module built into the kernel to support zstd compressed initramfs is straightforward, but I vaguely recall something extra is needed to support zstd compressed kernels.
>
> 2) They contain machine-specific configuration. Some of this can be
> passed on the kernel command line instead (eg, the machine ID), but we'd
> need answers for the rest. I can think of a couple of solutions:
>
> a) Stick the config in UEFI variables. It's small enough that we
> wouldn't run out.
> b) Extend grub to read some config files and synthesise an initramfs
> image for them. If we measure the paths that those images use then
> we don't need to worry about the contents as long as the tools that
> read the config can't be subverted via that configuration.
Any expected hardware with TPM2 but without UEFI?
There's a systemd facility for extra boot params to contend with the arch specific COMMAND_LINE_SIZE limit. I forget what it is, maybe it uses efivars.
>
> 3) User customisation, such as including extra tooling. grub supports
> loading multiple initramfs images. Packages that right now install stuff
> in the initramfs could instead ship a prebuilt image that grub could
> append to the main initramfs. This would allow for things like
> overriding Plymouth themes, and we could ship the measurements for these
> pre-built images in order to allow them to be validated.
If the first initramfs contains systemd, could systemd start things in parallel while unpacking a second initramfs?
I take it you've found some liability with measuring a locally produced initramfs?
--
Chris Murphy
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
