The Linux kernel lockdown patches were merged into the 5.4 kernel last year, which means they’re now part of multiple distributions. For me this was a 7-year journey, which means it’s easy to forget that others aren’t as invested in the code as I am. Here’s what these patches are intended to achieve, why they’re implemented in the current form and what people should take into account when deploying the feature.
Root is a user – a privileged user, but nevertheless a user. Root is not identical to the kernel. Processes running as root still can’t dereference addresses that belong to the kernel, are still subject to the whims of the scheduler and so on. But historically that boundary has been very porous. Various interfaces make it straightforward for root to modify kernel code (such as loading modules or using /dev/mem), while others make it less straightforward (being able to load new ACPI tables that can cause the ACPI interpreter to overwrite the kernel, for instance). In the past that wasn’t seen as a significant issue, since there were no widely deployed mechanisms for verifying the integrity of the kernel in the first place. But once UEFI secure boot became widely deployed, this was a problem. If you verify your boot chain but allow root to modify that kernel, the benefits of the verified boot chain are significantly reduced. Even if root can’t modify the on-disk kernel, root can just hot-patch the kernel and then make this persistent by dropping a binary that repeats the process on system boot.
These patches are intended to prevent that, and this blog post goes into detail about how it all works.
If you consider the “root” user to be an extension of the owners control over his linux computer, this is potentially dangerous to owner rights.
As with all things having to do with UEFI secure boot, the concern lies in who holds the keys to the mechanism used to lockdown the computer… If it’s the owner, then it isn’t necessarily a problem, but unfortunately the UEFI spec was created in a way that allows manufacturers to withhold control from owners. In practice, microsoft’s keys would get bundled into every motherboard while most linux distros will not be so lucky. This rightly drew lots of criticism, and at the time microsoft’s response was to require manufacturers to give owners the ability to disable secure boot on x86 machines, an assurance they have since reneged on once the commotion went away.
So now it’s up to each manufacturer whether or not to lock down the secure boot keys. There’s another wrinkle because microsoft accepts applications for other operating systems to run under it’s key and now certain mainstream linux distros are able to run under microsoft’s key. You could see this as an olive branch from microsoft, however linux users may not even realize whether their computers are secure boot restricted or not and they can be dependent on microsoft’s permission to boot alternative operating systems. This runs counter to the freedoms many of us expect from our computers. I’m not comfortable relying on someone else’s permission even if that permission is granted.
Here’s some information about it:
https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/ImageSigning
I recently came across my first computer where I could boot a mainstream linux distro, but I could not get others including my own (which is not signed) to boot at all. No matter what I tried, it wouldn’t boot. Furthermore custom bootable windows utility flash disk would not boot either. I can see & select bootable EFI media, but it just refuses to boot. It behaves as though the BIOS is simply ignoring attempts to disable secure boot. Alas if this is where commodity PCs are headed, then it will pose extreme hardships for alt-os enthusists. How are we supposed to know which computers are locked or not before buying them? I did my research in earnest, other reviewers reported that ubuntu booted, which it does. However I used to assume this meant a computer wasn’t secure boot locked, but alas this may not be the case going forward 🙁 . I guess I should be happy I can run ubuntu at all, but damn it it’s my computer, it should be my right to select what operating system to run on it. I certainly don’t need the manufacturer or microsoft telling me which linux distros I’m allowed to run. Just get the hell out of my way.
The author has posted to osnews in the past under the topic of secure booting under microsoft’s UEFI keys, I wonder if he’s still reading articles & comments here.
I couldn’t agree more. Well said.
exactly.
I do not think this is going a way I like 🙁
I understand the concerns, this could allow for a super tivo’d experience. At the same point, I do want to be able to lock down the os of my choice to an extreme extent. As long as its completly my choice, I’m okay with this. But, If I decide I do want to be able to modify the kernel, I should be able to. I’m not sure how that would work, even in my ideal world. I’ll have to think about this.
Bill Shooter of Bul,
The secure boot standard is rather broken because it wasn’t engineered for owner control, but rather for vendor control. The only mechanism defined by the standard for an owner to install a non-OEM key is to sign the owner’s new key with the OEM key, but this is extremely flawed since there’s no challenge/response protocol to identify the machine. Say my machine is preloaded with microsoft’s key. To change my key under the standard I would need to persuade microsoft to sign my key. Well, this process is not tied to my machine, so the signature that microsoft would need to give me to unlock my machine would enable me to replace their key on any machine using their key. Obviously microsoft won’t & can’t do that…the failure is really with the secure boot standard itself. This is a terrible flaw, but I don’t believe any of the companies behind secure boot cared because they weren’t designing it for owner control.
It’s a damn shame that nobody was representing owner interests when the standard was adapted since applying an owner key would have been an obvious use case for owners. Fortunately many UEFI implementations use non-standard mechanisms to give owners a way to achieve this under the supervisor login (and I applaud those that do, even if it was because the windows 8 OEM terms originally required required it), but it would have been much better to standardize on a mechanism for owners to import keys. Another problem that’s quite maddening is that some of these secure boot systems don’t show errors to indicate anything is wrong, they just pretend the boot media isn’t there at all, which is confusing as hell. Am I using the wrong boot media? Did I plug it in right? Do I need to change the boot priority? Why does this media work and that one doesn’t? It’s just stupid not to tell the owner that the key isn’t recognized and that’s why it’s not working. Again it’s like they didn’t even bother testing a use case where owners would be able to bring their own keys.
If only secure boot would have been built around owner’s needs first and foremost, it could have been so much better.
The reactions here seem to be misguided to me. You can’t have real security without protections like these. It does make things harder to tinker with but that’s kind of the point. It’s useful and even necessary for some implementations.
abraxas,
Ok, but don’t misunderstand the reactions, the majority of us are not against secure boot restrictions in principal so long as they remain under owner control, we just want to have the keys to our own machines rather than a 3rd party corporation. It’s completely fair to point out the ways this can be abused. Now that I’ve bought my first x86 computer where I can’t run the OS & tools of my choice, the concern over secure boot restrictions in hindsight several years ago was well founded.
At least for the time being I still have full root access under ubuntu, but there may come a day when not only do I loose the freedom to choose what OS will boot, but I may additionally loose full root privileges due to patches like these. I do believe Matthew’s patches are well-intentioned, however let’s not be foolish in accepting the blanket application of security measures that etch away at owner control over time. I’ve heard all the excuses before and some argue that owners need to be protected from themselves, but if we don’t precede extremely carefully this misguided belief will lead to the IOSification of PCs. 🙁
It definitely seems to go that way.
A specification can say: needs an option in the BIOS/UEFI firmware to disable the check or allow new keys, but these options aren’t actually tested by manufactures.
The end is nigh. 🙁