Ubuntu's GRUBby plans [LWN.net]

By Joe Brockmeier
April 3, 2026

GNU GRUB 2, mostly just referred to as GRUB these days, is the most widely used boot loader for x86_64 Linux systems. It supports reading from a vast selection of filesystems, handles booting modern systems with UEFI or legacy systems with a BIOS, and even allows users to customize the "splash" image displayed when a system boots. Alas, all of those features come with a price; GRUB has had a parade of security vulnerabilities over the years. To mitigate some of those problems, Ubuntu core developer and Canonical employee Julian Andres Klode has proposed removing a number of features from GRUB in Ubuntu 26.10 to improve GRUB's security profile. His proposal has not been met with universal acclaim; many of the features Klode would like to remove have vocal proponents.

Ubuntu provides two versions of GRUB: one for UEFI systems that enables Secure Boot (referred to as the "signed" builds), and another for systems with legacy BIOS or systems that otherwise don't support Secure Boot (the "unsigned" builds). The unsigned GRUB builds from Ubuntu would continue to have the existing set of features, but Klode is looking to strip quite a bit out of signed GRUB builds; he proposes removing support for reading /boot partitions that use Btrfs, HFS+, XFS, or ZFS filesystems. That would leave ext4, FAT, ISO 9660, and SquashFS. He also wants to disable features to use custom PNG and JPEG splash images, and strip out support for "complex partition setups such as LVM, md-raid (except raid1), and LUKS-encrypted /boot" because those were not tested nor used by the Ubuntu installer.

As for encryption in particular, encryption of /boot only provided security by obscurity, but not actual security. You want to ensure the integrity of those pieces. Our TPM [full-disk encryption (FDE)] solution correctly implements integrity in the early boot stage, and we are committed to keep iterating and improve it.

None of these changes would affect Ubuntu's support for the filesystems in general; users could still have (for example) a Btrfs partition for user data. They simply could not use Btrfs for /boot. The changes are not scheduled for the upcoming long-term-support (LTS) release, 26.04, which is due in April. Thus, he said, affected users (those who want the features being removed) would have the option of staying on an LTS release with the GRUB features for up to ten years.

Klode isn't the first person to decide that GRUB has too much complexity and too many features that pose security problems. For example, GRUB maintainer Marta Lewandowska has advocated getting rid of bootloaders altogether in favor of Unified Kernel Images (UKIs).

Pushback

Dropping features from an upstream application is rarely popular, as Klode no doubt discovered when turning off optional KeePassXC features in the Debian package he maintains. The tactic has proven no more popular with GRUB. Neal Gompa was first in line to object to Klode's plans; specifically, he complained about dropping Btrfs support. He argued that the support was necessary for those who want to use boot-to-snapshot setups. User "haroldw" pointed out that it is unnecessary, and perhaps undesirable, for /boot to be Btrfs-formatted for snapshot support to work: "Grub doesn't respect the default btrfs subvolume settings leading to easy breakage and requiring to modify kernel parameters in grub.cfg." Gompa did not seem to be persuaded, and still wanted to be able to use Btrfs features to resize /boot if desired.

Quite a few people wanted to preserve support for JPEGs and PNGs. Gompa, for example, argued against removing support since some of the Ubuntu flavors use images as part of their branding. Sebastian Schneeland not only objected to removing image support, but wished for an easier way to make a graphical boot menu with friendly labels for each entry. Paddy Landau said that he would be disappointed if Ubuntu removed image support. "I've been seeing my welcoming Ubuntu background when I boot for many years!"

Some suggested ditching GRUB entirely. Andreas Schildbach (and others) asked about switching Ubuntu to systemd-boot instead. "It's the minimal bootloader you're looking for, and it integrates into systemd-based systems well anyway." However, Tobiyo Kuujikai pointed out that systemd-boot only supports UEFI systems. That would likely be a non-starter, since Ubuntu would then need to support not just two different builds of GRUB, but two entirely different boot loaders, which would no doubt require changes in its installer, how it handles kernel updates, and more.

Robie Basak asked for Klode to cite specific security issues that could have been avoided if the change had happened earlier "given that these security issues of the past are the sole motivation for this change". Thomas Ward, a member of Ubuntu's Community Council and its Technical Board, said that Klode's proposal needed further discussion as well as "a deeper explanation of how this is going to improve security for each dropped item". He said that Ubuntu would be alienating the majority of its users and requiring organizations with specific requirements to forgo the use of Secure Boot.

I want to hear the Foundation team's reason for each removal. If you are unable to provide an ample justification for each removal, then the Foundations team needs to not abandon existing feature sets on the basis that "it makes GRUB Signed more bare and thus more secure because there's less open holes for risks".

While Klode did not reply with specific examples, Tobias Heider supplied a list of 11 recent CVEs "that would have been avoided by not shipping drivers that Ubuntu doesn't actually use", including CVE-2024-45774, which affected GRUB's JPEG parser. The flaw could allow an attacker to supply a "specially crafted JPEG" that would cause GRUB to perform an out-of-bounds write, that in turn might allow a Secure Boot bypass.

If you go through the list of CVE search results you will find that there are plenty and often in parts that Ubuntu doesn't actually use or support in any way.

Keep in mind the grub drivers are only ever needed to get to the kernel and initrd files which are on the /boot partition, after that we use the kernel drivers for LUKS and file systems.

Signed, sealed, delivered

