On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
On Wed, May 10, 2023 at 12:02 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
Now, there's a second problem with reading everything from the ESP - it's slow
for two reasons. First, because read speeds when going through the firmware are much
slower than the Linux NVMe stack. And second, because we have to read everything in order
to checksum and verify it.
For that reason, Demi's suggestion of moving things onto a dm-verity protected
partition is intriguing. Could that even be a loopback file on the ESP? It would be like a
lazy-read system extension.
The performance geek in me thinks "we could see exciting speedups from that!" -
the practical side of me thinks "it might be a few second faster. And much more
complex! Let's just go with efifb, keep the initramfs small, and accept any minor
regressions".
GRUB doesn't support dm-verity, but I don't know if it would make a difference if
it did. Once the kernel has the ability to interact with physical storage, understand
partitions, initialize dm-verity, and read a file systemt... it could just mount `/` . I
think the only way the current initial root file system works with the kernel is for the
bootloader to read an entire initrd file into RAM, and then the kernel can randomly access
things in that RAM disk.
It's early still for UKI details but I assume we will need both a universal UKI (all
use cases), and much smaller use case focused UKIs. I say that because the desktops in the
default installation configuration are the largest single use case. With Btrfs built-into
the kernel, we don't need that much in the initrd to setup block devices, discover
their contents, and perform switch root.
The next most common use case(s), device-mapper and md based, require a pile of user space
programs running to do all the work setting things up. Maybe we can just get away with two
images, a simple fast one and the universal.
--
Chris Murphy