hidden grub menu feature, bootloader writing to grubenv

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

 



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




[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