Users were also concerned about not having LUKS encryption for the /boot partition, and the impact on full-disk encryption (FDE). There was a fair bit of discussion and disagreement about the need for /boot encryption. Klode's position is that encrypting the partition did little to enhance security; that stance found a number of supporters. Peter White argued that it was more important to validate everything used in the boot process against cryptographic signatures. "The chain of trust doesn't hinge on everything being encrypted, but on everything being validated against cryptographic signatures; it's about integrity/verity rather than confidentiality." Mate Kukri agreed: "The only solution to this issue is the bootloader to actually enforce initrd signing, /boot encryption and even optional initrd signing is a completely inadequate defense."

Klode replied that Canonical had been working to address FDE integrity concerns by making its TPM-backed FDE boot flow available for Ubuntu Desktop in the 26.04 release, though it is not yet available for Ubuntu Server.

Our TPM FDE solution ensures that the initrd is verified at boot time (it is part of a [unified kernel image (UKI)] for now), and more importantly measured, and the unlocking of the root partition is sealed to that measurement, meaning you cannot even replace the initrd with another validly signed one.

Steven Maddox said that Klode's proposal was the opposite of what he was hoping for. GRUB 2.14, which will be included in 26.04, had just added support for the default encryption used with LUKS2; now it would be removed in Ubuntu 26.10. He complained that users would be stuck with unencrypted /boot partitions of a fixed size "where we have to try and forever judge how big they should be for future kernels and such". He also worried about bad actors being able to modify GRUB's configuration files in the unencrypted partition. White replied that bad actors would not get very far "because they can't coerce GRUB2 into opening an initrd that's not the sealed one". Encryption of the /boot partition, he said, was never a sufficient security measure.

Discussion of the proposal continues. Klode's last appearance in the thread, so far, was on March 27, when he replied about the TPM-backed FDE boot flow. It is not clear whether there is any deadline for feedback or whether any of the objections might alter the plans for stripping features out of GRUB signed builds. It will be interesting to see if any other Linux distributions consider following suit, or if Ubuntu will be alone in trying to streamline GRUB for security reasons.

to post comments

Modules?

