On Mon, Jan 20, 2020 at 5:58 PM Matthew Garrett <mjg59(a)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