If you're using a modern machine, then you probably are using Secure Boot. For better or worse, Secure Boot requires Microsoft[+] to sign your binaries and they have certain requirements which you cannot break or they will revoke the signature. One of these requirements is that you cannot have a signed binary load unsigned code into ring-0.
So (ignoring whether these features are useful or good) in order to be able to run Linux on modern hardware these types of features are necessary. And I'm sure you'd be just as annoyed if you couldn't run Ubuntu on a machine that was less than 6-8 years old.
> I wasted a few hours when that Ubuntu thing happened to figure out where that switch was and didn't find it.
It's a shame you didn't manage to find it, because it's pretty trivial to create your own signing keys and enroll them in the MOK. You can then use those to sign your kernels. You just need the sbsign package.
If you want to just turn it all off, it's even more trivial -- go into your BIOS and disable Secure Boot.
I would hope someone who wishes to do some kernel development would be able to overcome this fairly minor hurdle.
[+] Technically it's whoever owns the keys that the manufacturer has approved to run software on the machine. On basically all modern machines that list is just "Microsoft" but you can enroll your own keys or remove Microsoft's keys if you want.
I see arguments (like one of replies to your comment here), that you can turn off Secureboot - so simple, much wow.
Not all firmware allow you to turn off secureboot or enroll your own keys. You’ll see plenty of this on bios-mods.com if you want to know what that looks like. It also really throws into sharp relief questions around things like device ownership.
Let me tell you about my experience with an Amazon DeepLens device (x86-64) that I’ve been trying to get stock Ubuntu installed on. The only keys on this device are Amazon ones. This means I cannot install any OS other than the one they supply (a modified Ubuntu 16.04 install). If I own the device, shouldn’t I be free to install my own OS? If I own the device, and have physical control of it, I should be able to bypass secureboot, period - but not always the case today.
> Not all firmware allow you to turn off secureboot or enroll your own keys.
Being able to disable Secure Boot and install your own keys is a requirement of the Windows 8 and 10 advertising requirements, so manufacturers almost always allow it so they can get some money from Microsoft for advertising.
That doesn't mean it's always possible, but I would humbly suggest that we shouldn't purchase such devices so that companies who make those devices learn to stop doing that. The fact that Microsoft managed to pull this shit with Windows RT is disgraceful.
> It also really throws into sharp relief questions around things like device ownership.
I don't disagree at all, and I do think that it's something we need to be very mindful of. But Secure Boot does solve real security problems.
> If I own the device, shouldn’t I be free to install my own OS? If I own the device, and have physical control of it, I should be able to bypass secureboot, period - but not always the case today.
I completely agree. Amazon shouldn't be allowed to sell such devices. But that doesn't invalidate Secure Boot as a concept, nor is it the fault of Ubuntu or anyone other than Amazon.
I can see how Secure boot solves real security problems. And I am definitely not blaming Ubuntu here.
However, it’s unfortunate that the Secure Boot technology (or maybe this is a licensing thing) by default does not make prescriptions, and that we’re reliant on the device manufacturer’s good will to see it implemented correctly.
> It also really throws into sharp relief questions around things like device ownership.
There's no question about it: it's not ownership if the user doesn't have the keys to the device. The purpose of this technology is to ensure users can't run unauthorized software. Whoever authorizes the software is the true owner of the machine.
There are legitimate applications for this. Whether it's empowering for the user or not depends on how it's implemented. If people can use their own keys to sign the software they trust, it's fine. If they can disable the security, it's fine.
It's a problem when software is authorized by corporations or governments. That means the users of the machine are merely guests who are allowed to use the hardware provided they follow the rules. This is the true purpose of this technology, regardless of any potential benefits for users. The multi-billion dollar copyright industry would love it if this was the default for all computers. It's the only way they can guarantee the artificial scarcity of copyrighted works in the 21st century. Governments would really like to regulate software as well: encryption is far too powerful, it has the potential to frustrate even intelligence agencies and they can't deal with the fact civilians have free access to it.
>it's pretty trivial to create your own signing keys and enroll them in the MOK
Aleksa, I know you are probably aware, but if keys can be added by a user then the mechanism is not really achieving verified boot. The keys need to be burned into a read only portion of memory if we hope to protect against evil maid style attacks. Unfortunately this conflicts with the "user freedom" side of the hardware. Wish there was a good solution for device owners and only device owners to own their keys.
> One of these requirements is that you cannot have a signed binary load unsigned code into ring-0.
I think the requirement is slightly looser - MS won't sign binaries which in turn allow arbitrary unsigned binaries to be loaded/run at ring-0 without any user interaction/confirmation.
The shim and PreLoader loaders used by most Linux distributions allow you to boot arbitrary ring-0 code by requiring user interaction first, and both have been signed by Microsoft. The distribution-specific versions of shim/PreLoader also usually allow booting any code signed by the distribution's own key without needing to enroll that in the MOK.
The process you need to go through, as you describe, is to use shim/PreLoader to first enroll the hashes/keys you want into the MOK variable, then after that's been done once it will all happen without interaction.
> So (ignoring whether these features are useful or good) in order to be able to run Linux on modern hardware these types of features are necessary.
TBH, I find the argument "we are locking down your choice here because of Microsoft pressure" to be ridiculous at best.
The correct arguments should be more in line of "you can turn this off", but these arguments do not answer the very valid question of "what if it is my hardware vendor --like Google -- that is forcing me to turn this on?".
I don't know either, but they will use this sooner or later. And Google specifically: They are not the worst since they tend to address these questions; but they are not the best either since they tend to fall in the "my way or the highway" camp where you can "enable security and let Google control it" or "disable security", lacking the obvious middle option (e.g. the developer switch on chromebooks).
If you remove the write-protection from the read-only flash on Chromebooks, you can replace the verification keys and re-enable security based on your own root of trust.
On modern systems the write-protection is gated via the security chip, which responds to various key combinations. My understanding is that it's possible to re-enable the write protection after flashing and the machine will behave identically (other than that updates from Google will fail to apply due to the system no longer considering Google a trusted authority)
They are necessary to get Microsoft to sign your keys, which is necessary to get Linux distributions to boot on modern hardware without getting the user to install custom keys (and that is a requirement because there is no standard way to configure UEFI Keys -- that's why the mokutils exist).
And I have to stress that they do actually solve real security problems and aren't of themselves a bad idea. The fact that you can inject unsigned code into the kernel as root is not a good thing.
I don't disagree that secure boot can be useful, but the distinction is critical. If you omit all those conditionals and shorten it into a necessity you're basically saying that subjecting yourself to microsoft is unavoidable. It's ceding the entire PC ecosystem to a single vendor, similar to vendor-locked android devices for example.
Unfortunately, it is a practical necessity if you want to have an operating system that the majority of the public can just pick up and use. Yes, I think it's utterly ridiculous that Microsoft acts as the primary signatory for most hardware by default, but pretending that isn't the case won't help distributions ship software.
I wish it wasn't the case, and it is crazy that we have given this power to Microsoft. But that is the current state of the world.
Microsoft is the only company that could have done it. They are the only entity that has teeth through (as you mentioned above) advertising dollars, logo certification programs, etc. Only they had the infrastructure to get the ball rolling. The biggest kicker, the one thing only, and I really mean only Microsoft could do, was provide the infrastructure for revocation. Without their ability to strong-arm (for good or bad), the industry just would have never agreed.
When all it takes is a rogue USB drive and a power cycle to own a machine, it presents serious problems in high security environments.
So (ignoring whether these features are useful or good) in order to be able to run Linux on modern hardware these types of features are necessary. And I'm sure you'd be just as annoyed if you couldn't run Ubuntu on a machine that was less than 6-8 years old.
> I wasted a few hours when that Ubuntu thing happened to figure out where that switch was and didn't find it.
It's a shame you didn't manage to find it, because it's pretty trivial to create your own signing keys and enroll them in the MOK. You can then use those to sign your kernels. You just need the sbsign package.
If you want to just turn it all off, it's even more trivial -- go into your BIOS and disable Secure Boot.
I would hope someone who wishes to do some kernel development would be able to overcome this fairly minor hurdle.
[+] Technically it's whoever owns the keys that the manufacturer has approved to run software on the machine. On basically all modern machines that list is just "Microsoft" but you can enroll your own keys or remove Microsoft's keys if you want.