![](bg4.png)
placed into the second LUKS key slot for the respec-
tive partition, so each partition can be unlocked with
either a password (slot 1) or a key (slot 2). Both key
files have to be compiled into the initramfs. On boot
GRUB asks the user for the password to load the ker-
nel and initramfs from the first encrypted partition.
The initramsfs contains the two keys and the boot pro-
cess continues without any further user input.
Secure Boot. We use the so-called shim boot loader
as the first stage boot loader that validates and then
chain-loads GRUB. Shim can be used on every UEFI
compliant computer system, as it is signed by the Mi-
crosoft UEFI CA and therefore shim is trusted and
executed by the UEFI firmware when secure boot is
enabled.
The next step is to create a MOK (Machine Owner
Key), which signs the files of GRUB and the kernel.
A certificate signed by exactly that key is then stored
into the shim controlled MOK list.
The GRUB boot loader also has support for the
shim lock module. This module forces GRUB to only
load trusted modules and files, if they are not embed-
ded inside the core.img of GRUB. Therefore, this re-
quires a GPG-key for signing all files that are inside
/boot. The public part of the GPG-key and the nec-
essary modules for verifying files are embedded into
GRUB by the reinstallation process for the GRUB bi-
nary. The resulting new GRUB binary is signed with
the MOK, and every file in the boot directory is signed
with the private part of the GPG-key. This means that
even the initramfs is validated by GRUB when load-
ing the kernel. Additionally, the kernel image must
now be signed with the private MOK key. The last
step is to configure a new UEFI boot record that points
to the shim binary.
After the installation is finished, we enable secure
boot in the firmware setup and start the boot process.
Now secure boot first validates the firmware, then fol-
lows the boot record to executes the shim binary, shim
then validates and executes the GRUB binary, and
the Linux kernel will only be loaded when its signa-
ture is valid. Therefore the chain of trust spans from
the UEFI firmware through the boot process to the
Linux kernel. The chain could even be extended fur-
ther, by enabling the Linux kernel lockdown mode,
where only signed kernel modules are permissible to
be loaded.
4.2 Fedora
General. Fedora features UEFI boot support since
version 11, which was released on June 2nd 2009.
The installation process relies on a Live Desktop en-
vironment. The graphical installer of Fedora includes
the option of an encrypted primary partition, there-
fore no additional configuration needs to be done re-
garding this feature. After the installation completes
and the machine reboots, the boot partition of Fedora
is not encrypted while the primary partition, which
holds the root filesystem partition and the swap vol-
ume, is encrypted with LUKS2.
Secure Boot. The installation program creates a boot
entry called Fedora, which references the shim bi-
nary on the EFI system partition. During the boot
process shim validates and chain loads the GRUB2
binary grubx64.efi, which is signed by the Fedora Se-
cure Boot CA key. After the user selects a kernel entry
from the GRUB2 menu, GRUB validates the kernel
file and loads both, the kernel and initramfs, files into
memory. The initramfs file however is not validated
by GRUB2. All kernels that are built and shipped by
the Fedora Project are already pre-signed with the Fe-
dora Secure Boot CA key. The kernel modules are
signed by a temporary key that is generated during
the build phase. It is not saved, a new key is used with
each kernel build (Boyer et al., 2013). The kernel is
started in lockdown mode.
FDE. To also encrypt the first partition hosting /boot,
the initial step is a backup of the contents of the
boot partition (e.g. to the home directory of the root
user). Then the partition is unmounted, reformatted as
LUKS1 encrypted partition, with an Ext4 filesystem
with the same UUID that was used by the original un-
encrypted partition. This avoids changes to /etc/fstab.
The /etc/crypttab requires a new entry for the new
boot partition. Finally, the original /boot contents can
be restored.
The GRUB configuration also needs to be updated
accordingly, however a reinstallation of the GRUB2
binary is not necessary since the EFI build of GRUB2
already includes the needed modules, such as verify,
cryptodisk and luks support (Doron et al., 2020).
Just like with other distributions, to avoid a sec-
ond passphrase prompt by the kernel, the kernel re-
quires a key in the initramfs to unlock both the boot
and the root partition. Fedora uses the program dra-
cut to generate a new initramfs image. The key file
to be embedded in the initramfs can be placed via in-
stall items. After a rebuild of the initramfs and a re-
boot, only GRUB2 asks for the boot partition LUKS
passphrase. The kernel unlocks the partitions with the
key file embedded in the initramfs image.
4.3 OpenSUSE Leap
General. OpenSUSE implemented the support for
UEFI in openSUSE 12.2, which was released on
September 5th 2012, and an experimental support for
Securing the Linux Boot Process: From Start to Finish
607