Dear all, I failed to find the answer myself. :-( It seems to me that the AARCH64 version of Fedora is not enabled for UEFI Secure Boot like the x86_64 version. I.e., the shim EFI binary is not signed and neither is the kernel (see below). What am I missing? What am I doing wrong? Background: I want to use AARCH64 Fedora in a UEFI Secure Boot environment with the the pre-deployed keys from Microsoft. Thanks, Udo
AARCH64
# uname -r 6.15.10-200.fc42.aarch64 # sbverify --list /boot/efi/EFI/fedora/shimaa64.efi warning: data remaining[830464 vs 971654]: gaps between PE/COFF sections? warning: data remaining[830464 vs 971656]: gaps between PE/COFF sections? No signature table present # sbverify --list /boot/vmlinuz-6.15.10-200.fc42.aarch64 No signature table present #
X86_64
# uname -r 6.15.7-200.fc42.x86_64 root@ronin:~# sbverify --list /boot/efi/EFI/fedora/shimx64.efi warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections? signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root # sbverify --list /boot/vmlinuz-6.15.9-201.fc42.x86_64 signature 1 image signature issuers: - /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca image signature certificates: - subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot Signer/OU=bkernel01 kernel/CN=kernel-signer issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca #
Hi there, any hints on this topic? Cheers, Udo
On Sun, 31 Aug 2025, Udo Seidel wrote:
Dear all, I failed to find the answer myself. :-( It seems to me that the AARCH64 version of Fedora is not enabled for UEFI Secure Boot like the x86_64 version. I.e., the shim EFI binary is not signed and neither is the kernel (see below). What am I missing? What am I doing wrong? Background: I want to use AARCH64 Fedora in a UEFI Secure Boot environment with the the pre-deployed keys from Microsoft. Thanks, Udo
AARCH64
# uname -r 6.15.10-200.fc42.aarch64 # sbverify --list /boot/efi/EFI/fedora/shimaa64.efi warning: data remaining[830464 vs 971654]: gaps between PE/COFF sections? warning: data remaining[830464 vs 971656]: gaps between PE/COFF sections? No signature table present # sbverify --list /boot/vmlinuz-6.15.10-200.fc42.aarch64 No signature table present #
X86_64
# uname -r 6.15.7-200.fc42.x86_64 root@ronin:~# sbverify --list /boot/efi/EFI/fedora/shimx64.efi warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections? signature 1 image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
Corporation UEFI CA 2011 image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root # sbverify --list /boot/vmlinuz-6.15.9-201.fc42.x86_64 signature 1 image signature issuers:
- /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot
CA 20200709/CN=fedoraca image signature certificates:
- subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora
Secure Boot Signer/OU=bkernel01 kernel/CN=kernel-signer issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca #
Hi,
Last I knew, we did not have hardware available to sign the secure-boot binaries at build time for AArch64. so we have not gone through the process to have Microsoft sign shim. The way that it works on x86_64 is that there are dedicated builders with smartcards installed that have the keys for signing. pesign Is used to do the signing. In order to sign the binaries on AArch64 we would need some builders set up the same way, and then we could sign grub, shim, and kernel. Then we would have shim signed by Microsoft and included in the shim-signed package. Today, the only way to enable secure boot is to sign the binaries yourself and enroll and trust the keys in the system.
Dennis
On Sun, Sep 7, 2025 at 4:40 AM Udo Seidel via arm arm@lists.fedoraproject.org wrote:
Hi there, any hints on this topic? Cheers, Udo
On Sun, 31 Aug 2025, Udo Seidel wrote:
Dear all, I failed to find the answer myself. :-( It seems to me that the AARCH64 version of Fedora is not enabled for UEFI Secure Boot like the x86_64 version. I.e., the shim EFI binary is not signed and neither is the kernel (see below). What am I missing? What am I doing wrong? Background: I want to use AARCH64 Fedora in a UEFI Secure Boot environment with the the pre-deployed keys from Microsoft. Thanks, Udo
AARCH64
# uname -r 6.15.10-200.fc42.aarch64 # sbverify --list /boot/efi/EFI/fedora/shimaa64.efi warning: data remaining[830464 vs 971654]: gaps between PE/COFF sections? warning: data remaining[830464 vs 971656]: gaps between PE/COFF sections? No signature table present # sbverify --list /boot/vmlinuz-6.15.10-200.fc42.aarch64 No signature table present #
X86_64
# uname -r 6.15.7-200.fc42.x86_64 root@ronin:~# sbverify --list /boot/efi/EFI/fedora/shimx64.efi warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections? signature 1 image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
Corporation UEFI CA 2011 image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root # sbverify --list /boot/vmlinuz-6.15.9-201.fc42.x86_64 signature 1 image signature issuers:
- /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot
CA 20200709/CN=fedoraca image signature certificates:
- subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora
Secure Boot Signer/OU=bkernel01 kernel/CN=kernel-signer issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca #
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Once upon a time, Dennis Gilmore dennis@ausil.us said:
Last I knew, we did not have hardware available to sign the secure-boot binaries at build time for AArch64. so we have not gone through the process to have Microsoft sign shim. The way that it works on x86_64 is that there are dedicated builders with smartcards installed that have the keys for signing. pesign Is used to do the signing. In order to sign the binaries on AArch64 we would need some builders set up the same way, and then we could sign grub, shim, and kernel. Then we would have shim signed by Microsoft and included in the shim-signed package. Today, the only way to enable secure boot is to sign the binaries yourself and enroll and trust the keys in the system.
What AArch64 hardware ships with SecureBoot and MS's keys in firmware? Does that include a "third-party" key like on x86_64 (which wasn't enabled by default for example in my newest Thinkpad)? IIRC MS was treating SecureBoot on AArch64 different at one point, like I thought they were only including a key for their own use.
On Sun, 7 Sep 2025, Chris Adams via arm wrote:
Once upon a time, Dennis Gilmore dennis@ausil.us said:
Last I knew, we did not have hardware available to sign the secure-boot binaries at build time for AArch64. so we have not gone through the process to have Microsoft sign shim. The way that it works on x86_64 is that there are dedicated builders with smartcards installed that have the keys for signing. pesign Is used to do the signing. In order to sign the binaries on AArch64 we would need some builders set up the same way, and then we could sign grub, shim, and kernel. Then we would have shim signed by Microsoft and included in the shim-signed package. Today, the only way to enable secure boot is to sign the binaries yourself and enroll and trust the keys in the system.
What AArch64 hardware ships with SecureBoot and MS's keys in firmware?
I was trying to use it on KVM guests on a AArch64 host. So it was the AAVMF package providing the firmware. Thas the famouse "Microsoft Corporation Third Party Marketplace Root" key. Do you need more information?
Does that include a "third-party" key like on x86_64 (which wasn't enabled by default for example in my newest Thinkpad)? IIRC MS was treating SecureBoot on AArch64 different at one point, like I thought they were only including a key for their own use.
Once upon a time, Udo Seidel udoseidel@gmx.de said:
I was trying to use it on KVM guests on a AArch64 host. So it was the AAVMF package providing the firmware. Thas the famouse "Microsoft Corporation Third Party Marketplace Root" key. Do you need more information?
My point is that if there's no hardware shipping with that cert, and especially if that's not what MS considers the intended use of that cert (because at one point their rules were different between x86_64 and AArch64), they may not sign any code for that use. Even if Fedora did have the setup for signing the AArch64 pieces, MS may not sign shim.
If you need Secure Boot in your VMs, you'll probably have to add your own cert and do the signing yourself.
Thanks for your feedback
On Mon, 8 Sep 2025, Chris Adams via arm wrote:
Once upon a time, Udo Seidel udoseidel@gmx.de said:
I was trying to use it on KVM guests on a AArch64 host. So it was the AAVMF package providing the firmware. Thas the famouse "Microsoft Corporation Third Party Marketplace Root" key. Do you need more information?
My point is that if there's no hardware shipping with that cert, and especially if that's not what MS considers the intended use of that cert (because at one point their rules were different between x86_64 and AArch64), they may not sign any code for that use. Even if Fedora did have the setup for signing the AArch64 pieces, MS may not sign shim.
Understood. I can say that MS has signed shims for other AArch64 distributions. I tested Debian, Rocky Linux, Oracles OEL and SUSEs SLES as well as openSUSE. BTW, the RHEL shim is only signed by Red Hat and not co-signed by Microsoft. I figure now that the other Linux providers have set up those dedicated builders as described earlier in this thread and they want through the MS signing process.
If you need Secure Boot in your VMs, you'll probably have to add your own cert and do the signing yourself.
Understood.
Once upon a time, Udo Seidel udoseidel@gmx.de said:
I can say that MS has signed shims for other AArch64 distributions. I tested Debian, Rocky Linux, Oracles OEL and SUSEs SLES as well as openSUSE. BTW, the RHEL shim is only signed by Red Hat and not co-signed by Microsoft.
Okay, then that answers the "will MS do it" part. That's good to know. Then it's a matter of Fedora having time and resources to go through setting it all up and submitting shim (which is still a big hurdle).
Most (all? not sure) Fedora AArch64 supported hardware uses u-boot, which might be impractical to use with Secure Boot; I'd guess each image would have to be signed, and I don't know if there's even board firmware that implements a Secure Boot loader anyway (so it'd be mostly useless for those platforms).
On Mon, 8 Sept 2025 at 16:51, Chris Adams via arm arm@lists.fedoraproject.org wrote:
Once upon a time, Udo Seidel udoseidel@gmx.de said:
I can say that MS has signed shims for other AArch64 distributions. I tested Debian, Rocky Linux, Oracles OEL and SUSEs SLES as well as openSUSE. BTW, the RHEL shim is only signed by Red Hat and not co-signed by Microsoft.
Okay, then that answers the "will MS do it" part. That's good to know. Then it's a matter of Fedora having time and resources to go through setting it all up and submitting shim (which is still a big hurdle).
They have been signing shim for some time, there was some requirements around some security requirements but they were fixed well over 2 years ago.
Most (all? not sure) Fedora AArch64 supported hardware uses u-boot,
No, that's incorrect, there's a LOT of enterprise hardware that doesn't and has secure boot enabled and ready to go, as does Jetson hardware and a number of other options.
which might be impractical to use with Secure Boot; I'd guess each image would have to be signed, and I don't know if there's even board firmware that implements a Secure Boot loader anyway (so it'd be mostly useless for those platforms).
U-Boot upstream has supported UEFI secure boot for a while. I've been meaning on looking into it and enrolling the Fedora keys into our builds so it's there across all our officially supported devices.
Once upon a time, Peter Robinson pbrobinson@gmail.com said:
U-Boot upstream has supported UEFI secure boot for a while. I've been meaning on looking into it and enrolling the Fedora keys into our builds so it's there across all our officially supported devices.
I saw the U-Boot supports Secure Boot, but... does that add any security in the typical Fedora setup, where U-Boot is on the same storage as shim, grub2, and the kernel? I would think you'd only gain security from U-Boot's Secure Boot support if U-Boot itself was in firmware that can't be modified (at least easily) from Linux.
On Tuesday, 09 September 2025 at 14:26, Chris Adams via arm wrote: [...]
I saw the U-Boot supports Secure Boot, but... does that add any security in the typical Fedora setup, where U-Boot is on the same storage as shim, grub2, and the kernel? I would think you'd only gain security from U-Boot's Secure Boot support if U-Boot itself was in firmware that can't be modified (at least easily) from Linux.
Fedora on PineBook Pro kind of requires U-Boot to be stored in the SPI. As for easy modification, does SecureBoot block writes to /dev/mtd0?
Regards, Dominik
On Wed, 10 Sept 2025 at 09:40, Dominik 'Rathann' Mierzejewski via arm arm@lists.fedoraproject.org wrote:
On Tuesday, 09 September 2025 at 14:26, Chris Adams via arm wrote: [...]
I saw the U-Boot supports Secure Boot, but... does that add any security in the typical Fedora setup, where U-Boot is on the same storage as shim, grub2, and the kernel? I would think you'd only gain security from U-Boot's Secure Boot support if U-Boot itself was in firmware that can't be modified (at least easily) from Linux.
Fedora on PineBook Pro kind of requires U-Boot to be stored in the SPI. As for easy modification, does SecureBoot block writes to /dev/mtd0?
No, Secureboot doesn't write to anywhere, it reads the next phase in the boot process, checks it's signed by the right keys and hasn't been modified.
In a fully secure firmware stack, which isn't completely related to secure boot, aarch64 has a pretty well defined way with "Boot Loader Stage X assignments AKA BLX" you have the following flow:
1) In chip bootROM (BL1) oads SPL (Secondary Boot Loader) verifying the SPL using the keys stored in chip OTP 2) SPL (BL2) initialises DRAM and loads third stage firmware (BL3 inc BL31/BL32) including TF-A, TEE, quite often SCP 3) TF-A loads system firmware BL33 (U-Boot/EDK2) which often initialises display, clocks, various other HW needed in the early boot process 4) BL33 loads the OS, which in our case we use UEFI and that may implement secure boot
To have a fully secure firmware stack, protected from the OS, the SPI flash like on the Pinebook Pro, shouldn't be accessible from Linux and the update process should be through something like UEFI Capsule update. The problem is that restricting access to something like an SPI bus is complex, especially on cheap SoCs where there's not a dedicated secure co-processor.
UEFI Capsule updates is also a thing that U-Boot now supports and I'm looking at how I can generate capsules so we can enable people to do automated updates to firmware using fwupdmgr so people don't need to manually update FW through some pre OS cli.
On Wednesday, 10 September 2025 at 11:26, Peter Robinson via arm wrote:
On Wed, 10 Sept 2025 at 09:40, Dominik 'Rathann' Mierzejewski via arm arm@lists.fedoraproject.org wrote:
[...]
Fedora on PineBook Pro kind of requires U-Boot to be stored in the SPI. As for easy modification, does SecureBoot block writes to /dev/mtd0?
No, Secureboot doesn't write to anywhere, it reads the next phase in the boot process, checks it's signed by the right keys and hasn't been modified.
I never said SecureBoot writes anywhere. I asked if the kernel prevents the OS from writing to SPI if SecureBoot is active.
Thanks for the detailed description of the stack.
Regards, Dominik
On Thu, 11 Sept 2025 at 21:24, Dominik 'Rathann' Mierzejewski via arm arm@lists.fedoraproject.org wrote:
On Wednesday, 10 September 2025 at 11:26, Peter Robinson via arm wrote:
On Wed, 10 Sept 2025 at 09:40, Dominik 'Rathann' Mierzejewski via arm arm@lists.fedoraproject.org wrote:
[...]
Fedora on PineBook Pro kind of requires U-Boot to be stored in the SPI. As for easy modification, does SecureBoot block writes to /dev/mtd0?
No, Secureboot doesn't write to anywhere, it reads the next phase in the boot process, checks it's signed by the right keys and hasn't been modified.
I never said SecureBoot writes anywhere. I asked if the kernel prevents the OS from writing to SPI if SecureBoot is active.
Why would it? That's not what secure boot does, it purely verifies the next stage of the boot process.
On Friday, 12 September 2025 at 09:46, Peter Robinson via arm wrote:
On Thu, 11 Sept 2025 at 21:24, Dominik 'Rathann' Mierzejewski via arm arm@lists.fedoraproject.org wrote:
On Wednesday, 10 September 2025 at 11:26, Peter Robinson via arm wrote:
On Wed, 10 Sept 2025 at 09:40, Dominik 'Rathann' Mierzejewski via arm arm@lists.fedoraproject.org wrote:
[...]
Fedora on PineBook Pro kind of requires U-Boot to be stored in the SPI. As for easy modification, does SecureBoot block writes to /dev/mtd0?
No, Secureboot doesn't write to anywhere, it reads the next phase in the boot process, checks it's signed by the right keys and hasn't been modified.
I never said SecureBoot writes anywhere. I asked if the kernel prevents the OS from writing to SPI if SecureBoot is active.
Why would it? That's not what secure boot does, it purely verifies the next stage of the boot process.
I guess I confused myself when thinking about kernel_lockdown.
Regards, Dominik
On Fri, Sep 12, 2025 at 08:46:18AM +0100, Peter Robinson via arm wrote:
On Thu, 11 Sept 2025 at 21:24, Dominik 'Rathann' Mierzejewski via arm arm@lists.fedoraproject.org wrote:
I never said SecureBoot writes anywhere. I asked if the kernel prevents the OS from writing to SPI if SecureBoot is active.
Why would it? That's not what secure boot does, it purely verifies the next stage of the boot process.
Yes, but for that being still the case on the next boot you want make sure nobody goes replace your firmware with another version which skips the secure boot verification. Likewise the EFI variable storage must be protected to make sure nobody tampers with the certificate databases.
take care, Gerd
Once upon a time, Peter Robinson pbrobinson@gmail.com said:
U-Boot upstream has supported UEFI secure boot for a while. I've been meaning on looking into it and enrolling the Fedora keys into our builds so it's there across all our officially supported devices.
I saw the U-Boot supports Secure Boot, but... does that add any security in the typical Fedora setup, where U-Boot is on the same storage as shim, grub2, and the kernel? I would think you'd only gain security from U-Boot's Secure Boot support if U-Boot itself was in firmware that can't be modified (at least easily) from Linux.
Without further changes, no it doesn't, a lot of the U-Boot we build now actually can go on SPI flash so in a lot of cases it's not the same storage.
Of course to properly do fully secure boot chain you'd need to fully sign the firmware stack, most U-Boot builds these day for aarch64 are a collection of 3-4 firmware, and then of course burn those keys into a OTP on the chip at which point you'd have that full stack.
So no it doesn't provide that full level of security because without that process you don't get a fully authenticated boot flow that has each step verify the next one, but it's possible and I think it's useful to be able to demonstrate that. I'm also working with some vendors to actually implement that full stack.
Peter
Hi Denis,
On Sun, 7 Sep 2025, Dennis Gilmore wrote:
Last I knew, we did not have hardware available to sign the
...
to sign the binaries yourself and enroll and trust the keys in the system.
ah - thanks for the clarification. That also explains why other Linux distribution - even RHEL-based - come with MS signed SHIM. Thanks, Udo
Dennis
On Sun, Sep 7, 2025 at 4:40 AM Udo Seidel via arm arm@lists.fedoraproject.org wrote:
Hi there, any hints on this topic? Cheers, Udo
On Sun, 31 Aug 2025, Udo Seidel wrote:
Dear all, I failed to find the answer myself. :-( It seems to me that the AARCH64 version of Fedora is not enabled for UEFI Secure Boot like the x86_64 version. I.e., the shim EFI binary is not signed and neither is the kernel (see below). What am I missing? What am I doing wrong? Background: I want to use AARCH64 Fedora in a UEFI Secure Boot environment with the the pre-deployed keys from Microsoft. Thanks, Udo
AARCH64
# uname -r 6.15.10-200.fc42.aarch64 # sbverify --list /boot/efi/EFI/fedora/shimaa64.efi warning: data remaining[830464 vs 971654]: gaps between PE/COFF sections? warning: data remaining[830464 vs 971656]: gaps between PE/COFF sections? No signature table present # sbverify --list /boot/vmlinuz-6.15.10-200.fc42.aarch64 No signature table present #
X86_64
# uname -r 6.15.7-200.fc42.x86_64 root@ronin:~# sbverify --list /boot/efi/EFI/fedora/shimx64.efi warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections? signature 1 image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
Corporation UEFI CA 2011 image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root # sbverify --list /boot/vmlinuz-6.15.9-201.fc42.x86_64 signature 1 image signature issuers:
- /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot
CA 20200709/CN=fedoraca image signature certificates:
- subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora
Secure Boot Signer/OU=bkernel01 kernel/CN=kernel-signer issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca #
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sun, Sep 07, 2025 at 07:28:38PM -0500, Dennis Gilmore via arm wrote:
Hi,
Last I knew, we did not have hardware available to sign the secure-boot binaries at build time for AArch64. so we have not gone through the process to have Microsoft sign shim. The way that it works on x86_64 is that there are dedicated builders with smartcards installed that have the keys for signing. pesign Is used to do the signing. In order to sign the binaries on AArch64 we would need some builders set up the same way, and then we could sign grub, shim, and kernel. Then we would have shim signed by Microsoft and included in the shim-signed package. Today, the only way to enable secure boot is to sign the binaries yourself and enroll and trust the keys in the system.
Yep. Additionally, there is some progress on this. We have a new hardware setup (that we have not yet switched to) that should allow us to sign on aarch64. It uses a small application to gateway that signing request back to our sign vault which signs it. Switching to that is on my list, currently 2 places from the top. I'm hoping to get that done after Beta goes out and we are out of beta freeze.
There's also a new shim version coming up, and hopefully we can get that signed by MS at the same time they do so for x86.
Additionally, there were also some issues with the fedora kernel and it's secure-boot lockdown patch that didn't work right, but I think thats since been fixed. Also, it breaks kexec, and I am not sure where that is at, but it's not a blocker I don't think.
So anyhow, slow (sometimes very slow) progress is being made. --
Dennis
On Sun, Sep 7, 2025 at 4:40 AM Udo Seidel via arm arm@lists.fedoraproject.org wrote:
Hi there, any hints on this topic? Cheers, Udo
On Sun, 31 Aug 2025, Udo Seidel wrote:
Dear all, I failed to find the answer myself. :-( It seems to me that the AARCH64 version of Fedora is not enabled for UEFI Secure Boot like the x86_64 version. I.e., the shim EFI binary is not signed and neither is the kernel (see below). What am I missing? What am I doing wrong? Background: I want to use AARCH64 Fedora in a UEFI Secure Boot environment with the the pre-deployed keys from Microsoft. Thanks, Udo
AARCH64
# uname -r 6.15.10-200.fc42.aarch64 # sbverify --list /boot/efi/EFI/fedora/shimaa64.efi warning: data remaining[830464 vs 971654]: gaps between PE/COFF sections? warning: data remaining[830464 vs 971656]: gaps between PE/COFF sections? No signature table present # sbverify --list /boot/vmlinuz-6.15.10-200.fc42.aarch64 No signature table present #
X86_64
# uname -r 6.15.7-200.fc42.x86_64 root@ronin:~# sbverify --list /boot/efi/EFI/fedora/shimx64.efi warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections? signature 1 image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
Corporation UEFI CA 2011 image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root # sbverify --list /boot/vmlinuz-6.15.9-201.fc42.x86_64 signature 1 image signature issuers:
- /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot
CA 20200709/CN=fedoraca image signature certificates:
- subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora
Secure Boot Signer/OU=bkernel01 kernel/CN=kernel-signer issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca #
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, 8 Sep 2025, Kevin Fenzi wrote:
On Sun, Sep 07, 2025 at 07:28:38PM -0500, Dennis Gilmore via arm wrote:
Last I knew, we did not have hardware available to sign the secure-boot binaries at build time for AArch64. so we have not gone
...
to sign the binaries yourself and enroll and trust the keys in the system.
Yep. Additionally, there is some progress on this. We have a new hardware setup (that we have not yet switched to) that should allow us to sign on aarch64. It uses a small application to gateway that signing request back to our sign vault which signs it. Switching to that is on my list, currently 2 places from the top. I'm hoping to get that done after Beta goes out and we are out of beta freeze.
There's also a new shim version coming up, and hopefully we can get that signed by MS at the same time they do so for x86.
Additionally, there were also some issues with the fedora kernel and it's secure-boot lockdown patch that didn't work right, but I think thats since been fixed. Also, it breaks kexec, and I am not sure where that is at, but it's not a blocker I don't think.
So anyhow, slow (sometimes very slow) progress is being made.
Ah .. lots of good news. Good to know what is going on behind the scenes and why are where they are the moment. On top of the KVM guests I can also test that - once it is out - on Raspberry Pi 3/4 where it is possible to chainload UEFI by u-boot. https://github.com/useidel/uefiboot4rpi
Cheers, Udo
On Mon, 8 Sept 2025 at 17:28, Kevin Fenzi via arm arm@lists.fedoraproject.org wrote:
On Sun, Sep 07, 2025 at 07:28:38PM -0500, Dennis Gilmore via arm wrote:
Hi,
Last I knew, we did not have hardware available to sign the secure-boot binaries at build time for AArch64. so we have not gone through the process to have Microsoft sign shim. The way that it works on x86_64 is that there are dedicated builders with smartcards installed that have the keys for signing. pesign Is used to do the signing. In order to sign the binaries on AArch64 we would need some builders set up the same way, and then we could sign grub, shim, and kernel. Then we would have shim signed by Microsoft and included in the shim-signed package. Today, the only way to enable secure boot is to sign the binaries yourself and enroll and trust the keys in the system.
Yep. Additionally, there is some progress on this. We have a new hardware setup (that we have not yet switched to) that should allow us to sign on aarch64. It uses a small application to gateway that signing request back to our sign vault which signs it. Switching to that is on my list, currently 2 places from the top. I'm hoping to get that done after Beta goes out and we are out of beta freeze.
There's also a new shim version coming up, and hopefully we can get that signed by MS at the same time they do so for x86.
Additionally, there were also some issues with the fedora kernel and it's secure-boot lockdown patch that didn't work right, but I think
I believe that's all now resolved. So we need to get the Fedora signing stuff in place and then sign shim and we're done. \o/
thats since been fixed. Also, it breaks kexec, and I am not sure where that is at, but it's not a blocker I don't think.
So anyhow, slow (sometimes very slow) progress is being made.
Dennis
On Sun, Sep 7, 2025 at 4:40 AM Udo Seidel via arm arm@lists.fedoraproject.org wrote:
Hi there, any hints on this topic? Cheers, Udo
On Sun, 31 Aug 2025, Udo Seidel wrote:
Dear all, I failed to find the answer myself. :-( It seems to me that the AARCH64 version of Fedora is not enabled for UEFI Secure Boot like the x86_64 version. I.e., the shim EFI binary is not signed and neither is the kernel (see below). What am I missing? What am I doing wrong? Background: I want to use AARCH64 Fedora in a UEFI Secure Boot environment with the the pre-deployed keys from Microsoft. Thanks, Udo
AARCH64
# uname -r 6.15.10-200.fc42.aarch64 # sbverify --list /boot/efi/EFI/fedora/shimaa64.efi warning: data remaining[830464 vs 971654]: gaps between PE/COFF sections? warning: data remaining[830464 vs 971656]: gaps between PE/COFF sections? No signature table present # sbverify --list /boot/vmlinuz-6.15.10-200.fc42.aarch64 No signature table present #
X86_64
# uname -r 6.15.7-200.fc42.x86_64 root@ronin:~# sbverify --list /boot/efi/EFI/fedora/shimx64.efi warning: data remaining[823272 vs 949424]: gaps between PE/COFF sections? signature 1 image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft
Corporation UEFI CA 2011 image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft
Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root # sbverify --list /boot/vmlinuz-6.15.9-201.fc42.x86_64 signature 1 image signature issuers:
- /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot
CA 20200709/CN=fedoraca image signature certificates:
- subject: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora
Secure Boot Signer/OU=bkernel01 kernel/CN=kernel-signer issuer: /C=US/ST=Massachusetts/L=Cambridge/O=Red Hat, Inc./OU=Fedora Secure Boot CA 20200709/CN=fedoraca #
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-
Chris Adams -
Dennis Gilmore -
Dominik 'Rathann' Mierzejewski -
Gerd Hoffmann -
Kevin Fenzi -
Peter Robinson -
Udo Seidel