Posted Apr 3, 2026 15:21 UTC (Fri) by dskoll (subscriber, #1630) [Link] (3 responses)

Isn't a lot of that functionality found in GRUB modules? Couldn't Ubuntu achieve the safety it needs by not insmodding problematic code in the GRUB configuration file?

Or does GRUB sometimes automatically insert modules without that being explicitly mentioned in the config file?

I do agree that a JPEG parser seems silly. Why not only support an image format that's almost impossible to parse incorrectly, such as PPM, and convert any non-PPM image in user-space when GRUB is installed or updated.

Modules?

Posted Apr 3, 2026 15:27 UTC (Fri) by Conan_Kudo (subscriber, #103240) [Link] (1 responses)

When GRUB is built with Secure Boot lockdown mode enabled, it does not load any modules that are not compiled into the binary itself. So it really matters what is included in grub.efi.

Modules?

Posted Apr 3, 2026 15:32 UTC (Fri) by dskoll (subscriber, #1630) [Link]

OK, thanks for the clarification.

Modules?

Posted Apr 3, 2026 15:28 UTC (Fri) by ballombe (subscriber, #9523) [Link]

There are very few images libraries that have had less security issues than the original IJG libjpeg...

CVE-2024-45774

Posted Apr 3, 2026 18:43 UTC (Fri) by ju3Ceemi (subscriber, #102464) [Link] (44 responses)

How would that be an issue ?

It would require root to tell grub to load a file in a random location (/home or else) ..

CVE-2024-45774

Posted Apr 3, 2026 19:41 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (43 responses)

grub's configuration isn't encrypted (and nor could it reasonably be). An attacker with physical access can drop a file into the ESP and update the configuration to load it, which defeats the point of secure boot. Alteratively, an attacker who has root on a system could do the same and as a result elevate themselves to the kernel.

CVE-2024-45774

Posted Apr 3, 2026 20:06 UTC (Fri) by MortenSickel (subscriber, #3238) [Link] (40 responses)

If an attacker has managed to get root, would anything matter any longer?

CVE-2024-45774

Posted Apr 3, 2026 20:09 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (39 responses)

Yes, being root doesn't give you access to any secrets held in the kernel and isn't inherently a bypass for any MAC policy

CVE-2024-45774

Posted Apr 3, 2026 22:05 UTC (Fri) by ju3Ceemi (subscriber, #102464) [Link] (5 responses)

Does not being root gives you access to everything meaningful on the system ?

CVE-2024-45774

Posted Apr 4, 2026 0:21 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (4 responses)

No, as explained in the post you replied to

CVE-2024-45774

Posted Apr 4, 2026 13:17 UTC (Sat) by ju3Ceemi (subscriber, #102464) [Link] (3 responses)

What kind of secrets would that be .. ?

Being root, I expect being able to read all data files, source code, database and whatever

I can read and modify all network connections, too

CVE-2024-45774

Posted Apr 4, 2026 19:14 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (2 responses)

Anything stored in the kernel keyring, plus things like disk encryption keys.

CVE-2024-45774

Posted Apr 5, 2026 9:32 UTC (Sun) by lobachevsky (subscriber, #121871) [Link] (1 responses)

While I agree with you, I think that assertion needs the qualifier of not being able to load kernel modules. I once successfully used https://github.com/jtsylve/LiME to get the single volume key for an unlocked and mounted LUKS encrypted partition where the passphrase to the slot had been unfortunately lost.

CVE-2024-45774

Posted Apr 5, 2026 13:56 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

Was that with kernel lockdown enabled? Because with secure boot enabled the kernel only loads signed modules.

CVE-2024-45774

Posted Apr 4, 2026 6:56 UTC (Sat) by gf2p8affineqb (subscriber, #124723) [Link] (2 responses)

Theoretically. But practically wouldn't there be so many bugs in e.g. abandoned FS drivers that root could exploit by mounting malicious filesystems images?

CVE-2024-45774

Posted Apr 4, 2026 8:36 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (1 responses)

The theoretical existence of other bugs doesn't justify failing to do something to reduce attack surface. If we're going to assume that unprivileged user to kernel is a given, why are we implementing any security fixes at all?

CVE-2024-45774

Posted Apr 5, 2026 5:02 UTC (Sun) by gf2p8affineqb (subscriber, #124723) [Link]

I don't think those are very theoretical, no? There was an article here some time ago about this.

CVE-2024-45774

Posted Apr 4, 2026 8:25 UTC (Sat) by dichloromethane (subscriber, #179270) [Link] (29 responses)

But it does give you access to insmod and modprobe. And with these, you can certainly do whatever you want in the kernel.

CVE-2024-45774

Posted Apr 4, 2026 8:38 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (28 responses)

Secure boot implies lockdown, which implies module signature enforcement. You can certainly insmod kernel modules that shipped with your kernel, but distros have also adopted policies of not building kernel modules that offer significant attack surface or have poor security track record and which are rarely used in the real world.

CVE-2024-45774

Posted Apr 4, 2026 15:24 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link] (27 responses)

I don't think that's actually true? Neither Ubuntu nor openSUSE have a particular policy about kernel modules or kernel module packages. Ubuntu ships a system that automates (as much as possible) the ability to self-sign any arbitrary modules, and openSUSE signs packaged modules with their key if they are in the distribution.

There is a general disconnect between the people who develop and advocate for secure boot and pretty much everyone else, including most distribution developers and users. I think the prevailing opinion is that secure boot isn't actually useful as a security technology and has mostly been a nuisance that we have to find ways to work around. Certainly the user experience on the desktop is significantly degraded on Linux compared to a system with secure boot disabled. Things like suspend-to-hibernate work, for example.

CVE-2024-45774

Posted Apr 4, 2026 15:25 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link]

Err, that is suspend-to-hibernate don't work when secure boot is enabled.

CVE-2024-45774

Posted Apr 4, 2026 15:37 UTC (Sat) by bluca (subscriber, #118303) [Link] (25 responses)

This is completely wrong. The enrollment for signing requires manual user action for enrollment with physical presence confirmation, and then there is a private key that is managed with passphrase.

This is very, very different from malware being able to silently load arbitrary kernel modules. I don't think you really understand how this works or what the threat models are here.

CVE-2024-45774

Posted Apr 4, 2026 15:44 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link] (24 responses)

I do in fact understand them. What I'm saying is that it doesn't matter in practice. The fact that both Fedora and Ubuntu have guided workflows for key enrollment and automatic setup for DKMS with those things is indicative of that. Once the key is enrolled, users can do whatever, and signing works freely for any module on the system. And a number of popular Linux distributions provide this workflow or advise to switch off secure boot too, further demonstrating that people are unsatisfied with the current state of affairs.

CVE-2024-45774

Posted Apr 4, 2026 15:50 UTC (Sat) by bluca (subscriber, #118303) [Link] (22 responses)

Yeah I don't think you do, given it's evident you haven't really grasped what the difference is between the authenticated owner of the machine with physical presence verification, and random malware. You really should read up on the threat model and the past/current attacks that are relevant to these security boundaries. "Popular Llinux distributions" can advise on whatever they want, if they don't care about exposing their users to well-known and exploited threats that's their entirely their business, but it doesn't magically change what the threat models are in the real world I'm afraid. It's just the head-in-the-sand approach.

CVE-2024-45774

Posted Apr 4, 2026 15:56 UTC (Sat) by ju3Ceemi (subscriber, #102464) [Link] (13 responses)

The owner will use its physical presence to put the key

The malware will use the key that has been installed by the owner

OP was not talking about threats models and attacks and whatever

OP was talking about the low quality of secure-boot

CVE-2024-45774

Posted Apr 4, 2026 16:01 UTC (Sat) by ju3Ceemi (subscriber, #102464) [Link] (12 responses)

By the way, I just check on my PC:
- secure boot enabled
- no custom key added in the bios
- random key was generated on install
- dkms is signing module with that key
- modules are loading

I am glad I am protected;

CVE-2024-45774

Posted Apr 4, 2026 16:44 UTC (Sat) by bluca (subscriber, #118303) [Link] (11 responses)

If no custom key was enrolled then yes, you are protected, that's how it works

CVE-2024-45774

Posted Apr 8, 2026 12:39 UTC (Wed) by Conan_Kudo (subscriber, #103240) [Link] (10 responses)

Read that comment carefully. I'm pretty sure they were being sarcastic, because it worked without enrolling the custom key in firmware.

CVE-2024-45774

Posted Apr 8, 2026 12:44 UTC (Wed) by bluca (subscriber, #118303) [Link] (9 responses)

No, that's not how any of this works

CVE-2024-45774

Posted Apr 8, 2026 12:52 UTC (Wed) by Conan_Kudo (subscriber, #103240) [Link] (5 responses)

It technically can if a distribution doesn't force lockdown with secure boot.

CVE-2024-45774

Posted Apr 8, 2026 13:51 UTC (Wed) by bluca (subscriber, #118303) [Link] (2 responses)

No, they can't, because that's a hard requirement to be allowed in the shim ecosystem in the first place. And not using shim means having to manually enroll custom keys in the firmware.

CVE-2024-45774

Posted Apr 8, 2026 14:07 UTC (Wed) by Conan_Kudo (subscriber, #103240) [Link] (1 responses)

I'm not entirely sure that has always been true. For example, openSUSE did not have forced lockdown enabled until July 2023. Also, the enforced lockdown for secure boot patches are not upstream because Linus disagrees with the premise of the feature. So LOCK_DOWN_IN_EFI_SECURE_BOOT does not exist for mainline kernels without patches.

CVE-2024-45774

Posted Apr 8, 2026 14:10 UTC (Wed) by bluca (subscriber, #118303) [Link]

> I'm not entirely sure that has always been true.

It has, some did slip through, but were later corrected

> So LOCK_DOWN_IN_EFI_SECURE_BOOT does not exist for mainline kernels without patches.

Yes, but that doesn't change the requirement one bit:

https://github.com/rhboot/shim-review?tab=readme-ov-file#...

CVE-2024-45774

Posted Apr 8, 2026 13:53 UTC (Wed) by amacater (subscriber, #790) [Link] (1 responses)

Distributions *don't* generally force lockdown with secure boot - but it's generally not a bad idea to enable it. Anti secure boot folks - that ship has largely sailed. Similarly with removing 486 support and, eventually, BIOS support. [BIOS support as legacy boot was available until 2020 but the option for UEFI only on Intel/AMD machines was there since 2012 or so - and late model laptops don't *have* the option for legacy boot. (Hence scrambling for particular laptops to test Debian install media, for example :) )

CVE-2024-45774

Posted Apr 8, 2026 14:03 UTC (Wed) by bluca (subscriber, #118303) [Link]

> Distributions *don't* generally force lockdown with secure boot

We do if shim is involved for booting by default on consumer hardware. It's a hard requirement to be allowed to join in.

CVE-2024-45774

Posted Apr 8, 2026 15:19 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (2 responses)

It is how it work on my PC, and it does boot, and the module does load, and there are no extra key on bios or whatever (I rechecked)

Seems like reality and you are not on the same side, which is probably the core issue here

CVE-2024-45774

Posted Apr 8, 2026 15:27 UTC (Wed) by bluca (subscriber, #118303) [Link] (1 responses)

Not really, it's simply that you don't know how any of this works - which is fine, nobody knows everything

CVE-2024-45774

Posted Apr 8, 2026 15:36 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link]

Or could it be that a stupidly high number of motherboard manufacturers do not verify the signature at all and "trust" whatever is given to them (by default or hardcoded) ?

Could it be ?

I do not seems to be alone in the dark here :)

CVE-2024-45774

Posted Apr 4, 2026 15:59 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link] (6 responses)

I suspect you're a little out of touch here. I personally understand the benefits of secure boot and my systems run with it. I don't have a self-signed certificate imported into my systems because I don't have a reason to do it. But, I understand that Linux secure boot is incomplete and the loss of functionality that comes with it is crippling to the user experience relative to Windows and macOS.

Taking functionality away and hiding it behind a mechanism that users cannot easily choose effectively makes the default experience on Linux worse, and that puts all the rest of us in a bind. When we can't even have good power management and battery life because of secure boot lockdown, there's not much room for people to be happy about the security. And now these conversations about dropping features from GRUB just make people more upset about the feature because it makes the system less powerful and flexible for the system owner.

CVE-2024-45774

Posted Apr 4, 2026 16:43 UTC (Sat) by bluca (subscriber, #118303) [Link]

The "loss of functionality" is basically difficulties with handling out-of-tree kernel modules, which in 99.99% of the cases just means the proprietary ones from Nvidia. That's the hardware manufactorer's fault right there - they should just open source their drivers and get them merged upstream. Plenty of hardware vendors manage to do that just fine, so it's high time to stop making excuses for them.

Removing pointless cruft from the default grub build on Ubuntu is a great idea, and one that should have been done many CVEs ago, but of course better late than never. People who don't care or are unaware of all the threats that are out there can do their own builds if they don't like it. There are way too many attacks out in the wild for the sensible OS vendors to just ignore, and at some point it's just irresponsible to pretend they don't exist.

CVE-2024-45774

Posted Apr 4, 2026 19:27 UTC (Sat) by valderman (subscriber, #56479) [Link] (4 responses)

> When we can't even have good power management and battery life because of secure boot lockdown

Uh, what? Lockdown doesn't affect power management.

Even the "no hibernate with secure boot" problem is solved in theory by the kernel detecting that swap is on an encrypted partition, though it works poorly in practice since the kernel seems unable to recognize when swap is on encrypted LVM.

CVE-2024-45774

Posted Apr 4, 2026 21:07 UTC (Sat) by GhePeU (subscriber, #56133) [Link] (2 responses)

"Solved in theory but in practice it doesn't work in a very (if not the most) common use case" means that the problem is *not* solved and preventing hibernation from working means that lockdown *does* affect power management.

CVE-2024-45774

Posted Apr 5, 2026 15:07 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

Hibernation is restricted for good reason, and Linux would do its users an actual disservice by not making extra sure, it gets it right, when determining if swap is sufficiently secure. And that's very hard, given that there are so many ways of doing that. I, for instance have "unencrypted" swap on logical LVM2 volumes that are, in fact, LUKS2 encrypted. But it looks like plain swap to the kernel from that angle. I believe the kernel would let me hibernate if I were to setup cryptswap, but I haven't tested that theory, because I don't want to reinstall and cryptswap inside an already encrypted physical volume would just tank any performance left.

Security and comfort are often conflicting goals, and I don't miss hibernation; suspend to RAM (S3) is fine. The irony of the myriad of ways to do stuff like disk encryption in Linux is, that it's an actual hinderance in having your cake and eat it too, when it comes to Secure Boot with all the bells and whistles; so I'll settle for just the bells, for the time being.

CVE-2024-45774

Posted Apr 5, 2026 15:20 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

I, for instance have "unencrypted" swap on logical LVM2 volumes that are, in fact, LUKS2 encrypted.

That was meant to say: they are located on physical volumes that are, in fact, LUKS2 encrypted:

NAME                  PARTLABEL              LABEL FSTYPE
sda                                                
└─sda1                                             crypto_LUKS
  └─sata_crypt                                     LVM2_member
    ├─vgsata-data                                  btrfs
    └─vgsata-swap_1                                swap
nvme0n1                                            
├─nvme0n1p1           EFI System Partition         vfat
├─nvme0n1p2           Linux Boot Partition         ext4
└─nvme0n1p3           Linux System Partition       crypto_LUKS
  └─nvme0n1p3_crypt                                LVM2_member
    ├─vgubuntu-root                          Root  btrfs
    └─vgubuntu-swap_1                              swap

I am not quite sure if that was the Ubuntu installer alone or if I tweaked it. But I sure as hell wouldn't want to have statically sized (crypt)swap partitions alongside an LVM2 PV.

CVE-2024-45774

Posted Apr 4, 2026 22:21 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> Uh, what? Lockdown doesn't affect power management.

Except when you rely on userspace tools with direct access to hardware registers to do said power management because no other component in the stack (not vendor's shitty firmware, nor vendor's shitty/nonexistent Linux drivers) can be arsed to do it properly and/or in a non-user-hostile manner.

CVE-2024-45774

Posted Apr 5, 2026 13:44 UTC (Sun) by marcH (subscriber, #57642) [Link]

> "Popular Llinux distributions" can advise on whatever they want, if they don't care about exposing their users to well-known and exploited threats that's their entirely their business, but it doesn't magically change what the threat models are in the real world I'm afraid. It's just the head-in-the-sand approach.

Having great security that popular distributions don't use or use incorrectly is "head-in-the-sand". Designing and implementing security features is hard but that's not even the end of the story, it also has to crack the "security friction" nut and be sold in practice to reluctant users, otherwise it's just pointless theory = the extremely common issue with security. A feature/lockdown does not have to be adopted by a majority of users, especially not initially, but as long as it's "niche" then it has not been successful yet. What seems required here is some stats. Some distros already collect lists of packages installed, it would be great to add secure boot configuration to those stats? Opt-in of course.

> The "loss of functionality" is basically difficulties with handling out-of-tree kernel modules, which in 99.99% of the cases just means the proprietary ones from Nvidia. That's the hardware manufactorer's fault right there - they should just open source their drivers and get them merged upstream. Plenty of hardware vendors manage to do that just fine, so it's high time to stop making excuses for them.

This statement needs some evidence to back it up. If this is indeed the main reason by far in practice then yes: "Please thank Nvidia/similar for being insecure" is a great punchline and should be louder and clearer.

CVE-2024-45774

Posted Apr 5, 2026 14:32 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

I guess that's entirely on the user. In fact, I did decide to forego on some additional TLP module, because that tainted the kernel which, I think, also caused lockdown to be disabled, IIRC. Once DKMS was purged, the signing key was gone, I believe; or maybe I wiped it - it was some five years ago.

Long story short, if you value Secure Boot, don't install DKMS. Maybe, users should be educated on this better, but then again, GNU/Linux distros have always been by and for the more tech savvy. And there was some more or less involved procedure when DKMS was installed, so nobody say they weren't warned. Most of the time security and comfort are conflicting goals, as can be seen in Klode's proposal thread.

CVE-2024-45774

Posted Apr 4, 2026 23:33 UTC (Sat) by dmoulding (subscriber, #95171) [Link] (1 responses)

Can't an attacker with physical access simply replace grub with a tampered version of grub that has any backdoor inserted into it that the attacker wishes?

For all practical purposes, this is only a vulnerability in cases where the system is already completely vulnerable to compromise in myriad other ways.

CVE-2024-45774

Posted Apr 5, 2026 0:18 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

No, because it won't have a valid signature

Security by presence of vulnerabilities

Posted Apr 4, 2026 9:47 UTC (Sat) by dottedmag (subscriber, #18590) [Link] (10 responses)

"Prove it does/will have security holes" is such a bad take.

Security by presence of vulnerabilities

Posted Apr 4, 2026 12:00 UTC (Sat) by muase (subscriber, #178466) [Link] (9 responses)

It depends a bit I think – if you do "X for security" I think it's reasonable to ask how X will improve real-world security. In the end, the removal of features people seem to actively use should be justified with more than an abstract "for security". No conventional software is perfect, so it's always a trade-off between features, usability and security.

That being said, GRUB's security track record is pretty unsatisfying when we consider that it is such an integral component in the boot-chain, and given the fact that at its core it is a single-purpose application with an extremely limited scope. This is not meant as a criticism against the devs or maintainers; but a simple fact analysis: Apparently, GRUB's code base is too complex at the moment – so reducing complexity by removing unneeded code makes sense; especially if past CVEs prove that unneeded components and their complexity were a problem before.

Of course removing stuff is not the only way forward; security audits can help, Rust can certainly help a lot, and so on – but those are significantly more expensive (in time and/or money), and probably not a realistic option for near future. And ultimately, when it comes to security, complexity kills the cat, so KISS is paramount – and always pays out, no matter the language.

Security by presence of vulnerabilities

Posted Apr 4, 2026 14:24 UTC (Sat) by cesarb (subscriber, #6266) [Link] (8 responses)

> That being said, GRUB's security track record is pretty unsatisfying when we consider that it is such an integral component in the boot-chain

The root cause is that these bugs only became "security bugs" because of Secure Boot. Before that, they were normal boring bugs; for instance, who cares that a damaged image can crash the bootloader, when anyone who can put that damaged image in place can instead directly edit the bootloader itself? The bootloader was not a security sensitive part of the system, until Microsoft decided that it had to be (as a way to prevent boot viruses from executing any code before their operating system could load the antivirus drivers).

Security by presence of vulnerabilities

Posted Apr 4, 2026 15:10 UTC (Sat) by ballombe (subscriber, #9523) [Link] (7 responses)

A lot of users use Secure boot because it is the default, not because they expect any extra security. They are better served with an unsecured signed grub binary than by a binary that is missing features they need.

Security by presence of vulnerabilities

Posted Apr 4, 2026 16:05 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link]

I don't think Secure Boot is generally viewed as a security technology by distribution developers, but instead a necessary compatibility/interoperability technology. Without being trusted by the Microsoft UEFI CA, it is significantly harder for someone to install a Linux system on a PC. I know it's viewed as a security technology by the folks who developed the Linux implementation, but I suspect the incomplete nature of the implementation has not really allowed that perception to become dominant.

Security by presence of vulnerabilities

Posted Apr 4, 2026 19:14 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (4 responses)

The existence of an insecure signed grub means that those who *do* depend on the security guarantees of secure boot are fucked. The easy thing to do is provide both signed and unsigned builds and ensure that the process for disabling secure boot enforcement via mokutil is clearly documented.

Security by presence of vulnerabilities

Posted Apr 4, 2026 22:25 UTC (Sat) by ballombe (subscriber, #9523) [Link] (3 responses)

But such unsecured signed grub already exist.

Security by presence of vulnerabilities

Posted Apr 5, 2026 0:17 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (2 responses)

And the outcome of any vulnerabilities being flagged in them is that there'll probably be an SBAT-based revocation event

Security by presence of vulnerabilities

Posted Apr 5, 2026 16:44 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

And Ubuntu has successfully handled such a case in the past. I know, because I saw it happening on my device and nothing exploded.

Security by presence of vulnerabilities

Posted Apr 5, 2026 16:49 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

BTW, that's a prime example of a USN that would not have been required had image support been removed from GRUB for the secure boot compatible packages, i.e. grub-*-signed. It was quite involved, IIRC, to make sure nobody would end up with an unbootable system.

Security by presence of vulnerabilities

Posted Apr 5, 2026 16:57 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

No, they are not. GRUB has a terrible track record, when it comes to security, but it wasn't, and still isn't, considered a security boundary without secure boot, because then the old adage, that an attacker with physical access means game over, applies.

measure only what is used ?

Posted Apr 4, 2026 22:39 UTC (Sat) by champtar (subscriber, #128673) [Link]

Could GRUB only add to the TPM measurements what it actually uses ? No splash image in the config, the image parsers are not measured, if I use btrfs, the code for LVM2 / FAT / EXT4 is not measured ...
This would allow to keep most features available and lockdown on first use to only the features used by each system.

Ubuntu could solve this by providing 3 versions of GRUB (And they kind of already do)

Posted Apr 5, 2026 4:35 UTC (Sun) by NUXI (subscriber, #70138) [Link] (2 responses)

> Ubuntu provides two versions of GRUB: one for UEFI systems that enables Secure Boot (referred to as the "signed" builds), and another for systems with legacy BIOS or systems that otherwise don't support Secure Boot (the "unsigned" builds).

This isn't quite correct, what Ubuntu provides are:

1. grub-pc - An unsigned version of GRUBS for legacy BIOS systems

2. grub-efi-amd64-signed - A signed version of GRUB for UEFI systems (this is used on all UEFI systems even if secure boot is disabled)

There is also a third version (grub-efi-amd64) which provides an unsigned UEFI bootloader, but it is ignored as long as grub-efi-amd64-signed is installed. Since grub-efi-amd64-signed is a required package that means it can't be removed without passing "--allow-remove-essential" to apt. I can only assume that this means the configuration isn't actually supported. (For anyone wanting to nitpick, technically shim-signed is the required package and that depends on grub-efi-amd64-signed.)

I think that if Ubuntu wants to go down this route they need support using an unsigned version of GRUB on UEFI systems. IMHO the biggest issue with a change like this is blocking upgrades unless the affected users repartition their machines. So this would allow them to harden secure boot while giving users with the affected machines an option that is better then just reinstalling or not upgrading.

Ubuntu could solve this by providing 3 versions of GRUB (And they kind of already do)

Posted Apr 5, 2026 18:05 UTC (Sun) by PeeWee (subscriber, #175777) [Link] (1 responses)

Since grub-efi-amd64-signed is a required package

That's incorrect. grub-efi-amd64-signed is of priority "optional". Also, grub-efi-amd64 is just a dependency package that pulls in grub-efi-amd64-bin, which in turn recommends grub-efi-amd64-signed. grub-efi-amd64-signed also depends on grub-efi-amd64-bin. They never were mutually exclusive.

This is not like in the BIOS days when only one boot loader could occupy the MBR. In fact, UEFI with the requirement of the ESP simplifies a lot of things. People should watch that talk of Lewandoska's; nmbl FTW!

Ubuntu could solve this by providing 3 versions of GRUB (And they kind of already do)

Posted Apr 5, 2026 20:26 UTC (Sun) by NUXI (subscriber, #70138) [Link]

> That's incorrect. grub-efi-amd64-signed is of priority "optional".

As I already noted, grub-efi-amd64-signed is depended upon by shim-signed which is "Protected: yes". So regardless of what the priority flag says, you cannot remove it without specifing the "--allow-remove-essential" flag of apt-get.

> Also, grub-efi-amd64 is just a dependency package that pulls in grub-efi-amd64-bin

While grub-efi-amd64 appears to be empty dependency packages, it actually is not. Amongst other things it owns the debconf templates, /etc/default/grub, and it is grub-efi-amd64.postinst that installs grub to the disk when the packages are installed. Same goes for grub-pc, which is why those are the two packages that conflict rather than the -bin versions.

I didn't think it was worth complicating my post by diving into that mess.

> This is not like in the BIOS days when only one boot loader could occupy the MBR.

This is technically correct but ignores the reality of what the scripting within the Ubuntu packages actually does. Because this isn't about whether or not something is technically possible, this is about whether or not Ubuntu supports doing it.

Spacebar Heater Mode

Posted Apr 5, 2026 11:45 UTC (Sun) by k3ninho (subscriber, #50375) [Link]

I'll miss Spacebar Heater Mode, but I'm up for bikeshedding a replacement.

K3n.

Frustrating in both directions.

Posted Apr 6, 2026 9:07 UTC (Mon) by Heretic_Blacksheep (subscriber, #169992) [Link]

First of all, Klode has a tendency to be "my way or the highway" and that's a problem when it comes to software other people use that he didn't write merely packages it. Second, Grub's multiple filesystem support is not an optional feature, it's required to be able to (multi)boot from multiple otherwise *valid* natively supported kernel configurations.(1) Removing core functionality from someone else's project without well reasoned justification is a bad thing. It inevitably leads to people blaming volunteers upstream for the actions of (in this case paid) downstream packagers and hostility all around. Reducing maintenance burden is a security theater trope in paid software services. It's more about profit margins than security. Maintenance burden is a labor problem, not necessarily a security problem. There is some overlap, especially when you get to the size of a code base like Windows NT, but they shouldn't be conflated like many handwaving appeals I've seen have been on much smaller, trivial in comparison, software packages. Context and nuance matters. When a volunteer, non-profit, or otherwise small, free project wants to reduce functionality, even core functionality, well that's a their choice (like OpenBSD, libxml2, etc.). It's fully understandable with limited resources. When a profitable corporation's paid employee is handwaving at security issues in an otherwise small volunteer FOSS project, and making noises about maintenance burden not offering to help work out a mutually beneficial solution, that's laziness. Especially when said corporation made enough net profit last year to hire another developer to help manage core functionality. Not sorry.

That said, people that get Ubuntu for free are *not* Canonical's customers (like me through Linux Mint, my personal choice of distro). Customers are people that establish a contract for services. Their customers are those that pay consideration for support contracts. They have the lion's share of influence. The rest of us only have a say in Ubuntu's development in as far as Canonical's management tolerates the ranting. ;) Still, if I were a Canonical customer with financial influence, I'd be pointing the above out.(2)

(1) I didn't say Grub itself is required, only that for the problem Grub intends to solve those features are highly desirable or even necessary regardless of the project used.

(2)have done so to another vendor at $WORK in a similar situation... but with the backing of a fifty million dollar IT budget behind me. Unfortunately for us peon individuals, money talks very very loudly. Pay someone's bills and suddenly "that configuration is unsupported" gets oddly muted. And as an aside, one reason why paying hobbyists for their project labor will only work for those that are willing to effectively become a paid employee, and not a broadly applicable solution.

Full Disk Encryption

Posted Apr 6, 2026 9:27 UTC (Mon) by Wol (subscriber, #4433) [Link] (5 responses)

> Users were also concerned about not having LUKS encryption for the /boot partition, and the impact on full-disk encryption (FDE). There was a fair bit of discussion and disagreement about the need for /boot encryption. Klode's position is that encrypting the partition did little to enhance security; that stance found a number of supporters. Peter White argued that it was more important to validate everything used in the boot process against cryptographic signatures.

To me, this misses the point that FDE protects against much more than bypassing secure boot or whatever. What's the point of secure boot, if an attacker can just nick the system, remove the disk, and read it in another machine!

If grub, in the name of security, breaks FDE it's simply creating a different major (and real) headache to replace a theoretical (or laziness) headache.

Cheers,
Wol

Full Disk Encryption

Posted Apr 6, 2026 19:26 UTC (Mon) by muase (subscriber, #178466) [Link] (4 responses)

> To me, this misses the point that FDE protects against much more than bypassing secure boot or whatever. What's the point of secure boot, if an attacker can just nick the system, remove the disk, and read it in another machine!

But an attacker can just read the boot-partition which does not and should never contain sensitive data? I think there might be some confusion there: The root-partition and user partitions are still encrypted as usual; the boot-partition only serves as a trampoline to open the root-partition, and handover to there.

This setup is quite common, and has very reasonable security assumptions; there are very few systems that fully encrypt the boot partition and handover everything to the bootloader; usually because there are no security gains. Therefore I'm curious: What kind of real-world attacks are possible if the boot-partition as trampoline is readable?

Full Disk Encryption

Posted Apr 6, 2026 19:38 UTC (Mon) by mb (subscriber, #50428) [Link] (1 responses)

>What kind of real-world attacks are possible if the boot-partition as trampoline is readable?

The problem is if it is writable.

An attacker can modify it to get full arbitrary root/kernel access, while the owner is at the hotel bar.
FS content is much easier to write to than doing a TPM or UEFI modification.

Full Disk Encryption

Posted Apr 7, 2026 10:20 UTC (Tue) by muase (subscriber, #178466) [Link]

But that is an authentication problem, not a secrecy-related one. In the secure boot chain, every link in the chain is responsible to verify the next segment(s). Here, this means grub is responsible to verify the kernel signature and everything on the boot-partition that matters.

AFAIK on Ubuntu, Grub validates the kernel signature; but if it doesn’t (or that’s not sufficient due to initrd or similar), that’s a vulnerability that should be fixed. I agree that FDE can be annoying for specific attacks; but overall it is the wrong tool here, because if Grub doesn’t verify its next step, ultimately you can always trivially inject another malicious EFI-executable or boot-partition as intermediate next step before your real boot-partition gets unsealed.

Full Disk Encryption

Posted Apr 7, 2026 9:07 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

The point is that FDE is far simpler than encrypting (almost) every partition.

If you encrypt sda with the keys protected by TPM or whatever, it's a lot cheaper/easier/trickier-to-get-wrong than encrypting sda2/sda3/...

That said, I think I've just realised there's a "chicken and egg" problem here in my logic ... (but in that case why is FDE allegedly so good?). The point of FDE, as I understood it, was that removing the disk from the computer (without at the same time extracting the keys from the TPM) was a quick and simple way of making the data on that disk non-recoverable.

Cheers,
Wol

Full Disk Encryption

Posted Apr 7, 2026 10:42 UTC (Tue) by muase (subscriber, #178466) [Link]

I think we might have a confusion of terminology here. FDE usually refers to “block-level encryption” as opposed to e.g. file-system-level encryption. So the full logical disk (e.g. a partition) is encrypted; that does not mean the entire physical disk is.

In most setups, the boot-partition is treated similarly to the EFI-partition as part of the boot-chain, and not as userdata; because it’s a bit of a chicken-vs-egg problem: Someone needs to bootstrap the password/PIN entry and decryption logic. Unless you move that into the UEFI-firmware (and I don’t know of any firmware that supports LUKS), you need some plaintext executables on the disk anyways.

So in practice, even if you select a single partition layout in the installer, you usually get separate EFI- and boot-partitions (especially with LVM or encryption turned on).

However, this is generally not a security problem, because in common FDE-setups your assumption still stands: accessing the disk without having the keys (passphrase, TPM, etc.) will render all userdata unreadable. The important point is just that the boot-partition is not considered userdata, similar to how the EFI-partition or even the UEFI-firmware itself is not considered userdata.

systemd-boot

Posted Apr 7, 2026 16:00 UTC (Tue) by eean (subscriber, #50420) [Link] (2 responses)

It does seem like support has to be dropped for BIOS at some point and the question is when. I guess the problem is that systems until ~2020 could boot up in a legacy BIOS mode and asking users to mess with that is a big lift.

It's one of those technical decisions that does make more sense once you think about the trade-offs and alternatives. Sure, make a build of Grub that is stripped down to the functionality of systemd-boot. Makes sense actually.

systemd-boot

Posted Apr 8, 2026 13:56 UTC (Wed) by hmh (subscriber, #3838) [Link]

If you have dropped x86-64-v2 support then it might make sense to drop BIOS as well.

Otherwise, please don't. Some x86-64-v2 dual-mode boxes are better off in BIOS mode, and a lot of x86-64-v2 boxes are BIOS-only. These are not junk systems at all, and likely to still be around in large numbers until the 2032 (likely 2036). They can easily have enough RAM, CPU and GPU power to run well the current stack of applications, as long as they are not compiled to require x86-64-v3 or later (i.e. AVX, etc)...

systemd-boot

Posted Apr 10, 2026 9:32 UTC (Fri) by juliank (guest, #45896) [Link]

That statement only makes sense from a UEFI-focused standpoint, but if you extend past that to things like OpenFirmware on Power and bare metal firmware then BIOS isn't all that different and reasonably supportable.