Streamlining secure boot for 26.10

Project Discussion Foundations
21

This security risk is called steganography. It has been known about for decades. I remember an article many years ago on how it was possible for criminals to hide messages within the digital code of an image. To quote another source:

In computing and electronic contexts, a computer file, message, image, or video is concealed within another file, message, image, or video.

Wikipedia article on Steganography

So, putting an image file in the /boot/grub/ folder could be a security risk. It is true.

For years I have been downloading from the archives Grub2 splash-images into /usr/share/image/grub and then copying an image file into /boot/grub so that it appears as a background image for the Grub boot menu. It is easy to do.

I do not think that I am putting the security of my machine at risk. But I will not deny the truth of what has been said about the risk that is there. That would be stupid. I will also accept that making it possible for users to put image files from who knows where into the boot folder would present a security risk especially to commercial enterprises.

A commercial enterprise many have a company policy about this matter. But company policies are often broken. Even by top level management.

If in future I am no longer able to have a background image to the Grub boot loader, then that is what must be. I will survive.

Regards

1 Like
22

First off, I’m going to assume that any decision for 26.10 would apply to the future 28.04 LTS build.

Affected systems will by default stay on 26.04 LTS, that is, the upgrade will be disabled in ubuntu-release-upgrader.

I think this is the biggest problem with the decision. That means if you have an affected configuration, your only options are:

  1. Backup, reinstall (or manually repartition/reformat), and restore your data.
  2. Disable secure boot and use the unsigned bootloader packages.
  3. Don’t upgrade

I think that those represent pretty extreme choices.

I already have secure boot disabled, so option #2 would be fine with me except… that option would have to be available prior to upgrade for it to work. Maybe its allowed in Resolute but I don’t see any way to do it in Noble. In fact apt refuses to even consider removing shim-signed or grub-efi-amd64-signed.

5 Likes
23

This is simply absurd…. I would rather give up on GRUB than on LUKS or any FS/disk encryption (which is today simply required standard). In sense of “security”… like unencrypted disk is secure?

There is simply too many features you want to throw away for this. Snapshots also adds to security. So removing it to improve security is, like improving security of planes by forbidding them to fly, and instead use other mean of transport which is less safe. Simply said, what is point of so secure boot, when everything above (whole system) is as insecure as possible due to missing most important security features like encryption, RAID, snapshots, etc.

If it’ such big issue and you need to support ancient VPS environments, just make installer to choose the opion, like:

”encrypt the disk (requires UEFI, will install systemd-boot if enabled)” yes/no

Simple as. You can still allow GRUB installation for cases when you don’t want to encrypt the disk or need to run it on VPS environment. Just give option in installer. You can’t say it’s too hard to support both options, and just allow to choose GRUB vs systemd-boot during installation, when you can literally support tens of File-systems and options in installer that has much more effect on stability of OS. You are Canonical, The company with enough people and capacity for this small thing. And if you need more, I would gladly help.

If you remove encryption, bye bye Ubuntu.

6 Likes
25

While I can understand the idea of reducing the surface to maintain, secure boot would not be so secure without full disk encryption, as the initrd that lies in /boot can’t be protected from tampering except with a TPM (+UKI or custom verification method).

Therefore I’d suggest you to reconsider LUKS dropping as otherwise your chain of trust will be broken.

3 Likes
27

FYI this is going to break/upgrade-block everyone’s install who has followed the official OpenZFS install guides to run ZFS on Ubuntu as those call for zfs on boot partition. I imagine the situation is similar for all these other filesystems.

More broadly speaking, I think it’s a really shortsighted plan to put users in the situation where they have to do a full OS re-install – especially when that’s because choice is being taken away from users. A full OS re-install is a critical juncture point where users are going to re-evaluate which distro they want to run, and given some of the unpopular decisions recently, I think it would result in user attrition towards other distros (personally, I’m very interested in trying a snap/systemd-less distro for my next install)

To echo the prior comment, these removals don’t seem to be based on actual direct security implications so much as potential security hardening via reducing code surface. Which is a valid goal, but seems more suited to being an opt-in versus forced on everyone.

Could I suggest you accomplish this project instead by maintaining a parallel fork (ex: ‘grub-minimal’ ?) That way you can strip out as much as possible for a lightweight grub to accomplish your goal, without affecting other users.

3 Likes
28

Staff note to ALL users.

We have engaged Slow Mode for this topic.

While we understand certain changes may evoke certain responses, we require everyone to respect our community guidelines, including the Code of Conduct by which you are bound when signing up here.

To be perfectly clear: well-thought out and reasoned responses with technical perspectives are more than welcome.

Knee-jerk “this is the worst thing ever, I am leaving Ubuntu” reactions will be deleted…and the user may face possible censure by other means.

Don’t forget that at the end of the day you are responding to a Canonical employee who has put in years of hard work to make this free, open-source project better for everyone.

Be respectful!

2 Likes
29

@juliank I think this needs further discussion and a deeper explanation of how this is going to improve security for each dropped item being made in a public explanation of why each bit being dropped is beneficial.

Consider 26.04 currently, and 24.04 LTS or 25.10 flavors. All of the default Ubuntu installers for these have LVM as options. Have experimental XFS as a selectable option. Use LUKS+LVM for encryption.

Ubuntu Server’s default installers ALSO use LVM, and you don’t have a choice to remove this. You’re essentially saying “Hey, these defaults we’ve set? Worthless!” with this decision.

In fact, you’re hobbling existing installs and policy-mandating environments that require the use of encryption with LUKS (which currently can ONLY be done with LVM) and other setups.

I also don’t see the reason to drop filesystem support from GRUB signed. It doesn’t actually reinforce security, it actually brings a detriment to security because you can’t use Secure Boot if you also use one of these other things in an environment.

Especially given that all these are supported in 26.04’s roadmap currently, you’re effectively going to force everyone to old-school installation on physical partitions where, with VMs, etc. and other needs, LVM is actually USEFUL to facilitate easy expansion and management of disks and expansion of volume arrays across disks (without the need of full mdadm and software RAID with reinstalls of systems).

As a security professional myself, and someone who actively uses RAID-5’d systems to actually make sure my data doesn’t get lost and I can have more than one disk of failover in RAID systems, 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 featuresets on the basis that “it makes GRUB Signed more bare and thus more secure because there’s less open holes for risks”.

Additionally, with my community hat on, by doing this you’re going to be alienating the MAJORITY of users by suddenly forcing them to use what could be considered “legacy” approaches to disk management and forcing organizations with specific requirements for these other filesystems and setups to “not use secure boot” where their security policies are otherwise requiring Secure Boot to be enabled for compliance. (You’re effectively hobbling the entire infrastructure of Ubuntu by doing this)

15 Likes
30

The security risks involved with images have little to do with steganography, which is about hiding information “in plain sight”, at least in the context of (potential) GRUB vulnerabilities. For those you don’t even need a valid image. In fact, you need an invalid one that makes a vulnerable decoder exploitable while a perfect decoder would just reject it.

Steganography, OTOH, does require a perfectly valid image to avoid suspicion; it’s mostly about slightly adjusting color values of some pixels to encode the obfuscated payload. Nobody will notice that the actual correct value was 0xFC, when it’s 0xFF (for two stealthy bits); do that with enough pixels and you can stitch together bytes of information and Bob’s your Uncle. No attacker gains anything by having GRUB2 load such an image.

31

If we care that much of security we should probably better go for a signed, Rust rewrite of the GRUB bootloader(shrugs).

/s

3 Likes
32

Reading through this thread and others, it looks to me as though the developers have totally lost sight of the prime purpose of Linux - to bring an open and easy alternative to the market dominated by Apple and Microsoft.

By continually adding layer upon layer of additional security measures, the effect is to alienate not just long-term Linux users but refugees from other ecosystems who want to try Linux for the first time.

