On Wed, May 10, 2023 at 2:24 PM Owen Taylor <otay...@redhat.com> wrote: > > > > On Wed, May 10, 2023 at 12:02 PM Neal Gompa <ngomp...@gmail.com> 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 :-) >
fsverity is separate from fscrypt. We can apply filesystem authentication today. > 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? > No. It initializes the whole operating system, and then pivots the user-space later. That's why we have to everything in initramfs. UKIs attempt to standardize the early-stage image without attempting to solve this problem, because a two-stage boot process requires changing how we think about operating system initialization. In Windows, the Windows Boot Manager loads the NT kernel stub from the NTFS volume, which then loads the minimal operating system environment, and bootstraps the full Windows experience. The Windows Boot Manager has just enough to handle BitLocker and NTFS, and then transfers the rest to Windows itself. This means that you can do interesting things by simply replacing the Windows Boot Manager with another boot manager that includes more features. As an example, Quibble[1] replaces the Windows Boot Manager to enable booting Windows off Btrfs. [1]: https://github.com/maharmstone/quibble -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
