UEFI Secure Boot
In case you don’t know what this blog is talking about: UEFI is the “Unified Extensible Firmware Interface”, and “Secure Boot” is one of its more recent features that is generating a bit of a stir in the Open Source world.
At SUSE, we have been looking at UEFI Secure Boot long and hard.
On one hand, we agree that closing down some of the loopholes in the boot process is a worthwhile goal. For decades, we have accepted that this process has been one of the soft spots that are essentially unfixable without a major change in the BIOS. Now that this change is coming, we are ready to embrace it. And we’re also happy to see a much bigger change happening as part of this, which is the establishment of UEFI as the standard firmware on all x86 platforms.
On the other hand, as a Linux company, we are seeing a number of issues that have been causing us quite some headaches, which we wanted to resolve before we publicly state our plans in this regard.
In order to explain our concerns, let’s take a brief look at what Secure Boot really does, in a nutshell. In the world of UEFI, securing the bootstrapping process means establishing a chain of trust. The “platform” is the root of this chain of trust; I tend to think of it as the motherboard and the on-board firmware ROM. Or, put slightly differently, it’s the hardware vendor, and the chain of trust flows from that hardware vendor to the component manufacturers, the OS vendors, etc.
On the legal side, this trust is established by a lot of contracts and other legal paperwork. On the level of bits and bytes, this trust is expressed via public key cryptography. The vendor puts a so-called Platform Key into the ROM, representing the root of trust. The trust relationships with operating system vendors and others is documented by signing their keys with the Platform Key.
Finally, security is established by requiring that no code will be executed by the firmware unless it has been signed by one of these “trusted” keys – be it an OS boot loader, some driver located in the ROM of some PCI Express card, or be it an update of the firmware itself.
Of course, one could make this a very long chain of trust, by requiring that everything that ever gets run on that machine be signed: the OS itself, the modules it loads, the binaries and shared libraries it loads, all the scripts executed by any random interpreter, and even
the commands you type into a shell session.
So obviously, that has to stop somewhere; and in the UEFI specification, that point is reached when the firmware hands control to the operating system. Essentially, if you want to use Secure Boot, you need to have your OS loader signed with a key trusted by the firmware, and you need the OS loader to verify that the kernel it loads can be trusted.
Admittedly, this is glossing over quite some details – but that is of no real importance for this discussion.
The crux of the matter is that this conflicts with the way the Open Source community has been developing code for several decades now. The Open Source movement began as an act of emancipation from the operating system vendors of that time. Open Source was and is about Freedom, not in a dogmatic, but really in some very practical sense. The Linux community is where it is today because people could just start their own distribution, build their own boot loader and kernel, and grow a community. It is thriving the way it is thriving today because there are thousands of people around the globe who rebuild their kernel ten times a day to fix bugs, to add enhancements, or to run their test harness on the latest set of changes. And it will only continue to thrive in this way if we keep it that way.
From this point of view, Secure Boot is very much at odds with the Linux development model.
Just for the record, I do not think this is a conspiracy, or a sinister attempt to kill Linux. That’s not going to happen. But while Secure Boot can be a significant improvement for many, it definitely creates obstacles for the Linux community.
Granted, the Windows 8 Logo certification requires that BIOS vendors should allow users to turn off Secure Boot on x86 platforms, and we have hope that all BIOS vendors will actually implement this in a way that works well for Linux developers. But ideally, Linux developers should not be required to switch off a security feature in order to run their operating system.
Thus, over the past months, our guiding questions when dealing with Secure Boot have been, how can we make it work for our customers, and how can we reconcile the requirements of Secure Boot with the needs of the Linux community.
We plan to continue this series of blog postings soon with an overview of how we intend to support Secure Boot in SUSE Linux Enterprise, and what solutions we propose to the openSUSE community.
Related Articles
Jun 18th, 2024
Empowering Innovation: Celebrating Partner Excellence
Apr 03rd, 2023
SUSE Linux Enterprise and SBOM support
Aug 07th, 2023
Cybersecurity Threats to SAP Systems
Comments
‘The Secure boot’ option provides only 1 thing. To provided that a guarantee that only [key issuer=microsoft]-authorized devices’ may access ‘arbitrary resources’.
‘arbitrary resources’ can include just about anything you can imagine — your internet access, (would some ISP switch to only allowing trusted computers? private companies almost certainly would on company networks); bandwidth; websites; services; products;
Note: the ‘authorized’ devices can be whatever the key issuer wants to make them including(many “unlikely’s” included! but what is considered absurd today, might not be in a few years of increased controls): devices running on MS-approved (controlled) OS’s… this can include linux — if proper backdoors^w Auto-update features are forced to be enabled for security to be ‘assured’)… Such backdoors have already been used by attackers to hack into systems… something I predicted when they started push-updates)
It depends on who requires MS’s secure computers… MS used to have a partnership w/Hollywood (NBC), officially that was dissolved, but their actions show more prep to make PC’s into “player-only” devices — that play authorized software… whether or not things will ever reach that stage is unknown — but a closed Apple-like platform seems to be a desired goal.
It bothers me greatly, as I have almost always run a self-built kernel tailored & optimized for my HW — I can’t see how that would be possible unless I let someone else build my kernel for me, inserting their “signature modules” that might do a bit more than sign the code…
BTW — great write-up!
Hi Linda,
Let me add two things in response to what you said.
One, it’s important that we do not confuse Secure Boot with Trusted Computing. The latter was about attestation, which indeed would have allowed third parties to verify what software is running on your computer, and I think it’s good thing that it never succeeded. Secure Boot, on the other hand, is not about attesting what is running, but about preventing malware from subverting your machine.
Two, I agree that Secure Boot very much gets in the way of how we have been using and developing Linux for the past twenty years. Fundamentally, it prevents me as the owner of the machine from taking full control of what I own – it’s a bit like selling hammers that work with Brand X nails only, but fail to work with anything else.
So when discussing Secure Boot in SUSE Engineering, we were always pursuing two questions – how can we make it work for our users and customers, and how can we avoid locking people in?
Stay tuned for further updates 🙂
I don’t understand why Linux vendors like SUSE are bothering with this, since SecureBoot is only supposed to be mandatory on new Windows ARM hardware. Since Microsoft has already successfully alienated OEMs by making their own Windows ARM hardware, it seems to me this is a pretty minor concern! Though I am glad that SUSE is confronting the FUD and explaining that UEFI itself is going to be a massive improvement for everyone. It will!
Olaf said, “But ideally, Linux developers should not be required to switch off a security feature in order to run their operating system.” That would appear to address my question, but I ask again: why? I do not doubt your commitment to security, but why would you bend over backwards to implement a security system which is explicitly only going to close the barn door after the horses are out?
It’s my understanding that UEFI SecureBoot will only help if someone has managed to replace the bootloader (or kernel?) without detection. If they have this level of access to your computer, they could easily replace another component without detection. SUSE doesn’t checksum /sbin/init or /lib/modules/… on each boot, does it? It’s true that the boot process is one instance where an OS can do precious little to guarantee security, but even after boot-up, SUSE doesn’t traditionally engage in rampant paranoia to guarantee security, so why focus on this one little spot?
I’m just curious about the priorities. I have the impression that SUSE is a very practical company. Prioritize Apache & BIND buffer overflows, don’t get paranoid trying to detect rootkits after they’re in, right? Right?
Agreed, you are correct in that malware needs to subvert all OS security before it can even think of replacing the OS loader. And we are very careful on this line of defense, and I think the Open Source community has done a pretty good job there.
However, assume some remote attacker did succeed in subverting all OS security and plant a rootkit in your boot path; then your situation becomes really precarious. The malware now has a pretty strong hand in concealing itself, and recent worms have actually done that. When using UEFI without secure boot, things get even worse, as malware could hide itself in some UEFI driver, so that that even a full OS reinstall wouldn’t get rid of it.
So yes, you’re locking the barn door after the thieves stole your horses. But at least you don’t have to burn down the barn to get rid of them.
[…] SLE 11 genutzt werden soll. Das geht aus zwei Blog-Posts von Suse-Mitarbeiter Olaf Kirch hervor (1, 2). Die Pläne für Suse unterscheiden sich an zwei Stellen aber von denen Fedoras, wie aus einem […]
[…] SLE 11 genutzt werden soll. Das geht aus zwei Blog-Posts von Suse-Mitarbeiter Olaf Kirch hervor (1, 2). Die Pläne für Suse unterscheiden sich an zwei Stellen aber von denen Fedoras, wie aus einem […]
Hello!
I have made a spanish translation of this article.
I would like to spread to the world in my blog, always mentioned the original and the author, of course!
Can i publish in my blog? You can answer me by mail.
Thank’s for your work!
Hmmm…
When making packages for Android, it’s not all that troublesome to generate a valid certificate so my ‘phone won’t balk at installing them.
Seems to me that unless ones UEFI-SB computer is expected to verify a certificate via the network at boot-time, generating ones own certificates should be doable.
Since everyone is potentially a developer, everyone should be able to sign their own software.
Or am i missing something?
Would it be possible to update the UEFI Secure Boot posts (specifically the graphics) to include ELILO. Where does it fit? Why is it necessary?