UEFI Secure Boot for Linux Arm64 – where do we stand? 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 …
"I'm going to try the below out with my RPi 3 - thanks for this"
As the RPI 3 doesn't have (re)flashable firmware, unlike the RPI 4, 400, 5, 500, then you can use either u-boot or the UEFI port for RPI in which case you'd have the RPI 3's built-in bootloader loading the UEFI code to then boot Linux - so why bother rather than justing using the RPI's built-in bootloader alone?
If your answer is something like "so I can use a UEFI-based Linux distro" then that doesn't account for where the built-in bootloader's config files etc come from in the first place (if the "UEFI" distro provides them then it's not really a "pure" UEFI distro, if it doesn't provide then then you have to source them elsewhere).
Note: for RPI 4, 400, 5, 500 the referenced UEFI code *can* be flashed to replace the built-it bootloader, however last time I looked its support for RPIs built-in hardware was incomplete.
From the article:
"a harmless switch from the traditional u-boot based setup for Raspberry Pi OS"
I don't use Raspberry Pi OS myself but I'm surprised to hear that they apparently use u-boot chainloaded by the RPI's built-in bootloader rather than just using only the built-in bootloader.
Personally I've never used u-boot on a RPI, only the built-in bootloader.
> I don't use Raspberry Pi OS myself but I'm surprised to hear that they apparently use u-boot chainloaded by the RPI's built-in bootloader rather than just using only the built-in bootloader.
Your instinct is correct: RaspiOS doesn't use u-boot (I'm not entirely sure the article asserts this, but it does suggest u-boot is "traditional" on the Pi and that's certainly not my experience). To the best of my knowledge, RaspiOS has never used u-boot (going all the way back to wheezy). Ubuntu historically used u-boot on the Pi, but the last version that did so was focal (20.04).
They don't.
You can add your own UEFI keys and sign your own OS if you want. However PC's out of the box come with MS keys pre-installed, because basically 99% of use cases are running windows variants, and the effort of updating the BIOS values is beyond the technical capability of a majority of users. They just want something to work out of the box
It would also be possible for Rd Hat, SUSE etc to request motherboard manufacturers toi add their own keys, or all Linux distributions to come together and create a common key, but Linux does not work like that, so it has never been done, so they came up with the Shim idea, leveraging on the MS key
Also there is no reason why Linix distributors don't provide their own UEFI implementation, signed by MS key purely to add there own keys into an existion BIOS. Again no one has felt te need
Basically the reason MS has done it is their long standing deep relationships with motherboad manufacturers and they know who signs the checks.
"You can add your own UEFI keys and sign your own OS if you want."
Note that, depending on your hardware, you cannot rely upon only your own keys (i.e. deleting all the Microsoft UEFI keys) - some hardware such as graphics or storage devices may rely upon Option ROMs being loaded to be functional and such Option ROMs are typically signed by one of Microsoft's keys - remove all Microsoft UEFI keys and you may find your machine doesn't boot or boots but is not usable (i.e. graphics don't work). In particular these is an issue for built-in hardware (i.e. on laptops) rather than PCIe cards (which can be replaced).
In recent times when Microsoft created a newer set of UEFI keys they did split out a specific key/CA to be used only for signing Option ROMs but many motherboards likely don't have those recent keys and even if they're present any Option ROMs may still be signed by the older key(s).
What is the point you're trying to get at with that? Because there appear to be two problems with your implication, assuming you had a point at all:
1. That was a bug. It was fixed last year. Patch and that won't work.
2. The alternative is firmware with no verification at all, meaning I can do the same thing and not have any restrictions on it because there's no signature checking. Some people prefer that, but they don't pretend that it's safer.
Great article thanks, but some questions
So basically Linux provides a workaround to allow existing distributions to run on x86 platforms. How then does linux ensure that the OS installed can be trusted, if once the Shim is installed, basically it will run anything?
Similarly how does the Arm platform verify the installed OS.
With things like the Cyber Resiliancy Act coming in, it puts a lot more emphaisis on things like secure boot being available. How will Linux meet that challenge?
> if once the Shim is installed, basically it will run anything?
No. There is a chain of trust from UEFI -> shim -> bootloader (e.g. GRUB2) -> kernel / kernel modules
https://wiki.debian.org/SecureBoot#Shim
https://en.opensuse.org/openSUSE:UEFI#Implementation_in_openSUSE
By definition, no, because if you only have one key, hard-coded, then there are fewer opportunities for someone to sign something you don't want signed. However, is it enough less secure that you care given that, unless you built the board yourself, you won't control the key that's hard-coded into the board anyway. If you're designing your own hardware that must not run any software other than the thing you want it to, maybe this would be a reason not to use portable firmware, but for pretty much anything else, this is not a problem people really need to concern themselves with.
Apple absolutely are a problem too.
It's the power Microsoft and Apple take for themselves that is the issue. It's then puts us in the position of being reliant on their benevolence.
Microsoft is a convicted monopolies and Apple are just outright control freaks. For their users benefit of course.....
a) You are not crippling anything
b) what level of risk are you willing to accept that your PC is running a valid and unadulterated OS?
If you are joe blogs, and using it for a few games or writing documents, that mya not matter to you much. if you are a bank and you are accessing sensitive information, then you you may care a lot more
Bsaically it as about root of trust
The machine comes with BIOS installed at manufacturer. That verifies the boot loader can be trusted, that verifies the OS can be trusted. The OS then verifies the drivers and libraries. If the OS cannot be trusted, then In theory the libraries and drivers could be hacked, so your PC is pw0ned.
So again, is that desirable or not?
What? Something better than BIOS that was designed for 16-bit ral mode Intel CPUs? Secure boot to stop loading tampered files? A common system to load software on ARM devices just like Intel ones - without which probably the IBM; PC would have stayed a niche product, running IBM software only (just look at Apple..) and there would be no Linux?
For us at $placeofwork it's extremely desirable because the machines we build have by their nature massive safety implications*. Once they're out of the factory and in the hands of the customers we don't want people opening them up and playing around with the software in a way that might make them unsafe.** We're not there yet, but we're working toward a point where we have end-to-end trust chains. Our software (signed) will only run on our internal Linux distro (signed) which will only boot on hardware loaded with our firmware images (signed). The last thing we want is a massive lawsuit caused by someone messing about with one of these things and losing a limb or something because they managed to disable some of the safeguards and us not be able to prove that it wasn't a bug in our code that caused it.
Do you need this for your raspberry pi? Eh, no, probably not, but for industrial computing it's incredibly useful.
* We'll skip over what they're for, lets keep this suitably anonymous. Needless to say you could definitely kill yourself with one if you were sufficiently careless with it.
** I'm sure our legal and sales teams are also keen that people don't go around loading our software onto un-licenced 3rd party hardware too, but that's not really my concern.
I too don't understand the requirement for UEFI any more - to me it seems as obsolete as the BIOS.
Why is every damned system being designed as if it's a derivitive of the old IBM PC, having to load the equivalent to a bootloader to then load the OS into memory from storage seems lazy and somewhat myopic.
If you want security - with software set in stone - build your kit with a single use ROM containing the OS and standard RAM for the reset of the memory footprint. It worked for systems built in the 80s before the PC, why not now?!
If you want something a bit more flexible, so you can update the OS, then do the same as above, but with an additional flash based overlay that can cover the ROM address space post upgrade.
For those that say that ROMs are too small, it's probably true. But RAM has advanced in speed and capacity only because it's been needed as the generations of CPU have evolved. The same would have happened with ROMs if they'd been anything more than a bootloader.
We can start afresh with how systems work. Companies like Broadcom building an ARM chip to effectively be a "drop-in" CPU replacement for x86_64 just seems bizarre to me. ARM architecture is all about creating your own wrapper (for want of a better term) around various processing core designs developed by ARM for different utilities, so lets think outside of the DOS box. There's no legacy architecture compatibility/to hold it back, so stop trying to give it one.
Because some people actually want a standard firmware on which you can start whatever compatible software they want. Your solution works great for something where you only want to be able to run the software that was built into the thing. If you want to do some other things, it starts to break down, and if you want to run anything, it breaks down completely.
Updates are no longer optional. Things change more frequently. Even if programmers were all granted superpowers and never wrote insecure code again, people would still add features and not want to buy new hardware. Yes, that includes buying new ROM chips and manually opening and replacing them in all the hardware they have, when rewritable chips cost the same amount or even less given that's what we've been building for so long. We don't have to. People don't want to. Device-specific versions also makes any kind of update more painful as Android demonstrates. Why do security updates have to be device specific, pushed by the manufacturer? Because they didn't standardize enough. If the manufacturer stops caring, you stop getting patched. On desktop operating systems, that's not how it works; the people writing the patches have to explicitly do something that your hardware doesn't support or they have to block you. Windows 10 is ending support, but it's doing that for all things simultaneously, not requiring a lookup table to figure out that yours actually lost it in 2023 but never told you.
You could try to make a better standard, but as long as you're advocating that we go back to no standards, you're going to have a hard time convincing people other than manufacturers, and they're only interested because it makes it easier for them to make their hardware obsolete faster so you have to replace something that would be perfectly acceptable with new software they don't even write.
Okay, so you've poked a hole in one possible architecture, but there must to be others, or ways and means to repair that hole. We can make the alternate architecture a standard, but hardware suppliers are always going to push their own solutions anyway no matter what is done. For example, IBM switched their PC backplane from ISA to MCA way back when, only switching to PCIe when MCA failed due to the industry hating the proprietary nature of the specs and licensing. Now IBM's Power architecture is almost the same as the x86_64 PC, the same backplane and many of the I/O chips are the same, just with a different processor and core chipset, Even the bootloader style mechanism is there.
I just hate the fact that we're still churning out the same CP/M / PCDOS paradigm of booting into a loader that then gets an image from a set location from slow storage; and said image is loaded into RAM. Then a section of that image, now in memory, is executed to start loading the actual kernel and critical code. All this before getting to the rest of the operating environment from the image and then the disk.
I did have a whole proposition of an alternate architecture to go here, but that just grew and grew as I worked on it and muddied the waters, so have now just cut that out.
What i'm saying is lets simplify this whole computer architecture, not just the boot malarky, whilst we get the chance with the switchover to ARM. Something that works in both the personal and enterprise regimes. I mean, come on guys and gals, why even use PCIe as a bus anymore?!!! Lets think people!! Think!!!
Just my 2.5 cents worth.
Perhaps I'm not understanding what, other than simple, you want your bootloader part to be. The rest of the system should probably be handled separately; expansion busses are completely unrelated. From your initial argument, I understood that you wanted directly booted operating systems with no bootloader in the middle. Now your complaint appears to be with the load speed due to loading from slower storage. I don't know what problem we're trying to solve or why this is what we're doing about it.
If load times are the issue, I'm not sure the place you're looking at is the right one. Mostly, I don't care about boot times. So it takes my machine 20 seconds to turn on from cold. I can live with that. I could live with it at two minutes, because I rarely turn it off. When I do, well plenty of things I do require me to wait for upwards of two minutes occasionally. But I have dealt with a situation that might be a closer fit to your desires, namely building an embedded device. I was trying to build this around an embedded Linux stack, but users aren't exactly going to be pleased with an item that takes 30 seconds to turn on. I started to figure out how much stuff I could remove from the boot process, either entirely or at least postponing it so something user-facing would come up while those parts were still being loaded in the background. The firmware loading process was one of those annoying things I couldn't easily remove. However, the firmware loading process was at most 2 seconds and often much less. Copying a smallish kernel image into RAM and branching to it turns out not to be that intensive. Loading that kernel and running through the hardware discovery and initiation process is the slower part.
