Hi, The more I think about the bootloader writing to grubenv, the more I'm not a fan. I'm really suspicious of even the general case of anything doing (over)writes outside of the file system. Is block device writing something all UEFI firmware support? Even with Secure Boot enabled? Setting aside the default Workstation partitioning, some valid alternative schemes that I expect are problematic: - On UEFI, the installer supports (against all advice) using mdadm raid1 to sync multiple EFI System partitions. GRUB writing to grubenv is going to write to which device? And on next boot, which grubenv copy gets read? And now that the array is out of sync, there's no way of determining which one is correct, but more importantly is the potential for non-deterministic behaviors. - On BIOS, /boot can legitimately be on Ext4, Btrfs, XFS, md, LVM, LUKS. And GRUB can mostly read these format. Writing is another thing entirely: - On Btrfs, this 1KiB grubenv at creation time is written as an inline extent in metadata. That means it cannot be flagged as nocow, as metadata is always COW, and always checksummed. A 2x 512 byte overwrite to the physical sectors for grubenv, will corrupt the entire 16KiB leaf. GRUB is not doing COW, nor even recomputing checksums for the leaf and overwriting the leaf. And doing overwrites on a COW file system by 3rd party code makes me think of one thing: ! Now, I have no idea if GRUB has protection against doing writes in dangerous cases like this. Or if it's just expected developers won't ask GRUB to do dangerous things. I've asked upstream. Meanwhile, ext4 now supports inline extents, and metadata checksums. So if both of those features are used or become the default, then the same problem applies. An overwrite will corrupt the block. XFS now supports reflinks (not the default yet), overwriting the 1024 byte grubenv sectors doesn't corrupt XFS, but it in effect overwrites all the reflinked copies, which is a kind of sabotage of what's supposed to be a COW file, and is seriously damaging to user expectations and therefore trust. Who would reflink copy grubenv? No idea. But that doesn't even matter. The grubenv design has increasingly serious problems, the more sophisticated the file system gets. Already we have real cases where GRUB code for *reading* file systems isn't keeping up with what file systems can do, for example GRUB can't do journal replay, so there's no actual guarantee it has the proper view of a file system's state. The file system might say grub.cfg is located at AB, but the journal says, nope that was replaced, I know where the current copy is. And then there's md, LVM, eventually possibly thinp/Stratis support, and crypto. GRUB is not going to write out new PQ parity if /boot is on md raid. Is it going to encrypt those two 512 byte sectors before writing them? I don't know what the solution is but right now it's a fragile design. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