We should be making things easier with more choices, not adding layers of difficulty and certainly not in the most sensitive area of all - the boot process. Linux is already the most secure of all operating systems, this eternal obsession with added layers and ever more layers of security “features” such as snaps, flatpack, etc., will only end up alienating ever more possible converts to Linux. It seems to me that Ubuntu has lost it’s way in the last few years, if the developers continue on this course then the user base will inevitably shrink and many more will continue to abandon it in favour of more user-friendly alternatives such as Mint, Arch etc.

I hope this post is not too far off-topic but this attempt at “streamlining” secure boot for 26.10 is doomed to eroding Ubuntu’s user base ever further.

1 Like
33

Could you cite these security issues, please? This would be a major change, so I’d like to understand the specifics of the motivation behind it. For example, I’d like to understand the specific security issues we’d have avoided in the past had this changed happened earlier, give that these security issues of the past are the sole motivation for this change.

5 Likes
34

I think, you misunderstand the implications. This is about how GRUB gets access to the kernel image. For that it needs some filesystem support to access /boot. Since Secure Boot has a hard requirement for an additional vFAT partition anyway, by being part of UEFI, I don’t see how requiring a somewhat traditional separate /boot would add any meaningful inconvenience.

Heck, I’ll go as far as saying that even ext4 is too complex for the purposes of /boot; ext2 will do just fine. Journaling (ext3+) is rather pointless when it comes to /boot. And I don’t see any other requirements calling for ext4.

And, while I’m at it, why not use said vFAT partition and drop all the other filesystems? We cannot get rid of the EFI partition, so let’s embrace it and get rid of code complexity in the process? I mean, it doesn’t get any simpler than vFAT, I guess, which is probably the reason for it being required for UEFI boot; EFI vendors are cheap skates that way. The only thing that probably needs some attention at installation time is the size of the EFI partition. Or just use vFAT for /boot as well. I know that dpkg refuses to install to non-native filesystems, that don’t support all the bells and whistles, but I don’t see that as too hard to change or work around; e.g. just have the install action target some tmpfs, to placate dpkg and then some postinst action moves the relevant files to the vFAT partition.

Also, initrd images should be validated unconditionally, which is still not the case, IIUC. I find that rather puzzling as it leaves a glaring whole in the chain of trust, especially with full disk encryption, since a malicious initrd could just grab the passphrase and run with it. Yes, there is some protection against such tampering, but it requires hardware support for detection, e.g. (some) Thinkpads have bottom cover removal triggers, which can at least make such a change not go unnoticed. But what about other devices that lack that kind of integration?

That’s somewhat oxymoronic. More choices make things harder, actually. It used to be that pretty much any more advanced setup required a separate /boot. Then GRUB2 came along, got smarter and people got used to that, nothing more. It could be dead simple to install and run Linux, if the canononical way - see what I did there? :wink: - of installing just became: /boot on dedicated partition, period; no options, only ext2 or maybe even vFAT (see above). Or just reuse the already present, and mandatory, EFI partition, possibly resizing it in the installer. That’s much simpler, as in less code and also less user-facing complexity of having to make the right choice. I think the so-called refugees will be thankful for that alone; not having to read this, that and the other How-To. With Secure Boot, which this topic is about, there is no way around partitioning, so what’s one more, when it’s well-defined, or one “merged” vFAT EFI/boot partition?

1 Like
36

The Ubuntu CVE tracker is a pretty good source, here are some explicit ones that would have been avoided by not shipping drivers that Ubuntu doesn’t actually use:

https://ubuntu.com/security/CVE-2025-1125
https://ubuntu.com/security/CVE-2025-0689
https://ubuntu.com/security/CVE-2025-0686
https://ubuntu.com/security/CVE-2025-0685
https://ubuntu.com/security/CVE-2025-0684
https://ubuntu.com/security/CVE-2025-0677
https://ubuntu.com/security/CVE-2024-45783
https://ubuntu.com/security/CVE-2024-45782
https://ubuntu.com/security/CVE-2024-45781

https://ubuntu.com/security/CVE-2024-45779

Here’s one for the jpeg parser:

