Garrett: Linux kernel lockdown, integrity, and confidentiality [LWN.net]

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 6:47 UTC (Wed) by jorgegv (subscriber, #60484) [Link] (17 responses)

Surely. It can also be used for protecting users from malware installing rootkits, for example.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 12:03 UTC (Wed) by scientes (guest, #83068) [Link] (16 responses)

I don't believe that at all. These features are always to give "security" (i.e. perpetual ownership) to device designers, by making it too annoying to tinker with (keep in mine that Turing showed that this is not security at all). With iTunes they had to turn off the DRM (on music only) because otherwise no-one would have used their product as it provided negative value.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 19:10 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

This code was largely written while I was at Red Hat, not a company known for its hardware products.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 13:21 UTC (Thu) by ncultra (✭ supporter ✭, #121511) [Link] (1 responses)

Mathew, thank you for your effort on all of this code, it is needed and appreciated for a good segment of the user base.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 9:17 UTC (Fri) by bluca (subscriber, #118303) [Link]

Seconded. It's incredibly useful, and especially given how long and difficult the road to mainline was, praise is well deserved. Thank you!

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 22:22 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (12 responses)

> I don't believe that at all.

We must be careful in disagreeing with each other, lest we talk past each other and learn nothing from it. This starts by being precise about the claims with which we disagree:

The set of users whose devices are at serious risk of malware infection is much, much larger than the set of users who want to root their devices.
Malware can do a lot more harm if the device can be rooted than if it cannot.

These claims are factual, not ethical. They may be subject to empirical refutation (and if you have citations, I would be very interested in seeing them), but they cannot be logically refuted by moral arguments.

To determine the morality which results from this set of facts, you would need to consider:

Whether you are a consequentialist ("The needs of the many outweigh the needs of the few") or a deontologist ("We hold these truths to be self-evident, that all men [...] are endowed by their Creator with certain unalienable Rights[...]"). You can't be both, because they contradict each other. (There are other ethical positions as well, but for simplicity I omit them here.)
If you are a consequentialist, the amount of harm that you believe is created by each instance of malware on average, and by each user denied the right to root their device. Then, you multiply by the number of users affected, and compare the two harms in aggregate.
- Factors such as the "fault" of nontechnical users for failing to secure their devices, or the "freedom" of technical users to root their devices, are out of scope and not evaluated, except to the extent that they can be framed in terms of consequences (e.g. Would nontechnical users have been infected anyway? Can we quantify the amount of additional harm caused by the infected device being unlocked, instead of the total harm?).
If you are a deontologist, whether you consider rooting a device to be a fundamental right, and the extent (if any) to which you believe this right can be attenuated by your contractual agreement with the vendor or service provider, or by other considerations such as the availability of unlocked devices.
- Factors such as the number of users who will actually be subject to malware infections, and the likely consequences of those infections, are out of scope and not evaluated, except to the extent that they can be framed in terms of rights and responsibilities (e.g. Does the manufacturer owe a duty of care to its users? Will the malware cause harm to the public, for which the manufacturer would be responsible? Do the users themselves have responsibilities here?).
Whether facts can give rise to morality in the first place. (This is mostly only of interest to philosophers, but it gives you a sense of just how complicated this whole problem is.)

Since all of these points are somewhat subjective and/or disputed, it should be unsurprising that reasonable people may disagree about them. But we must not lose sight of the underlying facts, or it will be impossible to have a constructive discussion about this question.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 23:39 UTC (Wed) by pizza (subscriber, #46) [Link] (11 responses)

You left something out of the factual claims:

0) The device is the property of the owner.

Therefore one has to include the concept of property rights in any analysis, especially in situations where the owner and user are the same party.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 4:23 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (7 responses)

I broadly agree with you, with some qualifications:

Consequentialism doesn't care about property rights *as rights,* but it may be willing to recognize their abrogation as a form of harm which can be morally weighed. I already described doing so in my previous post, so I'm not sure what more there is to add here.
For deontology, property rights may be contracted away, regulated, limited by other responsibilities, or otherwise extinguished, and you need to determine whether that has happened in each specific case. Property is not a trump card.
There is a tendency to confuse the legal with the moral. Property rights and contractual obligations straddle this line, and need to be carefully considered in a deontological setting to avoid presuming that "the law" is always morally correct.
We are discussing the morality of locking down the device in the first place, not the morality of rooting it after the fact. Those two things could both be morally permissible, because they are different actions taken by different people at different times.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 7:17 UTC (Thu) by scientes (guest, #83068) [Link] (6 responses)

I appreciate that your effort. Besides the property rights mentioned above, I am mainly talking about how Linux is impossible to make secure because of the massive attack surface. The main way to show this, is to show what it is NOT, which is software written from the beginning to be proven correct:

https://microkerneldude.wordpress.com/2016/06/16/verified...

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 10:44 UTC (Thu) by smoogen (subscriber, #97) [Link] (5 responses)

When I sat in a class in proven software in the 1980's, the professor who was all for it wanted to stress that it isn't perfect unless you map out the entire universe in your proof. All it takes to destroy most proofs is some change in the environment be it running on a different CPU, hardware or even the orientation of the system. [The example given was that software which had been proven correct would fail in a way outside of the proof, if the computer was turned 90 degrees during the day. It worked fine at night in that orientation. The reason turned out to be a microwave dish in another lab which affected various components inside of the computer just slightly enough to make them not react properly.]

In the end, you can't make anything absolutely secure and generally usable. You can make it resilient and robust, but if people or the environment can interact with the system at all.. there will eventually be a way to make it insecure.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 11:16 UTC (Thu) by Wol (subscriber, #4433) [Link]

This is the difference between Mathematics and Science.

Your program proof will prove that your program is correct and consistent.

You then need to test it, to make sure (as best you can!) that theory and reality agree.

Mathematical proofs prove that things are *consistent*. Scientific proofs prove that reality disagrees with mathematics.

Cheers,
Wol

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 12:52 UTC (Fri) by jhhaller (guest, #56103) [Link] (3 responses)

The one I remember was a UK company (INMOS?) who was going to build a provably correct microprocessor. Unfortunately, they didn't account for silicon defects in actual implementations of the microprocessor. While that's not to say formally verifying the design is bad, just that it won't guarantee a particular chip will always work the way the specification says it should.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 17:49 UTC (Fri) by zlynx (guest, #2285) [Link] (2 responses)

Yep. Reminds me of a security story I heard a long time ago, about pen-testing a very fancy biometric lock system. An iris scanner, if I recall correctly.

One attacker bypassed the whole thing by inducing a signal into the wire in the wall that triggered the unlock relay. So much for security scanners.

And one of the smart cards where secret keys could be extracted by observing the outputs while applying a hair dryer to the card.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 18:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

You can trick a LOT of electronic locks using a simple magnet to trigger the motor relay.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 18:09 UTC (Fri) by kmweber (guest, #114635) [Link]

And to a large extent, it matters just what you're trying to protect against.

In college, I had a summer job that involved (among other things) cleaning and performing routine maintenance on large inkection molding machines at an automobile factory. This required physically entering the machines. The molds used weighed on the order of forty tons; consequently, the hydraulic presses generated several thousand tons of force. You did NOT want to be stuck inside that thing if it were accidentally powered up.

Consequently, as is standard practice in such environments, we used a lockout/tagout process that involved placing padlocks to immobilize the switches and valves for the power sources, and then placed the keys for those padlocks in a lock box. The lock box was shut by individual padlocks for everyone on the team, and each person kept their key on them. That way, it could only be opened (and thus the padlocks on the switches could only be unlocked) if everyone involved came out of the machine and removed their personal padlock.

Of course, the lock box was made of fairly brittle plastic, and the padlocks themselves were of the sort that you could cheaply purchase at any hardware store. So it wouldn't have been difficult at all for someone with ill intent to bypass the whole system--all you'd need is a hammer or bolt cutters. But that was fine, because it wasn't intended to protect against malice. It was there to prevent accidents, and it did so quite effectively.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 11:19 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> You left something out of the factual claims:

> 0) The device is the property of the owner.

Not to forget that the keeper/user is not necessarily the owner (as has been mentioned elsewhere).

Cheers,
Wol

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 12:23 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Not to forget that the keeper/user is not necessarily the owner (as has been mentioned elsewhere).

Of course!

But the keeper/user and owner can also be the same party, and when that device's ownership is transferred as part of a sale, the seller/oldowner no longer gets any say in what the buyer/newowner does with it.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 12:26 UTC (Thu) by Wol (subscriber, #4433) [Link]

I know. The trouble is, a lot of people seem to start from the premise "if it's in my possession, I own it". After all, possession is nine tenths of the law, after all ... :-)

Cheers,
Wol

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 6:52 UTC (Wed) by re:fi.64 (subscriber, #132628) [Link]

I think many security features could in theory be used for this, but at the same time this can be a godsend for any business working with sensitive information.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 7:26 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (14 responses)

If you're in control of your system then you can replace the kernel. If you can't replace the kernel then your freedom is already encumbered - you may be able to find a vulnerability in the kernel or make use of an existing kernel interface to modify it, but you're still dealing with a system that's attempting to restrict your freedom.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 9:20 UTC (Wed) by leromarinvit (subscriber, #56850) [Link]

I'm sort of split on this issue. I recognize the value of intentionally locking down a system I own, control and use myself for security. And when buying a new device, I prefer those where the manufacturer doesn't pretend they still own it after I bought it, and thus lets me control what it runs.

However, there are (and probably will be for the foreseeable future) many existing devices made by less friendly companies, that can still be made to work better or be more useful by modifying or replacing the software they run. So in these cases, any effective anti-tampering measure is a hindrance to the user, not a benefit.

Also, when choosing from a list of available devices, there are obviously other concerns as well, such as features, price, or build quality. And in some cases, there is no freedom-respecting choice at all.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 12:06 UTC (Wed) by scientes (guest, #83068) [Link] (12 responses)

But Linux is impossible to make secure in the strong sense you claim to be going for. Only seL4 (or something like it) can provide that. Because Linux simply is not secure from a local adversary (and it is impossible to make it so), the only use of this feature is to making engineering more difficult, and you are just creating more work for other people (which is basically the definition of an anti-feature). Please go away. Both you, and your social justice warrior witch-hunt mentality.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 13:18 UTC (Wed) by Paf (subscriber, #91811) [Link]

Well, uh, wow.

Rather than engage with the ugly parts, I’ll just give you a simple example: what does local access mean if your server happens to be - as strange as this sounds - *in another building from you*? Can you guarantee you’re the only one with local access? (This is of course ignoring the proliferation of remote methods to get local access, like various remote KVM and lights out type systems)

So, per you, the world should just stop using any Linux system they don’t physically control. And obviously of course everyone with physical access is trusted, at all times. And no remote consoles, dear god.

Gee, it sounds like security might be worth something even if it’s imperfect.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 14:18 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (9 responses)

"It can't be perfect, so let's just give up." What an asinine argument.

Nevermind that there are use cases where I may have access to a machine, but not ownership. I'd like to know that lending my laptop won't result in a rootkit. Schools want to provide laptops to students without them being allowed to replace the OS. Employers, etc. Yes, companies can also use it with respect to their customers. Complain about those instances, not the tool because those companies don't care about the tool as much as the end result.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 5:25 UTC (Thu) by pabs (subscriber, #43278) [Link] (8 responses)

Students and employees should be able to trust the OS on the laptop they use, which means they need to be allowed to replace the OS.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 6:27 UTC (Thu) by diconico07 (guest, #117416) [Link] (3 responses)

Universities/Schools/Companies/Whatever must be able to trust the OS on the laptop connecting to their network, which means they need to ensure it cannot be tempered with. Moreover to trust the OS on the laptop you use, I would rather say you need to be able to audit its code and configuration, not modify it.
There is also the fact that to trust your own laptop with the OS you put there, you have to be sure no one tampered with it (while you were away for example).

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 7:56 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (1 responses)

> Universities/Schools/Companies/Whatever must be able to trust the OS on the laptop connecting to their network, which means they need to ensure it cannot be tempered with.

It can be tampered with, they need to assume they cannot trust anything that connects to their network instead.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 12:59 UTC (Thu) by excors (subscriber, #95769) [Link]

> It can be tampered with, they need to assume they cannot trust anything that connects to their network instead.

It's impractical to never trust anything, so I assume you mean "don't trust anything simply because it's connected to the private network - use some kind of 2FA to verify a legitimate user is there before trusting it (and then still only trust it to the extent necessary for the user to do their job)". But a legitimate user could sign in with 2FA on a computer that's riddled with malware, which subsequently steals data from the private network or sends malicious data into the network. Even if they don't sign in, the malware could steal sensitive information that's cached locally (e.g. emails discussing confidential matters). That's not good enough protection.

Most students and many employees are likely to willingly install dodgy software on the computers provided to them, and all will be vulnerable to targeted phishing attacks, so you can't rely on the user to avoid malware. If someone with expertise and accountability, like the company's IT department, can verify the computers are running the clean software they were originally provided with and have not been tampered with, then that's a significant extra layer of protection. And that requires technical features to either prevent or detect tampering, like this kernel lockdown stuff. (And of course they should still do 2FA and least privilege too.)

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Jul 13, 2020 13:43 UTC (Mon) by immibis (subscriber, #105511) [Link]

There IS a middle ground: you can replace the OS, but after you do that, it cannot connect to their network.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 18:08 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (3 responses)

The guys who sit five yards away from me when we're in the office need the ability to replace the OS on the laptop the company bought for me to use for my employment duties.

I, on the other hand, don't want the ability to replace the OS on that laptop.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 6:08 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

> I, on the other hand, don't want the ability to replace the OS on that laptop.

You can have the ability. You don't necessarily have to take advantage of that ability.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 10:46 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

That's the point. If the ability is there, it can be mis-used. *HE* may not want to take advantage of it, but an attacker might.

As also mentioned elsewhere, I look after elderly relatives. I would *LOVE* to be able to lock down their systems and remove all these fancy "ease of use" features. Hell, *I* regularly invoke these damn features without realising it, and undoing a massive change that you did by mistake because you hit a key that you didn't even *know* did something fancy ...

The mere *ability* to do something is a massive liability when you are dealing with folks who don't understand computers (or on the other hand understand them far too well...).

Cheers,
Wol

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 25, 2020 0:04 UTC (Sat) by sjj (guest, #2020) [Link]

If you really want to do that, give your relatives chromebooks attached to your google domain. Tried it with mine, too much of a hassle for me but ymmv. Everything can be managed centrally. Normal google caveats apply.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 2:39 UTC (Fri) by RogerOdle (subscriber, #60791) [Link]

No general purpose operating system written in millions of lines of code can be secure. Linux isn't. OSX and Windows and Android are insecure by design. Even the Linux desktops want to integrate with google and open up the system to the advertisers. We are under constant pressure to willingly compromise our privacy because if we don't then we can't run the latest app craze that everyone else is running. Quality of life is diminished if we cling to our illusions of privacy.

As for locking down the kernel. It is absolutely necessary. Forget what the hardware vendors want. I want it for my 90 year old mother who doesn't have time or the capacity to patrol the digital border line of here computer and phone to stop and deal with intruders. The unfortunate thing is that some simple features that experienced users may want, like file sharing, don't work unless the device is unlocked. Where is the limited access? As for me, I want lock down capability for my relatives who are not nerds.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 7:34 UTC (Wed) by ras (subscriber, #33059) [Link] (1 responses)

> This looks like something to avoid people to do what they want with the devices they bought. :(

Perhaps. I guess if you avoid routers because you can't install openwrt on them this might be something else to avoid.

But even then, it isn't necessarily as bad as not being able to install software at all. It just means when you do so you break the trust chain, and everybody can know that. It's the model many Android phones follow. You can root them, but if you do software like bank authenticators may not trust your device any more.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 10:02 UTC (Wed) by Herve5 (subscriber, #115399) [Link]

> I guess if you avoid routers because you can't install openwrt on them this might be something else to avoid.
Here in Europe at least, there are off-the-shelf routers you can install it on, among others the ones from Turris (these in addition even propose a honeypot function that connects back to the university behind Turris to feed some filtering lists, and various other options, but I didn't activate these on mine...)

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 8:55 UTC (Wed) by ballombe (subscriber, #9523) [Link]

We just need to add an special UID that has the privilege that were removed from root :-)

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 28, 2020 16:32 UTC (Tue) by AngryChris (guest, #74783) [Link] (12 responses)

Take another look at the post.

> Lockdown is intended as a mechanism to avoid that, by providing an optional policy that closes off interfaces that allow root to modify the kernel.

Optional.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 28, 2020 19:41 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (11 responses)

> Optional.

If root can just do echo 0 > /magicpath this feature would be completely pointless, so optional only means that it won't be enabled on every kernel by default, but if it gets enabled it is there for good I guess.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 29, 2020 0:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

>so optional only means that it won't be enabled on every kernel by default, but if it gets enabled it is there for good I guess.

It's a config option. Why is this a concern?

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 9:56 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (9 responses)

> It's a config option. Why is this a concern?

Because when you buy a device you don't get to recompile the kernel, and for some devices it is completely impossible to replace the kernel with one that has the configuration you want it to have.

This patch aims to make running your own kernel on your own device even more difficult, since even by being root it might not be possible to replace the kernel.

So the problem is that even if you can compile a kernel without this option, if you can't run this kernel, it is pointless to be able to disable the option.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 12:59 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> Because when you buy a device you don't get to recompile the kernel, and for some devices it is completely impossible to replace the kernel with one that has the configuration you want it to have.

Sounds like some sort of restricted hardware problem than a kernel problem

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 13:31 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Sounds like some sort of restricted hardware problem than a kernel problem

While you are technically correct, and the GPLv2 license of the kernel allows this, it's zero consolation for the end user who discovers that no, they don't actually "own" their hardware after all.

(...and that there is no "competition" in the "free market" that provices the option for non-restrictive hardware)

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 15:17 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

> While you are technically correct, and the GPLv2 license of the kernel allows this, it's zero consolation for the end user who discovers that no, they don't actually "own" their hardware after all.

That is correct. Perhaps awareness of this problem will create market demand for more open hardware. I don't see how pointing fingers at lockdown patches help however. It's not like manufacturers of said restricted hardware can't simply patch their kernels to enforce restrictions regardless of whether they are upstream

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 22:15 UTC (Thu) by AngryChris (guest, #74783) [Link] (2 responses)

>> Because when you buy a device you don't get to recompile the kernel, and for some devices it is completely impossible to replace the kernel with one that has the configuration you want it to have.

>Sounds like some sort of restricted hardware problem than a kernel problem

You're exactly right. This mechanism simply enforces SecureBoot across the running kernel. This is the kind of thing you *want* if you want SecureBoot enabled. You can disable SecureBoot and disable this feature. The only problem is if the device doesn't let you disable SecureBoot. But that's a problem with the device, not the kernel.

People are looking for persecution where none exists.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 23:26 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> This is the kind of thing you *want* if you want SecureBoot enabled.

Absolutely! It's great.. if you're the device owner. But if you don't have the technical ability to disable SecureBoot, you're not the device owner, which raises all sorts of problems with calling the "purchase transaction" a "sale". (Because "sale" confers rights that you are not getting!)

> But that's a problem with the device, not the kernel.
> People are looking for persecution where none exists.

The problem with absolute statements is that they are trivially disproven.

It is _illegal_ for me to break the lock on systems I supposedly own. Doing so anyway could get me quite literally persecuted. Discussing how to break those locks is also illegal, and yes, folks can and have been persecuted for that. Meanwhile, it is nearly impossible to purchase several classes of devices that are not locked down. They are not locked down for the benefit of the end-user, nor are they always locked down for the benefit of the manufacturer or seller; instead the lock-down is usually for third parties (eg Hollywood) that are not part of the transaction.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted May 4, 2020 12:55 UTC (Mon) by tao (subscriber, #17563) [Link]

It being illegal to break the lock on systems you supposedly own is a *legal* problem though, not a technical problem.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 13:01 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

It's a logic error. If you can't replace the kernel, you do not "own" the device. It's not yours.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 13:59 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

> It's a logic error. If you can't replace the kernel, you do not "own" the device. It's not yours.

We are in agreement that buying the device was a scam. But unless you were born last week, I'm sure you are aware of the real world situation where it is basically impossible to avoid such devices, and those changes are aimed at making such scams easier to perpetrate.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 30, 2020 13:41 UTC (Thu) by pizza (subscriber, #46) [Link]

> So the problem is that even if you can compile a kernel without this option, if you can't run this kernel, it is pointless to be able to disable the option.

One thing worth pointing out is that folks have been shipping locked-down Linux systems for the last 15 years, so Garrett's patch doesn't meaningfully change the status quo.

(FFS, it's still a steep uphill battle to get _source code_, something explicitly required by Linux's GPLv2 license...)