Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 10, 2023 at 2:24 PM Owen Taylor <otaylor@xxxxxxxxxx> wrote:
>
>
>
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa <ngompa13@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux