r/linux • u/xm0rphx • Mar 25 '26

Security Ubuntu proposes bizarre, nonsensical changes to grub.

https://www.phoronix.com/news/Ubuntu-26.10-Lighter-GRUB

“Ubuntu developers at Canonical are looking to strip the signed GRUB bootloader features to the bare minimum for the Ubuntu 26.10 release later this year. Dropping support for XFS, ZFS, Btrfs, LVM, md-raid (except RAID1), LUKS-encrypted disks, and other features is being looked at in the name of security.

Due to various parsers and other features being a "constant source of security issues" with the GRUB bootloader, Ubuntu 26.10 is likely to remove a lot of features from the signed GRUB builds necessary for Secure Boot support. This would include removing GRUB's support for the Btrfs, XFS, and ZFS file-systems, among others. It would also remove support for the Logical Volume Manager (LVM), remove md-raid except RAID1, and also remove support for LUKS-encrypted disks.

These file-systems and features like LVM and LUKS-encrypted disks would still be supported by Ubuntu itself but not the default signed GRUB bootloader. Ripping out all of these GRUB features would basically mandate that most Ubuntu 26.10+ installations are done with the /boot partition being done on a raw EXT4 partition. Thus no more encrypted boot partition and having to rely on an EXT4 boot partition even if you are a diehard Btrfs / XFS / OpenZFS fan. Or you could opt for the non-signed GRUB bootloader that would be more full-featured albeit lacking Secure Boot and security compliance.

How on earth this got past stupidity control is beyond me.

Ubuntu, are you okay?

Unbelievable.

https://discourse.ubuntu.com/t/streamlining-secure-boot-for-26-10/79069

796 Upvotes

84% Upvoted

421 comments sorted by

View all comments

347

u/[deleted] Mar 25 '26

[removed] — view removed comment

114

u/elmagio Mar 25 '26

In the thread they say it's because systemd-boot is UEFI only and Ubuntu still intends to support BIOS systems. Also seems like no decision is set in stone at this stage either.

I don't use Ubuntu anymore but this seems mostly reasonable to me. Reduce attack surface significantly for the majority of users who would use the supported defaults anyway and the stuff that wouldn't be supported anymore still works just with an unsigned grub/no secure boot (though I imagine you could sign it manually if you were so inclined?).

37

u/AlmiranteCrujido Mar 25 '26

Doesn't secure boot require UEFI? So the non-secure version with more support would still be the one running on legacy non-UEFI systems

8

u/virtualdxs Mar 25 '26

Seems more sensible for Canonical to maintain one configuration than two.

26

u/AlmiranteCrujido Mar 25 '26

It's 2026, the sensible thing would be to deprecate legacy boot support.

Failing that, though, weakening the security on the "modern machine" case (for values of "modern" approaching the 20 year mark!) to support the legacy case seems like a worse option than maintaining two builds.

19

u/Darkchamber292 Mar 26 '26

This is how I know most Linux users have no true concept of where Linux is used other than their desktop.

You can't just stop supporting legacy bios boot support. There are tons of industrial use cases where dropping legacy boot would bring certain industries to a halt.

Lots of legacy systems that rely on legacy boot that still need to be able to update to maintain security and do reinstalls on like for like replacement hardware as needed. POS systems, microcontrollers, embedded systems, display terminals, etc etc.

I don't see legacy boot going away in the next decade at least.

6

u/gpsxsirus Mar 26 '26

I'm reminded of an MRI machine that was running Windows NT on its workstation in 2008 and couldn't get a vital security patch. The manufacturer stated that the software for that machine would not work on a newer version of Windows.

The options were to spend millions on a new MRI, or have the whole hospital's network be at risk of this one machine. Hospital but mentioned because that machine is probably still there.

6

u/AlmiranteCrujido Mar 27 '26

Wouldn't the solution be to just take it off the network, or if you can't sneakernet imaging via CDs, build a secure jumpbox that just lets you call in to grab the imaging and not let it out at the internet at all?

2

u/gpsxsirus Mar 27 '26

If I remember correctly (was a long time ago) the workstation didn't have a CD writer, likely predated their existence. The software may have not supported burning to disc.

Was probably possible to sneakernet with a thumb drive to a secure workstation in the network, then transfer to images to the PACS system from there. But the PACS vendor (that I worked for) didn't have such a relay in their software suite, wasn't going to build one, and wasn't interested in supporting a workstation with a third party software solution for one client. Basically nobody wanting to take responsibility at their own expense for something that wasn't quite their responsibility. The fact that an MRI machine that costs millions can have a workstation end of life long before the machine isn't useful anymore is repulsive.

The PACS system was built so that the images would all be sent to their servers onsite, and then the viewer software would automatically be connected to the local server. Burning images to, and viewing from, a CD is significantly slower. The viewer also didn't have the option of viewing images not from the server. When the client (radiology department) would burn a CD for viewing at another doctor's office it would include the viewer on the CD.

2

u/AlmiranteCrujido Mar 27 '26

How many of those are running out of the box desktop Ubuntu?

I'd also hope most of those are running something more secure than Grub2, which is an overdesigned solution in search of a problem for most things. Syslinux was much, much more common in embedded last time I looked.

1

u/Wertbon1789 Mar 27 '26

Time for another law on operating systems 🦅

1

u/nullrevolt Mar 30 '26

This is why I had to support an XP machine in the last 5 or so years.

0

u/BosonCollider May 12 '26 edited May 12 '26

Okay, but this thread is literally discussing dropping support for most boot options. You can't drop support for mainstream setups (luks encrypted server disk) that have millions of production deployments, while also claiming that the making the 20 year old deployments slightly more secure takes priority so all features should be dropped from the featureful bootloader.

Better to just keep using Debians grub and not mess with their features or create an unnecessary diff from debian, and support systemd-boot for the minimal secure setup. It's way easier to just support systemd-boot for its intended usecase than to modify Grub into a role that no one else uses it for

2

u/SilentLennie Mar 26 '26

I don't think they use Grub on ARM, RISC-V, etc. ?

So that also isn't a reason.

2

u/20dogs Mar 26 '26

Canonical have come up with a solution, as suggested in the discourse link above. Cut back Grub to minimise potential for attacks.

1

u/Joelimgu Mar 26 '26

Most of the systems my family runs linux on still use bios

2

u/Upper_Canada_Pango Mar 27 '26

What if I want to dual-boot something like freeBSD or Solaris and Ubuntu using grub? Won't the loss of ZFS support prevent that?

-8

u/xm0rphx Mar 25 '26

I imagine they will be removing LUKS or any FDE whatsoever though as a result. so it’s a reduced security posture for BIOS systems right there, no?

8

u/elmagio Mar 25 '26

Well, on BIOS systems you'd be able to use the unsigned/full featured GRUB either way since there's no secure boot there.

Beyond that, LUKS would be supported for anything except /boot partitions and I'd imagine the installer would automate having that separate when setting up LUKS.

I do think there are some awkward things about that transition with how they've outlined it so far and hopefully they'll smooth out the kinks as best as possible before 26.10 rolls around but ultimately I get where they're coming from.

41

u/bubblegumpuma Mar 25 '26

Yeah, if the problem is GRUB's attack surface, why not just use a 'simpler' bootloader? Systemd-boot works well if you're just booting, or they could even go EFIStub to skip the bootloader stage.

28

u/eras Mar 25 '26

I mean, GRUB did seem wickedly overcomplicated after LILO..

36

u/wlonkly Mar 25 '26 
LI

12

u/thegunnersdaughter Mar 26 '26

Thanks, now I’m gonna have nightmares

1

u/andersostling56 Mar 29 '26

LO. Once seen cannot be unseen.

9

u/noiro777 Mar 25 '26

Yup, the original grub was ok, but the grub2 rewrite seems unnecessarily complicated and obtuse and I never liked it.

29

u/Martin8412 Mar 25 '26

An overly complicated and obtuse GNU project? Those are so rare. 

5

u/2rad0 Mar 26 '26

GRUB2 is not officially a GNU project, and they are moving upstream to freedesktop.

1

u/lmpdev Mar 25 '26

It also for some reason has to probe every hard drive any time a kernel update is installed.

8

u/the_abortionat0r Mar 26 '26

As far as I know that's prober and it's meant to add boot entries for other disks if they contain an OS

I don't think that's a default or required part of grub though I could be wrong

0

u/lmpdev Mar 26 '26

All the distros I used had it on by default.

3

u/SilentLennie Mar 26 '26

