Build Archiso with proper UEFI SecureBoot signing

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












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: (sorry for the lack of indentation)



# Prepare /EFI
make_efi() 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() $install_dir


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?










share|improve this question





















  • 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 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 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 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 at 8:28










  • The signed shim binary was obtained by me from MSFT indeed but their procedure basically started with "come with a third party Code Signing certificate" -- my guess is to avoid messing with identification (the change here was that they want EV cert now, it's more expensive and is expected to come with more thorough identity checks). You'd better try your own cert (the one generated by you, not the one from 3rd party you use to authenticate to UEFI CA) before freezing it into a signed shim binary only to find out the build is faulty, of course. :-) Use it to sign updated binaries later on too.
    – Michael Shigorin
    Aug 10 at 8:12














up vote
1
down vote

favorite












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: (sorry for the lack of indentation)



# Prepare /EFI
make_efi() 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() $install_dir


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?










share|improve this question





















  • 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 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 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 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 at 8:28










  • The signed shim binary was obtained by me from MSFT indeed but their procedure basically started with "come with a third party Code Signing certificate" -- my guess is to avoid messing with identification (the change here was that they want EV cert now, it's more expensive and is expected to come with more thorough identity checks). You'd better try your own cert (the one generated by you, not the one from 3rd party you use to authenticate to UEFI CA) before freezing it into a signed shim binary only to find out the build is faulty, of course. :-) Use it to sign updated binaries later on too.
    – Michael Shigorin
    Aug 10 at 8:12












up vote
1
down vote

favorite









up vote
1
down vote

favorite











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: (sorry for the lack of indentation)



# Prepare /EFI
make_efi() 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() $install_dir


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?










share|improve this 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: (sorry for the lack of indentation)



# Prepare /EFI
make_efi() 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() $install_dir


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?







linux arch-linux uefi secure-boot






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Aug 7 at 19:13









Jussi Hietanen

61




61











  • 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 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 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 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 at 8:28










  • The signed shim binary was obtained by me from MSFT indeed but their procedure basically started with "come with a third party Code Signing certificate" -- my guess is to avoid messing with identification (the change here was that they want EV cert now, it's more expensive and is expected to come with more thorough identity checks). You'd better try your own cert (the one generated by you, not the one from 3rd party you use to authenticate to UEFI CA) before freezing it into a signed shim binary only to find out the build is faulty, of course. :-) Use it to sign updated binaries later on too.
    – Michael Shigorin
    Aug 10 at 8:12
















  • 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 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 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 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 at 8:28










  • The signed shim binary was obtained by me from MSFT indeed but their procedure basically started with "come with a third party Code Signing certificate" -- my guess is to avoid messing with identification (the change here was that they want EV cert now, it's more expensive and is expected to come with more thorough identity checks). You'd better try your own cert (the one generated by you, not the one from 3rd party you use to authenticate to UEFI CA) before freezing it into a signed shim binary only to find out the build is faulty, of course. :-) Use it to sign updated binaries later on too.
    – Michael Shigorin
    Aug 10 at 8:12















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 at 20:17





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 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 at 20:38





@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 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 at 5:41




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 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 at 8:28




@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 at 8:28












The signed shim binary was obtained by me from MSFT indeed but their procedure basically started with "come with a third party Code Signing certificate" -- my guess is to avoid messing with identification (the change here was that they want EV cert now, it's more expensive and is expected to come with more thorough identity checks). You'd better try your own cert (the one generated by you, not the one from 3rd party you use to authenticate to UEFI CA) before freezing it into a signed shim binary only to find out the build is faulty, of course. :-) Use it to sign updated binaries later on too.
– Michael Shigorin
Aug 10 at 8:12




The signed shim binary was obtained by me from MSFT indeed but their procedure basically started with "come with a third party Code Signing certificate" -- my guess is to avoid messing with identification (the change here was that they want EV cert now, it's more expensive and is expected to come with more thorough identity checks). You'd better try your own cert (the one generated by you, not the one from 3rd party you use to authenticate to UEFI CA) before freezing it into a signed shim binary only to find out the build is faulty, of course. :-) Use it to sign updated binaries later on too.
– Michael Shigorin
Aug 10 at 8:12










1 Answer
1






active

oldest

votes

















up vote
0
down vote













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.






share|improve this answer




















  • 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 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 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 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 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 at 6:47










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461150%2fbuild-archiso-with-proper-uefi-secureboot-signing%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













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.






share|improve this answer




















  • 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 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 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 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 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 at 6:47














up vote
0
down vote













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.






share|improve this answer




















  • 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 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 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 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 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 at 6:47












up vote
0
down vote










up vote
0
down vote









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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Aug 8 at 0:52









telcoM

11.4k11333




11.4k11333











  • 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 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 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 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 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 at 6:47
















  • 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 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 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 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 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 at 6:47















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 at 12:48




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 at 12:48




1




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 at 17:17





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 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 at 5:45




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 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 at 5:49




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 at 5:49




1




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 at 6:47




@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 at 6:47

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461150%2fbuild-archiso-with-proper-uefi-secureboot-signing%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay