Streamlining secure boot for 26.10

Project Discussion Foundations
1

Ubuntu systems support secure boot using grub. grub contains a lot of parsers for file systems and other things which are a constant source of security issues.

In 26.10, we’d like to propose removing the following features from signed GRUB builds:

  • Filesystems for /boot
    • Remove btrfs, hfsplus, xfs, zfs
    • Retain ext4, fat, iso9660 (and squashfs for snaps)
  • Image formats:
    • Remove jpeg, png
    • Retain none
    • We do not use images, but using that in your grub.cfg locally is a massive security risk (if even still allowed)
  • Partition tables:
    • Remove part_apple
    • Retain part_gpt and part_msod

In addition to those simpler changes, we will also remove support for /boot on complex partition setups such as LVM, md-raid (except raid1), and LUKS-encrypted /boot. These abilities were inherited by Debian, but never tested in Ubuntu, and the Ubuntu installer always setup a separate bare ext4 partition.

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 FDE solution correctly implements integrity in the early boot stage, and we are committed to keep iterating and improve it.

Keep in mind these changes only affect /boot. The file systems, partition tables, LUKS, LVM, RAID solutions continue working in the booted system - we are not removing them from the Linux kernel.

We understand these are controversial options; however we believe they’d substantial improve security, but also enable pivoting to a new unified boot solutions for our supported targets in the future.

The features will continue to be available without secure boot and security support (security support is only provided for secure boot scenarios).

The timing here is crucial, by performing the changes directly after an LTS, we can keep affected users on an LTS release with support for 10 years, rather than an interim release with 9 months of support.

11 Likes
2

Can we please not drop btrfs? It’s a read-only filesystem driver that is actively supported by upstream developers. Users who want to leverage boot-to-snapshot setups with Btrfs need this support.

That’s not my experience with users. Software RAID1 is incredibly common. It would indeed be a substantial loss.

10 Likes
3

Have you considered switching to systemd-boot instead? It’s the minimal bootloader you’re looking for, and it integrates into systemd-based systems well anyway.

9 Likes
4

except Raid 1

I think they are implying raid1 wouldn’t be removed but other raid types would

systemd-boot is UEFI only, grub supports both BIOS and UEFI

1 Like
5

Do you really want to support >=20 years old systems?

3 Likes
6

Most web hosting/cloud/VPS environments today don’t support UEFI today, either. So yes, we do.

And even if you exclude that and focus on desktop/server systems, a lot of UEFI implementations have been unusably broken prior to 2017, so only the last decade of PCs have things in useful enough order.

Also, GRUB supports more than x86, and Ubuntu is a multi-arch platform, supporting platforms that neither IBM/Phoenix BIOS (and descendants) nor UEFI exist. A common bootloader drastically simplifies the maintenance burden on that front.

7 Likes
7

To add to the reply by @Conan_Kudo, bear in mind that many people have dual-boot or multi-boot systems, not all of which necessarily support UEFI.

3 Likes
8

Some Ubuntu flavors have grub themes, and I know those use images. I don’t think you can yank this since it’s something flavor customization relies on.

10 Likes
9

Does this mean that LUKS2 encrypted /boot partitions will not be allowed? I have (although manually) set on my development 26.04 system encrypted /boot partition with ext4 and LUKS2 (pbkdf) and everything works correctly.

In my personal opinion removing support for LUKS2-encrypted /boot partition isn’t wise unless GRUB2’s encryption implementation defeats security enhancements provided by encrypted /boot

6 Likes
10

I would be terribly disappointed if you were to remove images. At the moment, we can use PNG and JPEG. Supposedly, TGA is also supported, but I’ve been unable to make it work.

I’ve been seeing my welcoming Ubuntu background when I boot for many years!

From what I’ve read, the security vulnerabilities affect only versions of Grub prior to 2.12, and TGA doesn’t present a vulnerability.

Illuminate Ubuntu
Illuminate Ubuntu1920×1200 53.2 KB

6 Likes
11

To add to @tomekdev’s comment, surely Grub must support both LVM and LUKS? LUKS is an industry standard within Linux, so how would we boot without its support? LVM is also common. My system uses both LVM and LUKS.