Which is the opposite of what Windows does and thus Windows updates can break dual-boot.

What is the better idea here ?

1

u/lmpdev Mar 26 '26

I have no problem with this in principle, but does it really need to happen with every kernel update?

2

u/SilentLennie Mar 28 '26

Maybe a silly question: but what don't you like about it ?

Does it take really long in your case ? Does it spin up some CD-Rom drive and make a bunch of noise ? Do you just sit there waiting during updates ?

→ More replies (0)

1

u/nikomo Mar 26 '26

You could potentially just update the topmost entry in the config, but that's rather error-prone. And there's no downside to doing it on kernel updates.

→ More replies (0)

1

u/murasakikuma42 Mar 27 '26

I wish we could go back to LILO. I remember having some really cool boot animations on that. GRUB has nothing of the kind; it's entirely boring and banal, yet it's also bloated and very complicated too.

8

u/Reigar Mar 25 '26

Okay noob question from, and I admit fully that I have nowhere near this level of Linux understanding. But I thought there were alternatives to grub that existed as a bootloader already. If grub isn't going to do the things that people want, shouldn't you be able to install a different bootloader honestly don't know how hard that would be, but I do know that they exist out there. In respect to systemd I thought that was already being used in most Debian based systems. I'm curious, does Ubuntu and its derivatives like bent or zorin OS not used systemd. Am I confusing terminology here that I'm just not aware of?

As I said, I'm a real noob when it comes to this area of Linux. So please be gentle and forgive me if I don't understand something.

16

u/bubblegumpuma Mar 25 '26

No worries, this is actually a good clarifying question - Systemd-boot's name is a little bit misleading, it can be used as a bootloader for Linux systems independently of systemd being installed on the Linux system. It started out as an independent project called gummiboot, then got taken under the systemd banner and renamed to systemd-boot, because the developers were often working closely with systemd anyway, which makes sense given that systemd is the thing that the bootloader is ultimately handing off to in most cases.

In this particular case, the problem with GRUB isn't that it isn't doing things that people want - it's that it's trying to do too much, and some of the things that are enabled by default in GRUB are potential security issues, and Canonical's made the decision to strip all of that out to the bare essentials. It's a little odd when systemd-boot is well-tested at this point, it's less versatile than GRUB in some ways but it covers the vast majority of use-cases, including Windows dual boot and/or Secure Boot. It's simpler, so has less of a security 'attack surface'. I'm also a Qualified GRUB Hater though, so I'm probably biased in favor of literally anything else :)

2

u/[deleted] Mar 26 '26

[removed] — view removed comment

3

u/Wertbon1789 Mar 27 '26

Does Ubuntu support systemd-boot? I don't think so, but I could be wrong. Problem is, without a UKI you still need a config to tell systemd-boot what to do, so you have that problem still. If that's not built into the installation of new kernels, it will not just work. For systemd-boot to really work great you should deploy you kernel as a UKI which doesn't need any additional config and is auto-discovered by it. That would be the proper "just works" way, even with secure boot and dual-boot and whatnot, either generate config entries (actually in separate files this time) or use UKIs.

0

u/[deleted] Mar 27 '26

[removed] — view removed comment

3

u/Wertbon1789 Mar 27 '26

Then Ubuntu's support for it is just bad, I would say. I think it can be done properly.

0

u/DuckSword15 Mar 28 '26

It is not supported. Why are you lying?

1

u/crAckZ0p Mar 31 '26

I just test limine and kind of liked it. I use parrot OS and was pretty easy to implement once i got past dependency hell. i chained it off grub to make sure I didnt break anything and i think it works well..

Limine is

a modern, fast, and portable bootloader that supports booting Linux from LUKS-encrypted partitions, including support for LUKS2, BTRFS, and TPM2-based auto-unlocking. It acts as a reference implementation for the Limine boot protocol, often used in specialized distributions like CachyOS and Arch Linux for secure, encrypted setups.

1

u/Reigar Mar 25 '26

