Linux 5.4 Pulls In LOCKDOWN Support For Opt-In Hardware/Kernel Security Restrictions

[phoronix]

Phoronix: Linux 5.4 Pulls In LOCKDOWN Support For Opt-In Hardware/Kernel Security Restrictions

While yesterday Linus Torvalds was still undecided on whether to pull in the long-revised "LOCKDOWN" kernel patches and wanted to review them patch-by-patch, following that lengthy examination he has decided to indeed land this opt-in restricted functionality for Linux 5.4...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.4-Adds-Lockdown

[tildearrow]

OK, then........

[Marc.2377]

The way I see it, anyone complaining "it hurts my freedom" regarding this patchset doesn't have the slightest clue what the patches are actually about.

The lockdown are hardening against exploitation, rootkits and legit 'malicious actors' (as I've seen them called) - they are not about locking down on end users.

I dare anyone complaining to cite their reasons for needing regular write access to '/dev/mem' or unrestricted CPU MSR access. Are you guys regularly overwriting arbitrary kernel memory locations and fiddling with the low-level control registers in the CPU? I'm genuinely interested.
p.s. If you are a low level developer and need to debug or mess around with any of the restricted features, I'm sure you'll manage to disable lockdown for your kernel.

Edit: Shall I add that the merged pull request implements lockdown (i) untied to secure boot, (ii) as an opt-in feature (command-line parameter), and (iii) states that "The majority of mainstream distributions have been carrying variants of this patchset for many years now" - about 6 years, to be precise. (Sorry, I can't quote which distros exactly).
But well.

[guilhem]

I dare anyone complaining to cite their reasons for needing regular write access to '/dev/mem' or unrestricted CPU MSR access. Are you guys regularly overwriting arbitrary kernel memory locations and fiddling with the low-level control registers in the CPU? I'm genuinely interested.

I'm quite happy by these patches to replace those integrated by Ubuntu (for example).
Currently, I'm obliged to disable secureboot to edit CPU MSR (I'm using it to underclock my CPU).
Having these patches will let me choose what behavior I want without editing bios parameters.

[Marc.2377]

I'm quite happy by these patches to replace those integrated by Ubuntu (for example).
Currently, I'm obliged to disable secureboot to edit CPU MSR (I'm using it to underclock my CPU).
Having these patches will let me choose what behavior I want without editing bios parameters.

Okay, the challenge is withdrawn early. I didn't know that was even somewhat popular.

[starshipeleven]

The way I see it, anyone complaining "it hurts my freedom" regarding this patchset doesn't have the slightest clue what the patches are actually about.

The lockdown are hardening against exploitation, rootkits and legit 'malicious actors' (as I've seen them called) - not about locking down on end users.

Yep. If your linux system does not allow you to edit boot commandline options to control this feature, you have bigger problems on your hands.

[Marc.2377]

I think what folks have in mind when they hear of the lockdown feature is new devices coming to the market with locked firmware and bootloaders preventing libre use of their linux. But hey, that's what we got geohot for.

Just kidding. You can still not buy the device, though. (Yeah I realize this only works for a limited extent.)

[chithanh]

The lockdown are hardening against exploitation, rootkits and legit 'malicious actors' (as I've seen them called) - not about locking down on end users.

I dare anyone complaining to cite their reasons for needing regular write access to '/dev/mem' or unrestricted CPU MSR access. Are you guys regularly overwriting arbitrary kernel memory locations and fiddling with the low-level control registers in the CPU? I'm genuinely interested.

That is a strawman argument. And you've answered your question yourself:

new devices coming to the market with locked firmware and bootloaders preventing libre use of their linux.

You can still not buy the device, though.

And that is precisely where the problem is. Kernel lockdown used to be a very invasive and risky procedure that only few vendors would have the expertise to implement. Now it is facilitated and basically every vendor who wants to lock out the users from their devices can just flip it on.

"it hurts my freedom"

Just look what is necessary today to get a fully libre system. What kind of hoops you have to jump through, the additional expenses, hunting down rare parts, limited hardware choice, the quirks and loss in functionality you have to live with, etc.

This is where we are heading if you want a system that is at least mostly hackable, and kernel lockdown pushes us a bit further in that direction.

[Marc.2377]

I don't buy it (the reasoning, not non-libre devices). I've been seeing linux-based devices with non-unlockable bootloaders (and obviously, non-root access) for the most part of the last decade now. And by that I mean actually longer than the first iterations of what we now know as lockdown the patchset. If anything, from my point of view we are nowadays many steps ahead in terms of libre than we've ever been.

[chithanh]

I think you misunderstand. I am talking about hackable, not libre. And that hackable is going to the place where libre is now.

And sure, working around a non-unlockable boot loader requires finding and exploiting a vulnerability in the boot loader or OS, and then becoming somehow persistent.