Build Archiso with proper UEFI SecureBoot signing

Question

I'm building an Archiso live USB. My goal is to make it SecureBoot compatible (users with SecureBoot enabled should be able to boot it).

It seems like this has been asked before (How to boot Arch Linux installation medium with Secure Boot enabled?) and answered but there is no explanation how this can be achieved for the build process of the Archiso.

My problem is at the moment the build.sh script, which defines the make process of the EFI as following:

# Prepare /EFI
make_efi() {
mkdir -p ${work_dir}/iso/EFI/boot
cp ${work_dir}/x86_64/airootfs/usr/share/efitools/efi/PreLoader.efi ${work_dir}/iso/EFI/boot/bootx64.efi
cp ${work_dir}/x86_64/airootfs/usr/share/efitools/efi/HashTool.efi ${work_dir}/iso/EFI/boot/

cp ${work_dir}/x86_64/airootfs/usr/lib/systemd/boot/efi/systemd-bootx64.efi ${work_dir}/iso/EFI/boot/loader.efi

mkdir -p ${work_dir}/iso/loader/entries
cp ${script_path}/efiboot/loader/loader.conf ${work_dir}/iso/loader/
cp ${script_path}/efiboot/loader/entries/uefi-shell-v2-x86_64.conf ${work_dir}/iso/loader/entries/
cp ${script_path}/efiboot/loader/entries/uefi-shell-v1-x86_64.conf ${work_dir}/iso/loader/entries/

sed "s|%ARCHISO_LABEL%|${iso_label}|g;
     s|%INSTALL_DIR%|${install_dir}|g" \
    ${script_path}/efiboot/loader/entries/archiso-x86_64-usb.conf > ${work_dir}/iso/loader/entries/archiso-x86_64.conf

# EFI Shell 2.0 for UEFI 2.3+
curl -o ${work_dir}/iso/EFI/shellx64_v2.efi https://raw.githubusercontent.com/tianocore/edk2/master/ShellBinPkg/UefiShell/X64/Shell.efi
# EFI Shell 1.0 for non UEFI 2.3+
curl -o ${work_dir}/iso/EFI/shellx64_v1.efi https://raw.githubusercontent.com/tianocore/edk2/master/EdkShellBinPkg/FullShell/X64/Shell_Full.efi
}

# Prepare efiboot.img::/EFI for "El Torito" EFI boot mode
make_efiboot() {
mkdir -p ${work_dir}/iso/EFI/archiso
truncate -s 64M ${work_dir}/iso/EFI/archiso/efiboot.img
mkfs.fat -n ARCHISO_EFI ${work_dir}/iso/EFI/archiso/efiboot.img

mkdir -p ${work_dir}/efiboot
mount ${work_dir}/iso/EFI/archiso/efiboot.img ${work_dir}/efiboot

mkdir -p ${work_dir}/efiboot/EFI/archiso
cp ${work_dir}/iso/${install_dir}/boot/x86_64/vmlinuz ${work_dir}/efiboot/EFI/archiso/vmlinuz.efi
cp ${work_dir}/iso/${install_dir}/boot/x86_64/archiso.img ${work_dir}/efiboot/EFI/archiso/archiso.img

cp ${work_dir}/iso/${install_dir}/boot/intel_ucode.img ${work_dir}/efiboot/EFI/archiso/intel_ucode.img

mkdir -p ${work_dir}/efiboot/EFI/boot
cp ${work_dir}/x86_64/airootfs/usr/share/efitools/efi/PreLoader.efi ${work_dir}/efiboot/EFI/boot/bootx64.efi
cp ${work_dir}/x86_64/airootfs/usr/share/efitools/efi/HashTool.efi ${work_dir}/efiboot/EFI/boot/

cp ${work_dir}/x86_64/airootfs/usr/lib/systemd/boot/efi/systemd-bootx64.efi ${work_dir}/efiboot/EFI/boot/loader.efi

mkdir -p ${work_dir}/efiboot/loader/entries
cp ${script_path}/efiboot/loader/loader.conf ${work_dir}/efiboot/loader/
cp ${script_path}/efiboot/loader/entries/uefi-shell-v2-x86_64.conf ${work_dir}/efiboot/loader/entries/
cp ${script_path}/efiboot/loader/entries/uefi-shell-v1-x86_64.conf ${work_dir}/efiboot/loader/entries/

sed "s|%ARCHISO_LABEL%|${iso_label}|g;
     s|%INSTALL_DIR%|${install_dir}|g" \
    ${script_path}/efiboot/loader/entries/archiso-x86_64-cd.conf > ${work_dir}/efiboot/loader/entries/archiso-x86_64.conf

cp ${work_dir}/iso/EFI/shellx64_v2.efi ${work_dir}/efiboot/EFI/
cp ${work_dir}/iso/EFI/shellx64_v1.efi ${work_dir}/efiboot/EFI/

umount -d ${work_dir}/efiboot
}

Now as told in Arch Wiki SecureBoot page, I believe that I understand everything else (and can modify the build script so it enables the signed efi binaries) in the "PreLoader" section, but how can I run the

efibootmgr --verbose --disk /dev/sdX --part Y --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

command correctly during the build process of the Archiso?

Answer 1

The efibootmgr step only configures the UEFI boot variables of your system to add that particular bootloader on that particular disk (identified by disk UUID in the GPT partition table header) in your system's boot order. It has nothing to do with Secure Boot.

When preparing a UEFI-bootable removable media, you won't need that. For UEFI, a removable media is bootable if it simply has <media root>/EFI/Boot/bootx64.efi on it. On a FAT32-formatted USB stick, this is expected to be within the stick's main filesystem; on an actual ISO9660-formatted CD/DVD, the FAT32 filesystem should be packaged into a dedicated boot image file, whose location on the disk is indicated in the El Torito boot data.

Your build.sh script already includes the creation of efiboot.img, which is apparently intended to be this boot image file (as long it's identified with appropriate parameters in the ISO image creation phase).

Basically, your build.sh has two distinct functions for different UEFI boot situations: make_efi() is for preparing the UEFI bootloader for an USB stick, and make_efiboot() is for preparing a boot image for building an ISO9660 CD/DVD image that will be burned on an actual CD/DVD.

You may have seen Linux installation .iso images which can be written to USB stick using dd or similar. These are not just regular ISO9660 images with El Torito boot information: these images include special isohybrid processing which puts a simple MBR partition table at the very beginning of the ISO image, which then presents the efiboot.img file as a "partition" within the ISO image data, resulting in a "dual-mode" image file that can work both when burned on an actual CD/DVD media, and when written on a USB stick, even when the actual boot procedure is very different between those two modes.

Your build.sh snippet does apparently not include the ISO image creation step, so I cannot guess whether ${work_dir}/iso will be written to the actual USB media or whether it will be used to build an .iso image file.

Some UEFI firmwares actually include ISO9660 filesystem support natively, so they might just look for /EFI/Boot/bootx64.efi on an ISO9660 filesystem instead of (or in addition to) reading a special FAT32 UEFI boot image using the El Torito boot information; however, not all systems are guaranteed to have this capability.