On Mon, Jan 20, 2020 at 5:58 PM Matthew Garrett <mj...@srcf.ucam.org> 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
