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