please add luks2 module to the signed grub2 images

[Niklas Sombert]

I (erroneously) created my new root partition with LUKS2 (with pbkdf2 though) and tried to mount it from GRUB. It didn't work with Secure Boot enabled, but it did work with Secure Boot disabled, because I was then able to load the luks2 module.

Please consider including the luks2 module in the signed EFI images.

$ lsb_release -rd
Description: Ubuntu 22.04.1 LTS
Release: 22.04
$ LANG=C apt-cache policy grub-efi-amd64
grub-efi-amd64:
  Installed: (none)
  Candidate: 2.06-2ubuntu10
  Version table:
     2.06-2ubuntu10 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
     2.06-2ubuntu7 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Julian Andres Klode (juliank)]

We do not provide users any means to install to encrypted systems without a separate /boot, and we have *a lot* of CVEs in grub, so I'm leaning towards saying no here.

The existing modules are there to not break boot on existing systems, but we should try to avoid adding new modules to the list wherever possible.

[Julian Andres Klode (juliank)]

Basically the module is not that big really but it also adds a JSON parser to the attack surface.

[Niklas Sombert (ytvwld)]

Ubuntu (ubiquity) makes it really hard to get LUKS without a separate /boot, yes, but it's the default for Lubuntu (but with LUKS1 obviously).

I can understand the JSON argument, though. I'm not sure JSON is worse than GRUB's own config file parsing, but sadly, it adds attack surface, yes.

[Julian Andres Klode (juliank)]

Assigning to the security team for review (1. do we want to support /boot inside luks2 and 2. small MIR-style code review if so)

[Seth Arnold (seth-arnold)]

We haven't really discussed this yet, but I'm initially skeptical.

Handling security updates in our signed boot code is very expensive. What we include inside the signed boundaries should be as minimal as we need, we shouldn't just include everything because it would be neat.

Ubuntu is an opinionated distribution, and part of that is the expected boot paths. I think it's fair to say "decide between secureboot and your botique boot path".

Does LUKS2 bring along compelling features? Is it mature enough to recommend to our users? What would it look like to integrate it into our installers? Do we want to transition users? Do we support both for a while? How long do we support both?

I think I'd rather this go through a more rigorous process: discussion at a planning sprint, or summit, etc., before starting in on the more expensive tasks.

Thanks

[Steve Langasek (vorlon)]

The GRUB LUKS implementation always trails the kernel+userspace implementation, so compatibility is always an issue. Given the security surface, and the usability issues over compatibility across time, I do not think it is justified to include this in the signed binary.

[Niklas Sombert (ytvwld)]

That's sad to hear, but sounds reasonable. Are there any plans to sign the initramfs instead?

[Julian Andres Klode (juliank)]

It seems we are inadvertently shipping luks2 support in 23.10 as we missed it got added in Debian, so I'm changing this from Won't Fix to Fix Released. We'll have to reassess whether to close that can of worms again after the release :D

[Seth Arnold (seth-arnold)]

Does this mean that we sent a large new feature to Microsoft for signing without noticing it? If so, I'd like to suggest that we investigate how this happened and try to change processes so these surprises don't happen again.

Thanks

[Seth Arnold (seth-arnold)]

.. It turns out that this was a bad experience all around:

https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/2043101

Thanks

[Niklas Sombert (ytvwld)]

Well, the bad experience comes from disabling the feature. :D

[Steve Langasek (vorlon)]

Mantic will EOL soon. This has never been supported in noble. It's unfortunate that it remained enabled in mantic as long as it did when we knew we intended not to support it, inducing some users to rely on an unsupported configuration, but I don't think there's any more action to take here.

If you don't care about the integrity of SecureBoot, you can disable it in your firmware. Or you can locally sign a grub.efi including whatever modules you want. But for the EFI binary signed by Ubuntu, we have a duty to ensure the code doesn't unduly risk the security of all Ubuntu users, and the luks2 module has not passed muster.