Ubuntu wants to strip some of GRUB features in 26.10 for security purposes
dryarzeg
48 points
36 comments
March 25, 2026
Related Discussions
Found 5 related stories in 30.2ms across 3,471 title embeddings via pgvector HNSW
- Ubuntu now has higher system hardware requirements than Windows 11 bundie · 21 pts · April 03, 2026 · 49% similar
- Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords akersten · 345 pts · March 21, 2026 · 49% similar
- Ubuntu is planning to comply with Age Verification law taubek · 16 pts · March 04, 2026 · 48% similar
- Nanny state discovers Linux, demands it check kids' IDs before booting jjgreen · 196 pts · March 13, 2026 · 46% similar
- Linux 7.1 to Retire UDP-Lite – Allows for Better Performance with Cleansed Code doener · 42 pts · March 16, 2026 · 44% similar
Discussion Highlights (4 comments)
gorgoiler
Regarding dropping support for a LUKS encrypted /boot, one of the comments chimes in with “[but] full disk encryption is mandatory in many environments in Europe for security conformity”. Surely some user editable data has to be stored in plaintext to be able to boot a system? Does grub.cfg need to be signed by the trust chain to be able to boot?
longislandguido
Have they replaced it with grub-rs yet? On a more serious note, grub is ancient bloatware, it is way overcomplicated for what it does, it's asking to be replaced by systemd-boot distro-wide. Look at Apple and Microsoft's bootloaders, they are dead simple and have barely changed in 20 years, it makes you wonder how the hell grub was even conceived. It has config files for config files. grub tries to do the kitchen sink. But we live in a UEFI world now. Boot is simple. None of that is necessary anymore.
Zardoz84
I glad that I moved to green pastures... Aka Debian.
hedora
This comment is particularly concerning (as is the functionality regression implied by this new "more secure" approach): > This means for example, that an encrypted system must use an ext4 /boot partition; it is no longer possible to encrypt the /boot partition. So, they want to let attackers modify /boot, including grub.conf and the kernel command line? This is better? Look at all these fun knobs attackers will be able to turn! https://www.kernel.org/doc/Documentation/x86/x86_64/boot-opt... This lets you disable machine check exceptions + the iommu. That means it'll force people to use a configuration that lets attackers stick a memory probe hardware device into the system + bypass a bunch of hardware security checks. Nice! I also found module.sig_enforce which lets the attacker disable kernel module signature verification. Sadly, I couldn't find anything that lets you directly load a kernel module from /boot. However, init.rd lives in /boot. I wonder if its signature is verified or not. At the very least, this approach implies that attackers can piecemeal downgrade stuff early in the boot process.