On Wed, May 10, 2023 at 12:02 PM Neal Gompa <[email protected]> wrote:
> > This proposal isn't better. Neither Windows nor macOS put critical > operating system code in the ESP, and we shouldn't either. But you > want to put kernels in the ESP? That's the wrong approach too. > > As soon as you throw UKIs in the mix, you've completely broken that > because now the absolutely most valuable code for your system is in a > "hostile" environment. At least we can make /boot authenticated and > tamper resistant as a Btrfs subvolume. > As other people have mentioned, we have a solution for the ESP being untrusted - secure boot. As far as I understand, there's no tamper resistance for /boot on btrfs unless it's encrypted, and that would be a whole other barrel of snakes :-) 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". I would rather have a multi-stage boot process, where the first stage > does just enough to unlock and load the OS volume to load the real > boot environment. > "unlock and load the OS volume" is pretty much what the initramfs does, right? - Owen
_______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
