UEFI Secure Boot on Arm64 is usable today but fragmented: the essential pieces exist, many mainstream distributions already support it, and a growing set of EDK II UEFI firmware ports make an x86‑like Secure Boot experience possible — yet the practical reality for users and enterprises remains uneven because firmware implementations, key management and distribution signing practices differ widely across SoCs, boards and Linux vendors.
UEFI Secure Boot was designed as an architecture‑agnostic mechanism to ensure only cryptographically signed, trusted code runs during early boot. On x86 machines this model is now largely invisible to most users because firmware commonly ships with Microsoft’s Secure Boot keys, and major Linux distributions solve the compatibility problem by installing a small, Microsoft‑signed shim that vouches for downstream bootloaders and kernels. On Arm64 the building blocks are the same — UEFI, EDK II, shim, GRUB, signed kernels — but the ecosystem is not as uniform: many Arm vendors ship custom firmware (or no replaceable UEFI at all), u‑boot remains the de‑facto bootloader in embedded designs, and distributions differ in whether their boot binaries for Arm64 are Microsoft‑signed and ready to boot with Secure Boot enabled. (documentation.ubuntu.com)
Red Hat’s situation is nuanced. Red Hat documentation states shim x86 is signed with Microsoft’s UEFI CA to ensure boot on platforms with default Microsoft keys; Red Hat then extends trust by adding its own Secure Boot CA for UKIs and kernels. However, some RHEL/arm users and RHEL‑derived distributions may see varying signing configurations on arm64 artifacts. There are community reports that certain RHEL arm shims were not co‑signed by Microsoft in the same way as x86 packages, which means installation with Secure Boot enabled on some arm64 boards may require extra steps (disable Secure Boot, enroll keys, or sign locally). CentOS Stream and AlmaLinux have in practice shipped Microsoft‑signed shims in many builds, giving those RHEL‑compatible images a more plug‑and‑play experience on some hardware. Given distribution and architecture differences this area is worth close checking per distro/version. (docs.redhat.com)
For enthusiasts and small deployments: use boards with community EDK II ports, be prepared to enroll keys manually, and test your chosen distribution’s shim packaging before relying on Secure Boot.
For ISVs and enterprise teams: build a signing pipeline, negotiate firmware management and update SLAs with board/SoC vendors, and treat Secure Boot on Arm as both a security enhancement and an integration project that requires coordination across silicon, firmware and OS vendors.
If the goal is to get the most seamless, PC‑like Secure Boot experience on Arm64 today, prefer platforms with vendor‑supported EDK II firmware (RK3588 class and some Raspberry Pi EDK II images) and distributions that ship Microsoft‑signed arm64 shim binaries — but always validate the exact shim signatures and firmware key state on targeted devices before wide deployment. (github.com)
Source: theregister.com UEFI Secure Boot for Linux Arm64 – where do we stand?
Background
UEFI Secure Boot was designed as an architecture‑agnostic mechanism to ensure only cryptographically signed, trusted code runs during early boot. On x86 machines this model is now largely invisible to most users because firmware commonly ships with Microsoft’s Secure Boot keys, and major Linux distributions solve the compatibility problem by installing a small, Microsoft‑signed shim that vouches for downstream bootloaders and kernels. On Arm64 the building blocks are the same — UEFI, EDK II, shim, GRUB, signed kernels — but the ecosystem is not as uniform: many Arm vendors ship custom firmware (or no replaceable UEFI at all), u‑boot remains the de‑facto bootloader in embedded designs, and distributions differ in whether their boot binaries for Arm64 are Microsoft‑signed and ready to boot with Secure Boot enabled. (documentation.ubuntu.com)Where the hardware and firmware stand
The Arm diversity problem
Arm is a design‑license business: Arm Holdings publishes CPU designs, and dozens of silicon vendors (Qualcomm, Rockchip, Broadcom, NXP, Samsung, MediaTek and many smaller vendors) build SoCs and platform firmware around those cores. That leads to two practical outcomes:- Many Arm boards ship with vendor‑specific, closed firmware rather than a standard, replaceable UEFI implementation.
- Even where UEFI is present, vendors do not always provision the same PK/KEK/db keyset in NVRAM; Microsoft keys are frequent on x86 consumer hardware but are not guaranteed on Arm devices. (docs.u-boot.org)
Growing UEFI support: EDK II ports and RK3588
The good news is there’s active work to bring EDK II‑based UEFI firmware to Arm boards. Projects such as the edk2‑porting effort for RK3588 show a mature, EDK II firmware image that aims to give RK3588‑class boards a full UEFI experience (ACPI + Device Tree support, network, PCIe, display and Secure Boot hooks). Where these firmwares are deployed, the user experience approaches what PC users expect: a UEFI GUI, standard variables, and easier key management. The RK3588 EDK II port explicitly targets mainline Linux compatibility and documents platform tiers that let users boot Fedora and Ubuntu AArch64 images with the UEFI path. (github.com)Raspberry Pi and the UEFI option
Raspberry Pi boards historically boot via vendor firmware into U‑boot or directly into kernel images. Community UEFI projects for the Pi 3/4 (and related initiatives) produce EDK II images that can be flashed to SD cards so the board behaves more like a PC for boot management and Secure Boot testing. These community UEFI builds are widely used by enthusiasts and are a practical stopgap for those seeking a familiar UEFI GUI and Secure Boot flow on Pi hardware. (github.com)u‑boot: the de‑facto bootloader and Secure Boot’s practicalities
u‑boot provides UEFI services but not keys
In much of the Arm embedded world, the firmware chain looks like: vendor ROM/firmware → u‑boot (on eMMC/SD) → kernel or a chained UEFI payload. Modern u‑boot can implement the UEFI interfaces, host EFI applications (grubaa64.efi, shim) and support UEFI Secure Boot enforcement. U‑boot’s documentation explains how to enable UEFI features and how to configure Secure Boot — but it does not ship with the manufacturer‑level keys filled in; key management is left to the integrator or end user. That means system integrators must create and provision Platform/KEK/db keys and sign boot binaries themselves unless the vendor chooses to ship or flash keys. (docs.u-boot.org)- In short: u‑boot has the technical capability to enforce Secure Boot, but the operational burden (key creation, enrollment, signing and update) falls on the platform integrator. (docs.u-boot.org)
Two practical approaches to Secure Boot on Arm
- Use u‑boot’s Secure Boot mode:
- Create keys (PK/KEK/db/dbx).
- Enroll them into the system (eficonfig/efivar or vendor tools).
- Sign boot binaries (shim/grub/kernel) and distribute the signed artifacts.
- This is flexible but requires tooling and per‑device enrollment.
- Chain‑load a hardware‑specific EDK II UEFI image:
- Some platforms (e.g., RK3588 mainline images, Pi UEFI ports) provide a TianoCore/EDK II UEFI implementation.
- That implementation can ship with a set of firmware keys or a process for enrolling keys and makes the user experience similar to x86 PCs (GUI, standard variable handling).
- This is the most user‑friendly option when available. (github.com)
How distributions handle Arm64 Secure Boot today
Signing policies and practices vary across distributions, and that directly shapes a user’s out‑of‑the‑box experience.Ubuntu & Debian: generally “works” on arm64
Ubuntu’s Secure Boot docs state that arm64 builds of shim and signed GRUB exist and are packaged as shim‑signed and grub‑efi‑arm64‑signed. In practice, Ubuntu engineers have pursued Microsoft signing of arm64 shims so images can boot on firmware that recognizes Microsoft keys; Ubuntu’s documentation and build process reflect that end‑to‑end effort. Debian follows similar pragmatic approaches. For users running Ubuntu server/desktop on boards with firmware that contains Microsoft keys (or when the vendor’s EDK II image is used), the experience is familiar: Secure Boot on, boot proceeds. (documentation.ubuntu.com)SUSE, openSUSE: similar readiness
SUSE/openSUSE and other Debian‑family distributions have also invested in shim and signing workflows for arm64, enabling secure‑bootable images where the firmware supports it. Community and enterprise SUSE variants are present among Arm‑targeted releases that accept Microsoft‑signed shims. (Upstream and distribution pages reflect these efforts and shipping packages.) (documentation.ubuntu.com)Fedora and CentOS / RHEL family: mixed picture
Fedora’s x86 offering long ago standardized on a Microsoft‑signed shim. On Arm64, multiple community threads and mailing list discussions show that Fedora historically lacked a build infrastructure to produce Microsoft‑signed arm64 shim binaries at scale; the net result is that Fedora arm64 can be more work to get booting under Secure Boot than its x86 sibling. Fedora maintainers have reported efforts to add arm64 signing infrastructure, but the situation has been uneven and has required manual key enrollment in many cases. (spinics.net)Red Hat’s situation is nuanced. Red Hat documentation states shim x86 is signed with Microsoft’s UEFI CA to ensure boot on platforms with default Microsoft keys; Red Hat then extends trust by adding its own Secure Boot CA for UKIs and kernels. However, some RHEL/arm users and RHEL‑derived distributions may see varying signing configurations on arm64 artifacts. There are community reports that certain RHEL arm shims were not co‑signed by Microsoft in the same way as x86 packages, which means installation with Secure Boot enabled on some arm64 boards may require extra steps (disable Secure Boot, enroll keys, or sign locally). CentOS Stream and AlmaLinux have in practice shipped Microsoft‑signed shims in many builds, giving those RHEL‑compatible images a more plug‑and‑play experience on some hardware. Given distribution and architecture differences this area is worth close checking per distro/version. (docs.redhat.com)
The bottom line on distribution readiness
- Ubuntu, Debian and many SUSE variants aim to provide Microsoft‑signed shims for arm64 so that Secure Boot “just works” on compatible firmware.
- Fedora historically required additional setup for arm64 Secure Boot and has been working to add signing infrastructure; users should confirm the current release notes for progress.
- RHEL’s documentation describes Microsoft‑signed shims for x86 and distribution‑specific signing for kernels; arm64 behavior can vary and may demand manual enrollment on some hardware. Where possible, check the exact shim package (e.g., shim‑aa64, shim‑signed) and its signatures on the target image before relying on out‑of‑the‑box Secure Boot. (documentation.ubuntu.com)
Security trade‑offs and risk analysis
Security benefits remain real
Secure Boot blocks unsigned or improperly signed bootloaders, kernels and drivers from loading during early boot. That dramatically raises the bar against bootkits, stealthy boot‑time rootkits and tampered system loaders. In environments where firmware keys are properly managed and the distribution’s signing chain is sound, Secure Boot remains an important piece of defense‑in‑depth. (documentation.ubuntu.com)Risk: firmware heterogeneity and key lifecycle
The protective power of Secure Boot depends on two operational items often out of the OS vendor’s control:- Whether firmware has the right keys (PK/KEK/db) or will accept updates to those key lists.
- Whether vendors keep key databases current in firmware over time.
Risk: signed‑but‑vulnerable software and SBAT
Secure Boot validates signatures, not semantics. A signed (but vulnerable) GRUB or shim may still allow a chain‑of‑trust bypass or expose vulnerabilities. Mechanisms like SBAT and dbx revocations exist to mitigate this by blacklisting known‑bad artifacts, but they require coordinated updates to firmware variable stores and OS‑level tooling. Some Windows firmware updates previously interacted poorly with Linux SBAT usage, creating real‑world compatibility headaches that illustrate the brittleness of a distributed signing/revocation ecosystem. (en.wikipedia.org)Operational cost
On many Arm boards, implementing Secure Boot is not a zero‑cost flip. Key generation, secure storage of private signing keys, integration of signing into the build pipeline, and the requirement to sign kernel modules (or adopt the SBAT/kernel‑UKI workflows) create nontrivial process and automation work for ISVs and enterprise teams. For embedded vendors, shipping firmware that supports standard UEFI variable storage (including tamper‑resistant RPMB/TEE storage) is essential but not universal. (github.com)Practical guidance for different audiences
For hobbyists and Raspberry Pi users
- If you want an x86‑like UEFI/Secure Boot experience, use community EDK II UEFI images for Pi 3/4 and boards that explicitly provide an EDK II port. That will expose the standard UEFI GUI and make it easier to experiment with shim/grub/signed kernels. Be prepared to enroll keys manually on many boards. (github.com)
For distribution packagers and integrators
- Maintain a signing infrastructure that can produce arm64 shim binaries and request Microsoft signing where you want broad compatibility. Document the signature chain and provide tools for users to verify and enroll keys.
- Automate SBAT/dbx workflows and coordinate with firmware vendors where possible; build tests against representative board types (u‑boot‑based and EDK II firmwares). Ubuntu and other distributions provide examples of packaging and shim update processes to emulate. (wiki.ubuntu.com)
For enterprises and cloud operators
- Inventory hardware: capture whether devices expose UEFI, whether Secure Boot is enabled, and which PK/KEK/db entries are present.
- For Arm servers (e.g., Cavium/Marvell/NVIDIA/Qualcomm based DPUs and blades), prefer platforms with vendor support for firmware updates and EDK II images; demand firmware key management and documented Secure Boot flows from vendors. NVIDIA BlueField, for example, documents Arm OS Secure Boot behavior for its DPUs. (docs.nvidia.com)
- Plan the operational overhead of signing, SBAT revocations and module signing — factor these into your release pipelines.
Short how‑to (high level) — enabling Secure Boot on an Arm board via u‑boot
- Confirm the firmware stack: is there EDK II firmware you can chain‑load, or do you boot directly with u‑boot?
- Build or obtain signing keys (PK/KEK/db). Use secure offline key generation tools and protect private keys.
- Sign shim/grub/kernel images using sbsign/pesign as appropriate.
- Enroll keys into firmware (eficonfig/efivar or vendor provisioning tools). If your hardware supports a TEE/RPMB variable store, use that for resistance to tampering.
- Test boot with Secure Boot enabled; verify signatures with sbverify and ensure SBAT/dbx rules are in sync.
- Automate signing in CI/CD and rotate keys per policy; provide a secure signing vault and a reproducible process for re‑provisioning images. (github.com)
What remains unresolved and where to watch
- Firmware key updates: the industry rollout of replacement Microsoft signing keys and whether vendors update firmware NVRAM in the field remains a risk vector for Linux boot continuity. Watch firmware update channels and distribution advisories closely around key expiry events. (tomshardware.com)
- Distribution signing parity on Arm: Fedora and some RHEL‑family artifacts have shown disparities on arm64 compared with x86; track distro release notes and arm‑specific signing packages (shim‑aa64, shim‑signed) before deploying Secure Boot broadly. (jfearn.fedorapeople.org)
- EDK II adoption across SoC vendors: as more ports (RK3588 and others) mature and become vendor‑supported, the friction around Secure Boot on Arm will fall. Monitor edk2‑porting projects and vendor announcements for platform‑level EDK II availability. (github.com)
Conclusion — pragmatic reality and strategic advice
The technical scaffolding for UEFI Secure Boot on Arm64 is in place: EDK II implementations exist and u‑boot supports UEFI Secure Boot enforcement. Major Linux distributions can and in many cases do provide Microsoft‑signed shims and signed kernels for arm64. However, the user experience is uneven because the real dependency is firmware — and Arm’s device diversity means firmware may not provide the same keyset, update path or management UI that x86 users have come to expect.For enthusiasts and small deployments: use boards with community EDK II ports, be prepared to enroll keys manually, and test your chosen distribution’s shim packaging before relying on Secure Boot.
For ISVs and enterprise teams: build a signing pipeline, negotiate firmware management and update SLAs with board/SoC vendors, and treat Secure Boot on Arm as both a security enhancement and an integration project that requires coordination across silicon, firmware and OS vendors.
If the goal is to get the most seamless, PC‑like Secure Boot experience on Arm64 today, prefer platforms with vendor‑supported EDK II firmware (RK3588 class and some Raspberry Pi EDK II images) and distributions that ship Microsoft‑signed arm64 shim binaries — but always validate the exact shim signatures and firmware key state on targeted devices before wide deployment. (github.com)
Source: theregister.com UEFI Secure Boot for Linux Arm64 – where do we stand?
