On Wed, May 10, 2023, at 2:24 PM, Owen Taylor 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.
In this idea, the dm-verity parition/file would only be accessed from the initrd, once we have enough kernel to ability to interact with physical storage, understand partitions, initialize dm-verity, and read *a* partition, but potentially not enough to read from a bluetooth keyboard, show a graphical prompt, mount / from the network, etc.
What dm-verity provides here is a way to trust content without requiring it to be read ahead of time, checksumed, signature checked and put into ram.
To be clear, I don't think this is necessarily the right way to go - I think using efifb, not prompting for a passphrase when possible, etc, are simpler approaches.
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.
The elephant in the room is whether the "desktops in the default installation" UKI requires piles of graphics firmware. It might not be at all small in that case.
- Owen