openSUSE Tumbleweed and MicroOS have made some significant changes to their boot loader and full disk encryption (FDE) capabilities. The new image now uses systemd-boot as the boot loader and implements full disk encryption based on systemd. This update aims to improve the security of the distribution while simplifying the design.
systemd-boot
The previous boot loader used by openSUSE, GRUB2, is feature-rich but complex and slow to develop. The openSUSE package for GRUB2 contains over 200 patches, some of which have been present for many years. While GRUB2 supports various systems and file systems, the introduction of UEFI made many of its features redundant, as the system firmware already provided similar functionalities.
As a result, more straightforward boot loaders focused on UEFI, such as gummiboot, emerged. Eventually, this code was integrated into systemd and renamed systemd-boot. Compared to GRUB2, systemd-boot is much simpler and serves as a small EFI binary that presents a menu with different boot loader entries and delegates the execution to the selected kernel.
systemd-boot can also work with unified kernel images (UKI) that aggregate the kernel, command line, and initrd into a single unit. openSUSE plans to support UKIs in the future.
openSUSE has been planning to provide systemd-boot as an alternative to GRUB2 for some time, and in August 2023, Tumbleweed started supporting systemd-boot. The yast-bootloader tool also gained support for systemd-boot for new installations.
While supporting another boot loader comes with challenges, such as decreased support for different architectures and compatibility issues with btrfs file systems, openSUSE is actively working on addressing these problems.
Full Disk Encryption
openSUSE has also introduced support for full disk encryption based on systemd. While GRUB2 already supported unlocking LUKS volumes, systemd offers some additional features, such as partial support for LUKS2 encryption and integration with TPM2 devices.
The TPM2 (Trusted Platform Module 2) is a cryptographic device that can unlock secrets only when certain conditions related to the system’s state are met. The TPM2 will unlock the secret if the system is in a known good state, ensuring that the firmware, boot loader, kernel, and initrd have not been tampered with.
To take advantage of TPM2 for FDE, openSUSE has developed a policy that instructs the TPM2 to decrypt a secret only if certain platform configuration registers (PCR) contain the expected values. The PCR values are measured during the boot process, and any changes to the system will result in different PCR values, preventing the secret from being decrypted.
openSUSE has also improved the prediction of PCR values using the pcr-oracle tool, which can encrypt a key under a set of PCR values that can change. This allows for flexible unlocking mechanisms and better system integrity checks.
Using systemd for Disk Encryption
While GRUB2 is still functional for FDE, the use of systemd-boot provides an alternative architecture that works with any boot loader that follows the Boot Loader Specification (BLS). With systemd-boot, the kernel and initrd are placed in the unencrypted EFI system partition (ESP), and the unlock of the sysroot (where the system is located) is done from inside the initrd using systemd-cryptsetup options.
To support this new architecture, openSUSE provides a MicroOS image named kvm-and-xen-sdboot that showcases the new FDE capabilities. This image includes systemd-boot, sdbootutil scripts for synchronizing boot entries, pcr-oracle for predicting PCR values, disk-encryption-tool for encrypting the sysroot device, and dracut-pcr-signature, a dracut module that loads predictions into the initrd from the ESP.
The tools work together to ensure a secure and seamless boot process. The VM with a virtual TPM2 device measures the executed code and data, extending the PCR values. systemd-boot then reads the correct boot entry, and the disk-encryption-tool script encrypts the sysroot device. Finally, the jeos-firstboot modules handle the enrollment of FIDO2 keys and provide recovery key information.
Future Improvements
While the current implementation is a sound proof of concept, there are several areas for improvement. The disk-encryption-tool should be integrated into the installer, and the jeos-firstboot modules should also live in the installer or be merged with the functionality provided by the encryption tool. Separating system keys from user keys and enabling the use of TPM2 and FIDO2 keys simultaneously are also potential improvements.
Additionally, openSUSE aims to work with upstream projects, such as systemd and GRUB2, to incorporate the current tools and features. The diagnosis of TPM2 rejection for unlocking the LUKS2 key could be improved, and the integration of multiple encrypted disks should be validated and enhanced.
Ultimately, openSUSE is considering the use of unified kernel images and further standardization to simplify the architecture. The generation and registration of new keys, as well as the selection of PCR values, may be automated or better documented to streamline the process.
