Unlocking Disks Earlier: Basic LUKS1 Support Arrives in U-Boot
A new 24-patch series in Concept that introduces basic support for unlocking LUKS1 encrypted partitions directly within U-Boot. This is a foundational step toward a more integrated and user-friendly full-disk encryption (FDE) experience.
๐ค The Problem with “Late” Unlocking
Traditionally, FDE on Linux systems is handled late in the boot process. U-Boot loads a kernel and an initial ramdisk (initramfs), and it’s the initramfs’s job to prompt the user for a passphrase and unlock the main root filesystem.
This common approach works, but it has several drawbacks:
- Firmware is blind: U-Boot has no way of knowing if the boot will succeed until long after it has handed off control.
 - Confusing user experience: The passphrase prompt appears late in the boot sequence, sometimes after the vendor logo has disappeared.
 - No integrated UI: It’s not possible to create a single, polished firmware UI that handles both boot selection and disk decryption.
 - Inflexible for automation: In VM environments where a key might be known in advance, there’s no way for the firmware to use it, so the ramdisk must handle this through attestation, etc.
 - Ramdisk is required: You can’t boot from an encrypted disk unless you also use a ramdisk to perform the unlock.
 
๐ก What’s New: The luks Command
This patch series takes a small step to improve this by bringing decryption capabilities into U-Boot itself. The new feature set is centered around the luks command, which allows U-Boot to interact with LUKS-encrypted partitions.
The command introduces three main subcommands:
luks detect: Checks if a given partition is a valid LUKS device.luks info: Parses and displays the LUKS header metadata. This works for both LUKS1 and LUKS2 partitions, thanks to a new simple JSON parser included in the series for handling the LUKS2 header.luks unlock: unlocks a LUKS1 partition using a provided passphrase.
Hereโs a look at it in action:
=> luks detect mmc 1:2 LUKS1 encrypted partition detected => luks info mmc 1:2 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha256 Payload offset: 4096 sectors Key bytes: 32 => luks unlock mmc 1:2 mysecretpassphrase Unlocked LUKS partition as blkmap device 'luks-mmc-1:2' =>
๐ Accessing Decrypted Data via blkmap
Once a partition is unlocked, how do you access the data? The luks unlock command integrates with U-Boot’s blkmap subsystem.
When a partition is successfully unlocked, a new virtual blkmap device is created. This device provides read-only access to the decrypted data on-the-fly.
This means you can now use standard U-Boot commands to read files directly from the encrypted partition, just as if it were a normal, unencrypted disk:
=> ls blkmap 0 /
          ./
          ../
          lost+found/
2481008   vmlinuz-6.8.0-53-generic
1616      initrd.img-6.8.0-53-generic
=> ext4load blkmap 0 ${kernel_addr_r} /vmlinuz-6.8.0-53-generic
2481008 bytes read in 64 ms (37.0 MiB/s)
=>
This simple feature allows U-Boot to load a kernel, read a configuration file, or access any other data from an encrypted volume before booting.
๐ ๏ธ Under the Hood: What Made This Possible
There is quite a bit of foundational work included in this series:
- Crypto: The 
mbedtlslibrary in U-Boot was enhanced to enable PKCS#5 (PBKDF2) functions, which are essential for deriving keys from passphrases in LUKS. A fix for AES-192 and AES-256 key-size handling was also included. blkmapEnhancement: Theblkmapdriver was extended with a newblkmap_map_crypt()function to handle the on-the-fly decryption.- Testing: A large portion of the series is dedicated to building solid testing infrastructure. This includes updates to the Docker image, CI configuration and new Python test helpers (
fs_helper.py) to create, encrypt, and test against real LUKS1 and LUKS2 disk images. 
This series lays the groundwork for a more secure and streamlined boot process. While full LUKS2 unlock support and read-write access are topics for another day, this is a step forward.