On Wed, Dec 21, 2022, at 12:00 PM, Lennart Poettering wrote:
On Mi, 21.12.22 10:03, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
> For the general case we need some other option. Could be just stick to
> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
> and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers,
> for example this one:
>
https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg
I am pretty strongly against the idea of ext4 for /boot/.
First of all, the firmware can't read it natively, but what's worse,
uefi cannot even make sense of any of the features it provides above
vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs,
symlinks, … are all complete nonsense to the UEFI fs layer (and to
boot loaders that natively implement the fs drivers, the same). The
UEFI fs API has no concepts for *any* of these features. Hence, if
this is supposed to carry data intended for consumption by the boot
loader, why the f**k would you use a file system it cannot even
remotely take benefit of?
And for btrfs, the GRUB btrfs.mod doesn't do any checksum checking at all, so
there's not even an incremental improvement to integrity, let alone any support for
fs-verity. So while I like btrfs for /boot due to the space efficiency advantage (I
don't have to ask how big boot should be, no space is wasted and I don't run out
either), I'm willing to give it up for practical matters like simplicity and reduced
attack and maintenance surface area.
--
Chris Murphy