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.