enable grub-2.00 boot-from-luks support

[Yung-Chin Oei]

(I suppose this comes too late in the release cycle to make the change, but perhaps it's simple enough:)

With only minimal manual intervention, I found I could use today's Ubuntu Server 12.10 daily iso to install a system with luks+lvm and no separate /boot partition (which doesn't really have any security advantages, but it makes managing space on a smallish disk easier). If grub-installer could manage the final 2 steps below, it would all be fully automatic. Thanks!

Steps:
1: go through the default installer motions
2: in partman, choose the manual option
3: create a single, whole-disk primary partition, use it as a luks encrypted volume
4: on top of that, create an lvm physical volume
5: insert lvm logical volumes for swap and / (I used btrfs, probably irrelevant)
6: finish remaining installer steps; find that grub install fails
7: drop into shell, per alt+f2, and chroot to /target
8: append "GRUB_CRYPTODISK_ENABLE=y" to /etc/default/grub
9: run "grub-install /dev/sda" (replace sda etc etc), then "update-grub", reboot

[Yung-Chin Oei (yungchin)]

I erroneously filed this bug against partman-crypto - should have probably been grub-installer.

[Launchpad Janitor (janitor)]

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

[Adam Stokes (adam-stokes)]

After speaking with engineering my premature nominations wouldn't be applicable since the changes necessary would be very invasive.

[Adam Stokes (adam-stokes)]

Yung-Chin,

This would be a very welcome enhancement, however, TMK there has been nothing in the roadmap to suggest supporting cryptodisk within grub-installer. I do feel that this should be kept open as a feature request to revisit in the future.

Thank you,
Adam

[Yung-Chin Oei (yungchin)]

Thanks for keeping this updated Adam!

I don't complete understand though - I believe the only real change needed is that this step:

 8: append "GRUB_CRYPTODISK_ENABLE=y" to /etc/default/grub

gets done automatically. Would it be harmful to just stick that in the default template for all setups? Other than causing a few extra modules to be installed in the grub partition, I don't think it would do any bad, or?

[Adam Stokes (adam-stokes)]

Hi Yung-Chin,

I will investigate your suggestion and see what our options are. I'll post back here when I have some more information for you.

Thanks again
Adam

[Adam Stokes (adam-stokes)]

Colin,

Hope you don't mind I subscribed you to this bug in hopes you may have some more information to shed on this particular issue.

Thank you!
Adam

[Mark Russell (marrusl)]

Enabling boot from LUKS would also fix LP bug 1067106.

[timjor19 (timjor19)]

It has been since 2013 and there is still no solution to this or fixed Ubuntu installer?

If there is a solution/guide elsewhere please link it to this thread.

[TJ (tj)]

GRUB_CRYPTODISK_ENABLE=y

will cause UEFI Secure Boot to fail until the Canonical signed GRUB images include the necessary modules for crypto algorithms, cryptodisk and luks.

[kay (kay-diam)]

At last high importance. BTW, what about this bug? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532

[Nazar Mokrynskyi (nazar-pc)]

Some more details with exact steps needed for this to be fixed on UEFI system in following bug report: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1670552

[Mate Kukri (mkukri)]

Encrypted /boot partitions isn't a currently supported configuration. Despite this signed UEFI GRUBs have the `luks` module built-in for backwards compatibility with some old setups, we have no plans to include `luks2` or support more modern encrypted /boot setups going forward.

For full disk encryption on modern Ubuntu, I recommend looking into the current password based or TPM FDE options provided by the Ubuntu installer.

[Nazar Mokrynskyi (nazar-pc)]

> For full disk encryption on modern Ubuntu, I recommend looking into the current password based or TPM FDE options provided by the Ubuntu installer.

But you realize not everyone uses the things offered by installer exclusively, right?

I have FDE with encrypted boot for many years now, only grub and config are left unencrypted and you force me to use older less secure LUKSv1 despite upstream supporting LUKSv2. Distro maintainers should really stop messing with upstream software and ship it they it is intended to be.

Making this as "Won't Fix" after more than a decade of waiting is extremely frustrating.

[semreh (launchpad-via-forwarder)]

I suspect part of the motivation for this decision is that GRUB2 still does not have upstream support for Argon2 Key Derivation Functions (KDFs), so adding luks2 'support' only works if the KDF is restricted to PBKDF2. I don't know if the problem with 'grub-probe' not recognising luks2 formatted block-devices has been solved either, which makes automating the creation of the GRUB2 setup up more challenging than it should be.

I do not expect Ubuntu to solve GRUB's problems implementing Argon2 KDFs (it requires non-trivial changes to GRUB2s version of libgcrypt - GRUB2 applies patches to a particular version of the source of libgcrypt from upstream which is then compiled for the GRUB2 environment - see the grub-devel mailing list and search for libgcrypt).

Rather than saying "Won't Fix", I'd prefer it if the Ubuntu developers simply made supporting luks2 and Argon2 KDFs a dependency on upstream GRUB2 doing so. Not all systems that people wish to run Ubuntu on support TPM-backed FDE, and it would be helpful to continue allowing an encrypted /boot.