6 Likes
12

I don’t know, if it’s a real deal then I understand and of course accept it. In the meantime, as a normal user I feel like I have to struggle more to get what I want. We had a simple timeshift btrfs layout yearso ago and that was taken away, now relying on scripts that not always work - especially on 26.04. Needing to setup a different /boot partition in order to have btrfs, xfs and zfs does feel strange, just as choosing a driver on 26.04.

13

Please explain why.

If one has the privileges to change the boot picture, couldn’t that person also change other boot parameters?

Setting a GRUB theme is the easiest way to make the boot just a bit less ugly and partially hide the embarrassing obsolescence of GRUB.

3 Likes
14

In effect systems must boot with /boot on a raw ext4 partition (whether a separate or inside of /); on GPT or MBR disks.

Full disk encryption is mandatory in many environments in Europe for security conformity. So support for encrypted /boot (via LUKS) is important.

10 Likes
15

Can you please at least reconsider the decision with LVM? Using LVM with the /boot partition was the default for Ubuntu Server LTS 24.04 and I can’t see how LVM specifically would create so many security issues. Your making your own lives harder in supporting an upgrade from LTS 24.04 to 26.10 with this decision as well.

Not supporting LVM also makes it practically annoying to do things like replace/resize the boot partition.

5 Likes
16

Are you proposing keeping or dropping support for /boot on an MD RAID-1? The first quoted text below indicates keep but the second seems to imply drop.

  • Support for md-raid; except raid1.

RAID systems are usually set up by mirroring the /boot partition, rather than putting /boot on a RAID natively

Does “mirroring the /boot partition” mean copying (at a file level) the contents of /boot, copying (at a block level) the contents of the partition, or something else?

As noted, for ZFS setups, this would mean replacing the bpool with an ext4 /boot. This loses some ZFS advantages, mainly checksums and mirroring/raidz, for reduced attack surface in GRUB.

In multi-disk setups, using an MD RAID1 is the likely replacement for mirroring/raidz, but it’s unclear if that would still be supported.

I think you should keep MD RAID1 support.

If a system has more than say 2 disks, doing copies (filesystem or block level) other than MD RAID-1 seems especially tedious and error prone. Even with two disks, it is extra complexity.

Also, when GRUB supports the mirroring, it can recover from any disk read issues. In other words, the BIOS/UEFI only needs to read GRUB off the selected disk successfully. (And if that fails, the BIOS/UEFI ought to fail over to the next boot disk.) If you don’t do mirroring in GRUB, then if GRUB loads but it can’t read the kernel or initramfs, the boot breaks.

Another option might be to use FAT, specifically the ESP, to store the kernel and initramfs. That’s non-journaling, so even worse than ext4. And existing ESPs may not be big enough. Plus you’d still have the mirroring questions/concerns.

17

To add to that: I wish it was actually significantly easier to get a graphical boot menu with user-friendly labels for the entries, i.e. something like:

  • Windows
  • Ubuntu
  • UEFI Settings
  • (Advanced) [all specific kernel versions + maybe memtest would go here]

Not only do I personally like it more and feel it’s kind of the default for other OSs - to non-technical people like my parents most of the data in the boot screen doesn’t mean anything, so I usually spend a bit of time on each fresh setup to make the boot experience a bit more welcoming.

Now I can see why maybe that’s not useful everywhere and my servers do not need anything in that direction, but if a slimmer configuration becomes the default, I feel there should be an easy way to switch to a graphical/graphics-capable version, at least for desktop systems.

18

Why not just use systemd-boot? It’s beyond time to switch and removing all this support from Grub is a bad move.

1 Like
19

There was a boot manager, Burg, like that years ago — bright, full-screen, with big logos from the actual distributions. The problem, of course, was that it didn’t work on a server.

This has already been answered previously in this thread.

2 Likes
20

Will there be a migration path forward for users who have installed zfs root using the Ubuntu installers from the past few years?

(Some of my apple amd64 and amd64v3 hardware uses unsigned grub, but a bunch of my amd64v3 hardware does use recent hardware with zfs boot partitions thanks to recent Ubuntu installers.)

1 Like