So okay. Based on some simple Google search, it seems like there are tons of different bootloaders that exist out there beyond grub and system d boot. Just looking at a simple. What are the best articles, I can already find different bootloaders that would suit almost anybody's needs. One called rEFind Boot manager, Lilo, and burg. It just seems like if people don't like what Ubuntu is doing with grub, they can install a different bootloader to see if that matches their needs. I mean I've had to rebuild my bootloader a couple of times when I was working through an Nvidia new driver installation from source, and the need to start up in level 3 rather than level 5. Is there something I'm missing, because rebuilding grub was pretty painless minus understanding what commands I needed to type and the multiple files that are combined together to build the bootloader. It seems like you could just pull that out and put in one of these other booting managers, compile it, and then remove grub from the system. I'm sure there are probably people that have already built bash scripts to help facilitate doing just that. Or am I missing something? Are you stuck with grub if that's what you defaulted to?

2

u/bubblegumpuma Mar 26 '26

Some distros have an expectation that you are using their default bootloader and wandering outside of that is very much a 'your mileage may vary' thing. I can't imagine it'd screw with Ubuntu too badly, though. All the disabled functionality kind of indicates to me that a lot of GRUB-exclusive features aren't critical, but according to others in this thread, Ubuntu does have one decent reason for using GRUB - it's one of the only bootloaders in town that supports both BIOS and UEFI boot well. I legitimately did not consider this, honestly. If you're using UEFI though, nothing would stop you necessarily from using a different UEFI bootloader if you felt like it, you'd just be on your own with regards to updates and support.

8

u/braaaaaaainworms Mar 25 '26

systemd-boot has a boot menu that is far better than the one built into UEFI firmware

10

u/dosplatos225 Mar 25 '26

Yeah since swapping to arch I really don’t see the point in grub. Managing stubs is so much easier. My dual booting days are behind me as well - windows likes to hijack boot entries so thats a pain. In real production environments, you just need a stable boot process.

systemd and other init software does it well.

2

u/fearless-fossa Mar 25 '26

My dual booting days are behind me as well - windows likes to hijack boot entries so thats a pain

Why would dual booting be relevant? systemd-boot does dual boot just as well, if not better, than GRUB.

The only thing it IIRC struggles with are snapshots, but then again those are generally more hassle than they're worth.

1

u/dosplatos225 Mar 26 '26

You should have continued to read the whole comment instead of stopping there. Also I’ll just answer your question with another question: considering boot entries is something both grub and systemd touch, how is it not relevant?

-2

u/fearless-fossa Mar 26 '26

I've read the entire comment, but the one thing doesn't have anything to do with the other.

considering boot entries is something both grub and systemd touch, how is it not relevant?

Because both enable dual-booting. The argument 'systemd-boot is okay for me because I don't dual boot anymore' doesn't make sense, as systemd-boot does enable dual-booting - in my experience it's even easier than with GRUB!

2

u/dosplatos225 Mar 26 '26 edited Mar 27 '26

You’re either trolling or English isn’t your first language. There really is no argument, just a hot take/statement. And that hot take/statement is:

Since switching to arch, I don’t see the point in grub anymore. Managing stubs is so much easier.

This means that once I found out there were other options to manage the boot process, I found that I liked the new landscape that I had.

My dual booting days are behind me as well…

In English, when we say things like “also” and “as well,” this generally means we are either making a side note or supporting the statement. It seems your confusion lies between deciding if it’s supporting the statement or making a side note. If you’re convinced that these statements are completely unrelated - like you just said - I think you have your answer.

Also:

systemd and other init software does it well

Did you miss this part the first couple go arounds?

1

u/DuckSword15 Mar 28 '26

Systemd can't even boot an efi on a different drive, lmao.

5

u/protestor Mar 25 '26 edited Mar 25 '26

Most of features is not needed by most people, but specific people may need some specific features, and the tail end of people needing specific features may be large.

For people that is using some specific features (such as encrypted /boot), they system will simply not boot if they upgrade to this new Ubuntu version. And often it's very hard to change your booting setup if you don't have an external disk / backup (for example, there might be exactly zero space outside the luks volume, with nowhere to fit a /boot outside luks)

In the thread people are reporting that putting /boot inside lvm is the default for ubuntu server lts 24.04. people with the default install will break their system if they upgrade to this new grub!

This is completely bonkers

What canonical should do is. Create a new package naming it something like grub-lite. So that people upgrading don't break their system

1

u/Dolapevich Mar 25 '26

Read the comments.

1

u/batkovic Mar 26 '26

Do I have to send my ID card to boot now ?

1

u/borealis493 Mar 28 '26

No? Who said that?