Arm devices are everywhere today and many of them run Linux. The operating system also powers cloud computing and IT environments all over the world. However, x86 is still the dominant architecture of global computer hardware, where the Unified Extensible Firmware Interface (UEFI) with Secure Boot incorporated is a standard. But what does UEFI look like from an Arm perspective?
As a quick reminder: UEFI was initially developed by Intel as a firmware for its Itanium-based high-end datacenter computers. That was in the late ’90s and early 2000s, when it was simply called EFI (Extensible Firmware Interface). In 2005, Intel handed its development over to the Unified EFI forum. Around that time the first open source implementation of UEFI – called Tiano – was released as well. A few years later it was clear the traditional BIOS (Basic Input/Output System) would be superseded by the new firmware technology.
UEFI addresses some scalability challenges – e.g. large disks – as well as security concerns. And this is where Secure Boot comes into the picture. But this evolutionary step went mostly unnoticed until late 2011, when Microsoft announced that Windows 8 hardware certification would require UEFI and Secure Boot. That announcement caused concern and passionate discussion in the Linux community. Why? It soon transpired that Linux wouldn’t boot on those devices by default. And it looked like major efforts and lobby work would be needed to overcome this challenge.
(A quick side-note: this whole discussion was very much focused on x86. Nobody really mentioned Arm. This is not really a surprise because that hardware platform did not play a role in the universe of Windows and Linux at the time.)
But back to x86. Very soon there was a working solution, and it was not only adopted by the different Linux vendors and the community but was also supported by Microsoft. The trick was a little EFI binary called shim, which is signed by Microsoft. Having the seal of approval from the Windows-maker meant UEFI would happily execute it when Secure Boot was enabled. Shim opened a door to securely introduce other certificates and signatures into the firmware. Those requiring more granular control or inclusion of more of their own code could enroll Machine Owner Keys (MOK) into the UEFI Secure Boot process. This allows you to extend the Secure Boot chain to load their custom boot loader or an operating system kernel which was not properly signed to a specific machine. This setup has worked well for quite some time in the x86 world and is used by Ubuntu, Fedora, and openSUSE, among others. The major Linux distributions – both enterprise and community – come with shim, which is signed by Microsoft. During the installation a certificate that is used to sign the boot-loader, the kernel, and its modules, is added to UEFI. Trusting the hardware and the firmware and enabling Secure Boot will allow Linux to start up as usual. The user will not notice a difference.
UEFI Secure Boot for Linux on x86 is not exotic anymore – click to enlarge
Strong Arm tactics
The enormous success of devices like the Raspberry Pi and its single board computer clones has massively increased the adoption of the hardware platform in recent years. Unsurprisingly, the same is true of Linux installations on Arm. These days everybody talks about AARCH64, or Arm64, which is the 64-bit version of Arm. While the 32-bit variants are officially supported as per UEFI specification, they really don’t play a role.
The whole topic has two different aspects. Number one is considering what kind of UEFI functions are provided with the shipped hardware. The second one has to do with how Linux deals with it. Let’s look at the hardware part first.
While the core UEFI specification is architecture-independent, its implementation on Arm-based devices differs.
The Arm world works differently than the x86 one. Instead of just a few there are dozens of chip manufacturers. Remember the company Arm itself just releases specifications for chip designs. The actual plumbing of that in a chip is done by others. As a result of that diversity of hardware there is no homogeneous picture of the firmware. Each chip vendor normally produces their own firmware, and often enough it is not replaceable / compatible with something else. And even worse, it is not UEFI, which would potentially mean no Secure Boot. But hold on. There is some common ground: the de-facto standard of the boot-loader for Linux on those Arm devices. This piece of software, called u-boot, does provide compliance with the UEFI specifications and allows Secure Boot. However, there are two main things to consider when going down that path. Firstly, u-boot itself does not come with any pre-deployed certificates and keys. That is a huge difference from what happens in the x86 world. There, one can expect that at least the Microsoft ones are available with the firmware installed.
To clarify, u-boot itself is not firmware. The vendor firmware is stored on chips on the board. And then this firmware loads u-boot, which is stored on an external drive, for example a USB or an SD-card. U-boot then provides a standard and loads Linux. (Side-note: Linux in that context could be another bootloader like grub2 but the standard is that u-boot loads the Linux kernel and associated files directly.)
To enable Secure Boot with u-boot you need to create and deploy your own certificates and keys. That is a bit cumbersome because there is no GUI for that and it’s obviously very specific to this boot-loader. Additionally, the user also needs to sign whatever is loaded by u-boot. You could do it by way of the Linux kernel and its modules itself, or via a secondary/chained bootloader like grub2. The latter is the preferred solution because that would also enable the Linux distribution specific certificates and keys and hence, meaning you expend a bit less effort.
But there is also another, different option. Startup via u-boot consists of several phases and it is possible to sneak in a switch to UEFI. The challenge here is not the implementation of that startup sequence deviation – it is the availability of that hardware specific UEFI implementation. There are working examples for the Raspberry Pi 3 and 4 and also for some other Arm-based devices. The so-called RK3588 chips especially look very promising. The benefit of this approach is the almost same user experience known from the x86 world. The UEFI GUI is intuitive and close enough to what the user already knows from PCs. In a nutshell: the UEFI support on Arm is not as great as in the x86 world. If you are lucky, you own hardware where chain-loading as described above is possible. Apart from that: the hope is on the u-boot implementation of UEFI and Secure Boot.
And does the user gain anything from having Secure Boot support in u-boot? Well, as with UEFI, only properly signed binaries are executed.
There are still a few differences on how the Linux1 distributors/communities handle the shim signing on Arm64. Having it signed by Microsoft is the common ground – though some still have some homework to do – click to enlarge for a better look
The software side of life
What does it look like from the Linux operating system point of view?
Given the nature of UEFI Secure Boot on the x86 side, one would not expect any surprises. The technology, the source code, the processes – they are independent of the hardware platform. Hence, whatever works in the x86 world should/will work as well on the Arm side. Reality tells that this is true for Debian, Canonical/Ubuntu and SUSE part of the house. That means the corresponding distributions – community and Enterprise – simply install with Arm with UEFI Secure Boot enabled and Microsoft keys/certificates pre-deployed. However, those working within the Red Hat universe can get quite different and surprising results. The community variant Fedora comes with a shim which has not been signed. Consequently, the installation will not work out of the box. On the RHEL (Red Hat Enterprise Linux) side the surprise is even bigger. The shim is signed but not with a Microsoft certificate/key. Instead, a Red Hat one is used. In both cases the best way forward is to install Linux with disabled Secure Boot. Afterwards the user can create and deploy their own certificates and keys and make either the shim or the grub2 binary trustworthy for UEFI. Interesting enough, CentOS Stream and Alma Linux – both based on Red Hat code – are better prepared. They come with a Microsoft-signed shim. Based on discussions on the relevant mailing lists there is hope that at least Fedora will work out of the box soon.
What is the final conclusion? With all the experience and knowledge from the x86 side, the Linux community is well prepared to implement UEFI Secure Boot on the Arm platform. As noted above, there is a slight chance for a few teething issues, but in general it looks great.
The challenging part is on the hardware/firmware side. It cannot be expected that UEFI is part of the shipped Arm device. It can be integrated afterwards, but not always, and with limited options. The best hope is based on the bootloader u-boot either standalone or chain-loading hardware specific UEFI implementations which are based on the EDKII project. ®
Some additional resources
The UEFI spec [PDF]
Some guidance and commands for a harmless switch from the traditional u-boot based setup for Raspberry Pi OS to an UEFI one (including Grub) by this author.