Slashdot Mirror
Torvalds Opposes Tying UEFI Secure Boot to Kernel Lockdown Mode (phoronix.com)
An anonymous reader quotes Phoronix:
The kernel lockdown feature further restricts access to the kernel by user-space with what can be accessed or modified... Pairing that with UEFI SecureBoot unconditionally is meeting some resistance by Linus Torvalds. The goal of kernel lockdown, which Linus Torvalds doesn't have a problem with at all, comes down to "prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded." But what has the Linux kernel creator upset with are developers trying to pair this unconditionally with UEFI SecureBoot. Linus describes Secure Boot as being "pushed in your face by people with an agenda." But his real problem is that Secure Boot would then imply Kernel Lockdown mode... "Tying these things magically together IS A BAD IDEA."
Essentially what the corporations want is for people to only user the Internet via locked down ("approved" or "secure" devices). These devices will only have cloud based storage available and everything will be streamed from servers and the consumer will only need to pay a monthly fee for all this goodness. If you don't think this will happen, think of the children, or the terrorists, or the terrorist children, or security, or whatever the problem is this week.
"This discussion is over until you give an actual honest-to-goodness reason for why you tied the two features together. No more "Why not?" crap." -Torvalds
Linux is a distribution by users, for users. So the individuals you are locking down are the developers and future developers of the operating system.
"Keeping the bad guys out" is a nanny state problem for for-cost operating systems. You can tie secure boot and kernel lockdowns together if you want to outsource your I.T. to a third party or for-cost developer.
The rest of us what to know what the difference is between what secure boot protect, and what kernel lockdowns protect. As well as to be able to enjoy our hobby without having to get a degree in cyber security to sign a kernel every time we want to try out a new OS or distribution.
uefi secure boot won't "keep the bad people out" either. In fact, uefi secure boot is a vehicle to take control away from you-the-computer-owner, and as such is the vehicle of bad people looking out for themselves using your hardware.
Nanny state to ensure your HIPPA and PCI and SOX compliant servers at work do not have rootkits?
If a system is rooted once a computer is booted then a few things MUST be true:
1. You've already epically failed. It's game over right there and then. Talk about what happens next is mightily irrelevant.
2. See 1.
3. See 1.
4. Unless vulnerability is found and fixed secure boot won't do shit to prevent the rootkit from being re-loaded upon next boot the same way it was loaded initially.
I very much fail to see the point here. The only conclusion I could draw that would make any sense is when you get owned you can get away with tempting fate and not have to completely rollback system / rebuild all of your shit otherwise secure boot seems to be an exceedingly pointless waste of time.
There is a much easier and much more secure way to handle this that does not require any cryptographic bullshit. Deny capability to modify OS image via hardware latch and don't allow any hardware to incorporate persistent storage that can be modified in the field.
The real reason for secure boot isn't security. It's exclusively about locking out users in order to dictate terms.
IT departments require UEFI secureboot with custom add in keys for their servers which Redhat and FreeBSD support I may add is to make sure you keep your job.
Box checking jobs sure do pay well regardless of predictably feckless results.