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?

  • If you're not strictly tied to Arch, maybe looking at any distro that went through this mess[1] is more feasible -- e.g. ALT Rescue can be tailored to one's needs quite easily and it tends to work under SecureBoot enabled. [1] en.altlinux.org/UEFI_SecureBoot_mini-HOWTO – Michael Shigorin Aug 7 '18 at 20:17
  • @MichaelShigorin Thanks for the suggestion! However, I've done most of the work already using Archiso as the base... However, I looked through that wiki page, and realized that I can use shim to sign the efi binary with my own certificate. Buying my own cert is not a problem, but I still need to know how to apply it into my own Archiso build :) – Jussi Hietanen Aug 7 '18 at 20:38
  • The certificate is only the start of a headache, not sure you're going to come through it for Arch -- but if it's worth that for you, consult with those who implement(ed) UEFI support there. I was actually the one who did that for ALT, so if surviving SB (without making user to mess with extra keys) is absolutely needed, this might easily become the real "most of the work"... I know like 5 distro projects that went through this. // but hey, I only scare you to not underestimate the effort needed down that road ;-) – Michael Shigorin Aug 9 '18 at 5:41
  • @MichaelShigorin Oh I didn't recognize it was you! I followed your AltLinux wiki page and I think some things have changed since you wrote it (for example the certificate - it must be obtained from MS, or at least the signed shim binary). I also think that I'm able to get the shim working. As if I understood correctly, I just need to sign the systemd bootloader .efi binary and my kernel binary with my part of the cert key I used before sending the shim binary for MS to sign..? Do you know if anything else needs to be considered? – Jussi Hietanen Aug 9 '18 at 8:28
  • 1
    I'd recommend following this bug if you are interested. – mirh Jan 24 '19 at 20:34

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.

  • Thanks! I figured also myself that the efibootmgr step was unnecessary. But your reply helps me to understand UEFI a lot better, and thanks for clarifying that USB/disk difference! I researched this SecureBoot subject a lot yesterday and I was able to replace the PreLoader and HashTool with signed ones, and I was actually able to boot the "burned" USB stick on a SecureBoot enabled machine, but I still had to manually enroll the actual bootloader and kernel. Now I think that I'll need to go for shim and buy a certificate for complete SecureBoot compatibility for my archlive. – Jussi Hietanen Aug 8 '18 at 12:48
  • 1
    Before paying for a UEFI boot signing certificate, have you checked if it's possible to install your own? If the UEFI configuration screens allow deleting the Secure Boot Primary Key (PK), Secure Boot switches into "Setup Mode" which means you can edit all the Secure Boot key variables without the requirement to have the new variable content as signed updates. You can then configure your own Secure Boot certs. Of course, if your goal is a disk/USB that is bootable on any Secure Boot system without configuration changes, then you'll need a signed certificate, probably from Microsoft. – telcoM Aug 8 '18 at 17:17
  • Erm, if you don't understand UEFI well enough at this stage, maybe spare some time for these articles: rodsbooks.com/efi-bootloaders -- very well worth reading right from the "principles". Buying a certificate is worthless unless one plans to go through UEFI CA (nee MSFT) to get a signed shim binary holding a public part of it. – Michael Shigorin Aug 9 '18 at 5:45
  • PS: regarding the iso build script, there were quite a few nuances with xorriso argument order for me; the result is here: git.altlinux.org/people/mike/packages/… (the other script taking part in preparing iso contents is mki-copy-efiboot but that one is somewhat overcomplicated, should be moved to mkimage-profiles and simplified a lot). – Michael Shigorin Aug 9 '18 at 5:49
  • 1
    @Michael Shigorin:you're absolutely correct: as long as you can achieve what you want with an already-signed shim, you don't need to buy a certificate for UEFI signing at all. (and that teaches me: when interrupted in mid-comment, read & see if it makes sense before submitting) – telcoM Aug 9 '18 at 6:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.