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:
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.