https://ubuntu.com/security/CVE-2024-45774

If you go through the list at CVE search results | Ubuntu 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.

5 Likes
37

To avoid doubt, we are not removing any kind of FDE support from Ubuntu whatsoever.

How FDE works today in Ubuntu is that /boot contains a kernel and initrd, and the encrypted / filesystem is unlocked by cryptsetup executed from the initrd.

There is no GRUB involvement there, we advocate for and will keep supporting full disk encryption.

This is only about cutting out unsupported FDE code from GRUB.

4 Likes
38

I think this clarification would have curbed a lot of negativity from the start. Thanks for posting it as this is not immediately apparent to many who are not necessarily experts in the boot loader realm. (Myself being one of those people).

3 Likes
41

This is only for /boot.

And from the Arch wiki, Grub doesn’t respect the default btrfs subvolume settings leading to easy breakage and requiring to modify kernel parameters in grub.cfg.

Cf https://wiki.archlinux.org/title/Btrfs

GRUB’s grub-mkconfig script does not respect Btrfs default subvolume settings. If / is the top-level subvolume, it will never specify subvol=/ or subvolid=5 mount options, which may cause boot failure. If / is not the top-level subvolume, it will always specify the corresponding subvol option, making it impossible to fall back by simply setting the default subvolume (bug report). Currently this can be resolved by manually modifying the rootflags kernel parameter in grub.cfg (see #Mounting subvolumes), or by using tools to automatically create boot entries for snapshots in GRUB (see #Booting into snapshots). Additionally, if the actual location of grub.cfg changes, such as when the subvolume containing /boot changes, you need to run grub-install again. See this forum thread.

And for ZFS this is worse. Grub doesn’t support all the ZFS features enabled by default in a pool, and if you let any ZFS feature not supported by Grub in the zpool where /boot is, Grub won’t even read /boot.

https://wiki.archlinux.org/title/ZFS

By default, zpool create enables all features on a pool. If /boot resides on ZFS when using GRUB you must only enable features supported by GRUB otherwise GRUB will not be able to read the pool. ZFS includes compatibility files (see /usr/share/zfs/compatibility.d) to assist in creating pools at specific feature sets, of which grub2 is an option.

You can create a pool with only the compatible features enabled:

# zpool create -o compatibility=grub2 $POOL_NAME $VDEVS
2 Likes
43

While this is true, you usually use a subvolume for /boot so that it isn’t snapshotted along with the rest of the system while still benefiting from flexible space allocation. There are a multitude of methods for boot-to-snapshot, including leveraging GRUB’s BLS support or modules like grub-btrfs.

1 Like
44

I have no experience with boot-to-snapshot, but as far as I’m aware it’s no different from mounting any other BTRFS subvol as /, so GRUB doesn’t need to know anything about it other than to pass the correct kernel parameter, which it learns at update-grub time, when the whole system is up.

There are a multitude of methods for boot-to-snapshot

But why keep supporting all of them if one simple policy decision can make that only one well-defined and well-supported option. Just have a reasonably sized /boot, say 2 GiB to be extra generous/safe for the foreseeable future and re-evaluate that size on every LTS release. Insisting on having it dynamically sized, as per the perks of BTRFS, comes at the cost of a hard requirement on GRUB supporting the filesystem natively, only to then hand over to the kernel which is much better equipped. That just feels like abusing a Ferrari engine as a starter motor; I’d sooner bump start my Linux than having such heresy on my conscience. :wink:

As Antoine de Saint-Exupéry so aptly put it: “Perfection is achieved, not when there is nothing more to add, but when there’s nothing left to take away.”

45

You are. FDE includes encrypted /boot. Otherwise it’s not FDE, and as I stated, the chain of trust is broken.

Please reconsider the LUKS drop.

2 Likes
46

No, everyone is running the same boot code, there is no reason to encrypt /boot, it just needs to be integrity protected.

Encrypted /boot has intentionally not been supported by the Ubuntu installer for a very long time (if ever).

3 Likes