About seven years ago, a ticket was filed noting aarch64 systems were shipping with Secure Boot enabled, and that Fedora should start signing its boot path to support these devices out of the box.

I’m pleased to say that today’s Fedora Rawhide images - what will be Fedora 45 - finally does this thanks to the work of a whole bunch of people.

This means you can grab the latest Rawhide images and boot them on your favorite aarch64 laptop without turning off Secure Boot, or launch VMs in any of the major clouds with Secure Boot on. For example, I’m able to start a VM in Azure with the TrustedLaunch security type:

❯ az group create --name "jcline-aarch64-secureboot" --location "eastus2"
❯ az vm create --location eastus2 --name fedora \
  --resource-group jcline-aarch64-secureboot \
  --image /CommunityGalleries/Fedora-5e266ba4-2250-406d-adad-5d73860d958f/Images/Fedora-Cloud-Rawhide-Arm64/Versions/latest \
  --security-type TrustedLaunch \
  --size Standard_D2plds_v6 \
  --accept-term \
  --ssh-key-values @/home/jcline/.ssh/id_ed25519.pub
❯ ssh jcline@20.12.69.183
[jcline@fedora ~]$ mokutil --sb-state
SecureBoot enabled

Why Now?

The way Fedora used to sign UEFI applications for Secure Boot was delightfully simple (for some value of simple). The keys were in a smart card, plugged into a special build host, and anything that needed a signature was routed to be built on that host. pesign, one of the common utilities to sign PE applications, has a mode where it can run as a daemon and sign anything provided to it over a Unix socket. That Unix socket is threaded into the build environment, where builds can access it to sign PE applications with pesign-client.

Unfortunately, that host was x86_64 so when aarch64 started shipping with Secure Boot enabled, an alternative approach was needed.

Ultimately we moved the smart card to the signing server we use for RPMs and other things. The tricky bit about the whole process is that Fedora signs each bit of the boot chain during the build. Each time any of the UEFI applications in the boot chain is built it needs to be signed. One way to do this is to build the application in Fedora’s infrastructure, and then have a second build which uses the output of the first build along with a signature as input to construct a signed final version. However, this means you’ve got two specfiles which you have to keep in sync, and there’s probably other painful aspects I’ve not considered. In any case, that’s not what Fedora does.

Instead, Fedora signs the UEFI applications during the build. Since we want the signing key to be stored in a remote server, this implies some sort of networking, but builds aren’t permitted network access. Nor can the build environment provide the necessary secrets to authenticate with the signing service. In order to handle this, I wrote a small service that pretends to be the pesign Unix socket, and that can be exposed to the build environment in the same way. However, it just shovels anything it gets to the signing server and returns whatever the signing server does.

That service got deployed last week, and after a little bit of debugging it even worked. In fact, everything was signed for aarch64 last week, except for the fallback UEFI application that adds a boot entry for Fedora if it’s not there, which happens on first boot. Without that, booting new images would fail unless you explicitly added the correct Fedora boot entry manually. Yesterday, shim got rebuilt and everything works.

Stable When?

It’s possible this will eventually work in Fedora 44 Cloud images. Shim in Fedora 44 hasn’t (yet) been rebuilt and we’re in the final freeze for Fedora 44, so unfortunately we just missed it, but if it does get rebuilt later, Cloud images will be updated and will start working.

For Fedora 43 and older, the version of shim shipped doesn’t include the version signed for aarch64. I’m not sure it’s worth the risk to update it, as much as I’d like it to work there, as well.

Anyway, Fedora 45 will be upon us before you know it, and after seven years, six more months isn’t so bad, right?

Comments and Feedback

Thoughts, comments, or feedback greatly welcomed on Mastodon