Ubuntu Looks To Strip GRUB To The Bare Minimum For Better Security
15 points by UkiahSmith
15 points by UkiahSmith
For EFI systems, why not just use Linux kernel with efistub? It'd eliminate GRUB entirely, especially if you intend to pare down GRUB to the point where it lacks many features at all.
I was wondering this too... or also why not systemd-boot, which can also work with zfs?
They replied further down in the thread. systemd-boot is uefi only and they need to support non-EFI platforms. And rather than support multiple bootloaders like some other distros, they're just sticking with the one that ticks all the boxes they need.
From the discussion it sounds like they still want to stick with GRUB not just for its BIOS support but also because it supports different architectures. Maintaining support for several bootloaders depending on system configuration would likely increase the maintenance burden too much.
From the discussion it sounds like they still want to stick with GRUB not just for its BIOS support but also because it supports different architectures.
There might be some architectures that it doesn't support (such as ppc), but it does support different architectures. I use it on aarch64, loongarch64, and x86_64. It also works on RISC-V.
Believe I'm using this on one machine, it is the UKI stuff?
It works fine most of the time, but I lose the boot manager entries when the firmware is updated. Which means a fun recovery session from EFI CLI or systemd-boot, which is what I had before, but it is still on the ESP boot partition.
A pretty large drawback, imho. Will probably go back to only systemd-boot when I am able.
Removing support for encrypted filesystems other than ext4 and support for encrypted boot partition seems like a step back and will break current systems.
Encrypted boot partitions were kind of a joke anyway.
Why? Because of limited security improvements or because it's slow to decrypt /boot from grub?
It gives you no security benefit at the cost of having to deal with two different implementations of LUKS in your boot chain.
In 26.10, we’d like to propose removing the following features from signed GRUB builds:
Filesystems
- Remove btrfs, hfsplus, xfs, zfs
- Retain ext4, fat, iso9660 (and squashfs for snaps)
Huh, in what way could GRUB care about snaps..? Would this be for kernel images distributed through snap? I think it's reasonable to keep squashfs support regardless, it's a wonderful little filesystem for read-only rootfs or boot images, so it doesn't really matter, I'm just curious
All in all, this looks very reasonable.
Would this be for kernel images distributed through snap?
Yes: https://documentation.ubuntu.com/core/how-to-guides/image-creation/build-a-kernel-snap/
just wanna flag, in case others do what I did and jump to the conclusion that this support for the / partition, it's not.
They are proposing that grub slims down the scope of WHERE it can be installed and where the files required for its operation can be. so... the /boot partition.
TL;DR they are proposing what is already a very common best practice:
So.. all in all, I agree, yes please, go ahead, better late than never.
PS: I rather they did this + drop grub and adopted systemd-boot
A little sad to make booting ZFS even harder. The issue is durability: it's nice to have redundant storage for this most important partition!
Proxmox has a reasonable workaround. It has a ZFS-centric Debian distribution. But it doesn't boot on ZFS partitions. Instead it creates an ext4fs partition for /boot. The neat thing is if you set it up with ZFS redundancy, like RAID-Z1, it will also create mirrored ext4 partitions for booting with identical contents on each disk. There's some userspace code to keep them in sync and (I think) something clever in the bootstrap to automatically boot off a backup partition if the primary is down. It's a kludge but it seems to work.
The real solution here is to greatly simplify things and use efistub or the like. EFI should do the booting, not GRUB.
the ZFS support in GRUB was lipservice only tbh, because you had to restrict the entire zpool to boot to the feature set grub supports and now you can't do anything fun (or modern) on it without risking the bootability of the system. I do kinda understand why GRUB wouldn't wanna invest the hours needed to bring their implementation up to speed, but it's blegh.
A little sad to make booting ZFS even harder.
ZFS boot menu exists and I've deployed it at my day job for efi builds.
This conversation is like:
"We will remove X, Y and Z"
and each comment is about:
"But I use X"
"But I use Y"
"But Z is a very common usecase in the industry"