I'll say again that I don't expect Ubuntu to develop and support their own patchset on upstream GRUB2 - merely that once upstream GRUB2 offers Argon2 KDFs that Ubuntu will support that by including relevant modules. I don't think that is an unreasonable request. I respectfully request that the status is changed from "Won't Fix" to "In progress", and the assigned person tracks GRUB2's progress on implementing Argon2 KDFs.

[Nazar Mokrynskyi (nazar-pc)]

Argon2 is already supported in GRUB2 version that Ubuntu ships (in fact it was already in the version that was shipped with Ubuntu 23.10), but Ubuntu maintainers decided to disable that as well! See https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2047485

This is why the whole situation is so frustrating. They seem to intentionally remove features that are present upstream for no good reason as far as I'm concerned.

[Julian Andres Klode (juliank)]

The new LUKS2 format stores the metadata in a JSON document which requires a JSON parser in grub. Given that Ubuntu does not support encrypted /boot partitions, the decision was made not to enable the feature such as to prevent the JSON code from becoming an attack vector to break secure boot.

Please note that encryption of /boot is security by obscurity: The data is encrypted, but not authenticated so it is still subject to chosen plaintext attacks, as is any encrypted data. You do not need obscurity for public knowledge like kernel and initrd content, it's only valuable for your personal private data.

A secure chain needs to authenticate the initrd against a certificate. For example, Ubuntu Desktop TPM FDE offers fully authenticated early boot environments.

[Nazar Mokrynskyi (nazar-pc)]

> The new LUKS2 format stores the metadata in a JSON document which requires a JSON parser in grub. Given that Ubuntu does not support encrypted /boot partitions, the decision was made not to enable the feature such as to prevent the JSON code from becoming an attack vector to break secure boot.

I'd rather invest in fuzzer or integrate Rust-based JSON parser than removing it completely.

> Please note that encryption of /boot is security by obscurity: The data is encrypted, but not authenticated so it is still subject to chosen plaintext attacks, as is any encrypted data. You do not need obscurity for public knowledge like kernel and initrd content, it's only valuable for your personal private data.

While true in theory, I'm not sure it is applicable. Modern well designed ciphers and encryption schemes should not be succeptible to this attack, though I can't speak to LUKS specifically, I do not fully know how it is implemented in detail. Also kernel and initrd content might be public knowledge with kernels that you, Ubuntu, ship, which is not true if there are customizations applied on the system. While I don't think they are particularly sensitive, the fact that kernel and initrd are public knowledge is strictly speaking not true.

> A secure chain needs to authenticate the initrd against a certificate. For example, Ubuntu Desktop TPM FDE offers fully authenticated early boot environments.

Ubuntu's desktop FDE is a special case that only works with Ubuntu-signed precompiled kernel that depends on Snap (I use neither Ubuntu kernel nor Snap on my desktop). I was initially very optimistic an then kind of disappointed by implementation.

I have configured TPM FDE encryption that fully verifies everything on one of my Ubuntu servers with self-signed initrd (mostly based on https://blastrock.github.io/fde-tpm-sb.html while using different tools for some of the steps). It does work, but even then was a bit painful on 23.10 due to Ubuntu not shipping some of the systemd components required for this to work on purpose (ukify specifically, see https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2031898).

I understand that you have a "canonical" way of doing FDE that is user-friendly, but that is not the only way and making it impossible to use alternatives is very annoying.

[Stu Card (stu-card)]

This was not strictly true of something we demonstrated in 2017: the
capability based, formally verified, open source, Syracuse Assured Boot
Loader Executive (SABLE), which used the "late launch" Dynamic Root of
Trust for Measurement (DRTM) instructions available on AMD and Intel x86
CPUs (skinit/senter) to decrypt an operating environment conditionally
based on measurements of Trusted Computing Base (TCB) software modules
extended into TPM Platform Configuration Registers (PCRs) matching
values previously whitelisted by the system administrator. We were able
to boot not only Ubuntu but also the formally verified seL4 microkernel.
Upstream changes broke this. We have not had the resources both to
maintain SABLE and patch the upstream changes, so SABLE has bit-rotted;
when we obtain the necessary resources, we would really like again to be
able to boot not only seL4 (our primary target) but also more popular
kernels (primarily Linux where the distro that is our usual focus and
tool is Ubuntu).

On 6/13/2024 8:40 AM, Julian Andres Klode wrote:
> ...
> Please note that encryption of /boot is security by obscurity: The data
> is encrypted, but not authenticated so it is still subject to chosen
> plaintext attacks, as is any encrypted data. You do not need obscurity
> for public knowledge like kernel and initrd content, it's only valuable
> for your personal private data.
>
> A secure chain needs to authenticate the initrd against a certificate.
> For example, Ubuntu Desktop TPM FDE offers fully authenticated early
> boot environments...

--
Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc.
Superior Engineering Solutions for Trustworthy Networked Autonomy
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <email address hidden> www.critical.com