On Wed, May 10, 2023, at 7:36 PM, Owen Taylor wrote: > > > 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.
OK got it. So it would be some kind of intermediate /usr that bridges between initramfs and /sysroot mounting? I'm not sure the added complexity helps significantly with authenticity over either LUKS or fscrypt. > >> >> 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. True. I don't know what the limitations/reasons are for firmware blobs needing to be available so early during boot. But (a) we have chosen a file system by default that we can shrink online (b) have at least 128 partitions possible (c) we can extent Boot Loader Spec to permit multiple XBOOTLDR. So we can make room for these firmware blobs. It's just fricking ugly. And I'm not sure it'll be RPM's domain if these things really need to exist on /boot. Something will have to put them there, as needed. -- Chris Murphy
_______________________________________________ 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
