On Di, 14.10.25 00:49, Chris Murphy ([email protected]) wrote: > On Mon, Oct 13, 2025, at 10:24 AM, Lennart Poettering wrote: > > > Moreover the last time I looked it writes boot counter updates and > > such directly to disk, bypassing the file system log. That's really > > evil, and certainly doesn't help integrity guarantees. > > GRUB only writes to grubenv, and without a file system driver, > because they're all read-only. The writes to grubenv aren't allowed > by GRUB btrfs and zfs modules (probably also luks, lvm, and > md). There is a patch to use the Btrfs bootloader pad for grubenv, > it's only 1 KiB. And then GRUB and read and write to it there.
BTW, for btrfs the first 64K of the disk are entirely unused, it would be trivial for grub to put its data there without asking anyone for cooperation. The first copy of the btrfs superblock is at offset 64K. Still a really really bad idea though, but just pointing that out. Bypassing or even corrupting an fs when doing updates to a disk, is a terrible idea. > > (And as mentioned elsewhere, you cannot avoid VFAT because mandated by > > UEFI for ESP, and the data there has similar update/write cycles as > > /boot, so nothing is gained by a different fs) > > ESP is infrequently updated compared to XBOOTLDR. > > It's not correct nothing is gained by a different fs. Aside from > pooling, (open)SUSE has leveraged Btrfs for bootable snapshots. Can > Fedora do this some other way? Yes, it'd be more work, rather than > leveraging what Btrfs is designed to do. GRUB follows snapshots just > fine, and has for a very long time. Whenever you do something like this it implies you are not interested in a proper, modern authentication/encryption boot chain, because if you do that you basically have to turn your boot loader into something that speaks verity, does tpm2 measurements and policy enforcement, that does fido2, and pkcs#11. And frankly, that's just not realistic to reimplement in a boot loader. Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
