On Wed, May 10, 2023 at 5:34 PM Chris Murphy <li...@colorremedies.com> wrote:
> > > On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote: > > > > On Wed, May 10, 2023 at 12:02 PM Neal Gompa <ngomp...@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. > 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
_______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
