Slashdot Mirror
Linus Torvalds Clarifies His Position on Signed Modules
An anonymous reader writes "No one, but no one, in the Linux community likes Microsoft's mandated deployment of the Unified Extensible Firmware Interface (UEFI) Secure Boot option in Windows 8 certified PCs. But, how Linux should handle the fixes required to deal with this problem remains a hot-button issue. Now, as the debate continues hot and heavy, Linus Torvalds, Linux's founder and de facto leader, spells out how he thinks Linux should deal with Secure Boot keys."
And it's not in the control of Microsoft: distros should sign only the modules they provide with their key, with user built modules signed by locally generated keys (since, as SSL certification authority break-ins have shown, centralized trust systems are prone to abuse and offer dubious security benefits). Basically, no love for proprietary kernel modules.
What are you smoking? He just provided guidelines for using keys while running Linux. He didn't say UEFI is evil, he just doesn't want sign off the ability to boot Linux on UEFI+Secure Boot to some big company.
> not because this actually does anything at all to inconvenience Linux users.
Ummm ... not necessarily. Linus is concerned about two things:
1. That a Microsoft-signed Linux secure boot key could be used to hack systems. Microsoft could disable the key, which would then disable *Linux* systems. We can argue about whether Microsoft would actually do this, but understandably, Linus isn't excited about placing that kind of power in anyone else's hands.
2. Linus also says, "Before loading any third-party module, you'd better make sure you ask the user for permission. On the console. Not using keys."
Linus can be a tyrant and an anus, but I like where his heart is at. The best quote is this Linux's approach to UEFI is (again quoting), "based on REAL SECURITY and on PUTTING THE USER FIRST."
Agree or disagree, don't just dismiss this as the usual "Microsoft bashing." I'm not a Microsoft hater; we use their stuff alongside F/OSS all over our workplace. I prefer Linux, but I don't hate Microsoft. But I am very concerned about this whole UEFI thing and the way it's shaping up.
So is Linus ... and in his usual, inimitable fashion is telling everyone how he feels. :)
Cogito, igitur comedam pizza.
Could microsoft refuse to sign a uefi binary because it violated their patents? If so, this could be a way to get everyone using linux to pay them.
Microsoft's OEM stranglehold is so 1998. Now the Linux kernel is everywhere surely we now have a much stronger case against Balmer and his shills.
See, you're misunderstanding that: Microsoft made two mistakes that caused that lawsuit. The first was browser bundling. The second was failing to grease the right palms in Washington. They learned their lesson, began giving out the campaign donations, and all of a sudden the case went from seriously considering the breakup of the OS and application divisions to a settlement that amounted to a slap on the wrist.
My take is that we're probably going to end up with instructions on how to disable secure boot, but it may involve soldering or other physical modifications.
I am officially gone from
"you can load keys of your choice"
I think this is the biggest, and most complained about, assumption in all the debacle. If it was true, the Microsoft key issue wouldn't exist (we'd just have a "Linus key" and that would be the end of it).
Sure, MS give lip service to this but there's nothing that guarantees it will be available. Nothing at all. You can turn Secure Boot off, but then you've had BIOS engineers working on a feature that you then turn off because it doesn't work as you need it to.
But nothing guarantees that every user will ever be able to add a key to their own machines, nor that machines would ever come supplied in a way that would ever suggest that's what needed.
Having just fixed a 2012-issue BIOS bug a few months ago, and it being pretty much par for the course with even the larger consumer manufacturers to have such bugs, I don't trust that a BIOS option to enter a key I trust will be present in machines before I've bought them.
The bug I reported (and had to get a custom BIOS patch for)? A whole series of laptop machines from my normal supplier, using big-name BIOS's, motherboards, and other components (and Windows 7 stickers on them!), would refuse to boot if a certain offset on the selected bootable partition on the first disk was not zero.
That offset is actually always zero on a plain Windows NTFS drive. On Linux, or any other filesystem, it is not. On any encrypted system - even with an NTFS partition - (we discovered the problem using Truecrypt), it was not.
You could not fake partitions and juggle them around - whatever the bootable partition was was checked, no matter what the filesystem signature on it. God knows what happens if you use GPT and equivalents. Even chain-loading from partitions was next-to-impossible to set up with booting into an encrypted Windows setup (you would have to boot from an unencrypted NTFS partition into an encrypted one somehow and even playing games with syslinux etc. it was too difficult to even demonstrate a single working example, let alone deploy company-wide) .
Any non-zero byte in that position on the disk, which could be verified with a hex-editor on a blank disk, rendered the machine unbootable. Black screen, no boot options, no truecrypt loader, it just stopped. Zero the byte and it would happily boot again.
Yes, it's stupid and it SHOULD NOT HAPPEN. But only our threat of sending many thousands of pounds worth of laptops back because they did not fulfill the stated purpose actually prompted the reseller to nudge the manufacturer to nudge the board supplier, to nudge the BIOS supplier, to hack up a dirty patch to their BIOS labelled with all sorts of beta /not for distribution / etc. warnings. And even that, it was a close run thing because the reseller was ready to just say "not our problem, it runs Windows which we supplied with it" at any second and only the threat of a lot of future business prompted any sort of action from them.
UEFI just puts an unnecessary burden of responsibility onto BIOS manufacturers and Microsoft. And the vast majority of BIOS manufacturers (even AMI, Pegasus, etc.) are inherently bad and aim at making machines that boot only Windows and then walk away saying "not my problem". Try finding a machine with valid ACPI tables, the problem has actually got WORSE since ACPI become commonplace and in every machine.
Samsung only the other week had a problem where a BIOS issue can cause a complete machine bricking no matter what the OS, but Windows triggers it less because it doesn't do certain things that are perfectly reasonable to do by the standards.
Nobody *cares* what *SHOULD* work. They care what could *NOT* work. And relying on your BIOS manufacturer to be able to boot Linux successfully is, historically, one of the most contentious areas of computer manufacture ever.
Instead of screwing around with politics, I have a much better idea...
Replace the kernel idle loop with a UEFI signing key cracker. Let it chow down on Microsoft's key.
Lol. Just disable "Secure Boot". Thats your choice right there (AFAIK the disable option is in the Microsoft secure boot spec).
The issue is to run Linux WITH SECURE BOOT ENABLED.
Especially some big company that has already been hacked and had its certificates compromised in the past.
Seven puppies were harmed during the making of this post.
I think this entire issue needs to be looked at by the Attorney General and Federal Trade Commission. The SecureBoot UEFI is nothing more than a form of vendor lock-in, cleverly (or not so much) disguised as a security innovation. Please sign my petition and spread the word: http://wh.gov/wHLq
They're not adopting Windows 8 because on the whole, Windows 8 sucks or doesn't offer a compelling reason to upgrade. That does not mean that Microsoft will remove secure boot from future operating systems, since most of the drones have no idea at all what it means or what it does, and don't care. If their $500 computer stops working they say "it had a virus" and throw it away and buy another one.
Seven puppies were harmed during the making of this post.
Microsoft = small, soft
Their business model has outgrown the company name. They are big and hard. So big, that they can get by with some shit like this. Hard because their head is hard.
Them getting with the hardware designers and creating this secure boot shit, just so it's harder for pirates to pirate a copy of windows8, is the same thing as GM getting with the folks that make roads, and have them install a switch that can disable ALL CARS if GM decides. GM can just state, "What if a GM car is stolen? How are we supposed to be expected to recover the losses?"
So here is another car manufacturer saying that he's not willing to put the GM parts into his cars. That's all. Our world's problems are getting so stupid, that it's sorta hard to tell/believe what's going on.
I think everyone should read the lyrics to "Wish You Were Here" by Pink Floyd. Or maybe another band should release a song called "I wish we weren't here". Again, hard to tell...
"Sure, MS give lip service to this but there's nothing that guarantees it will be available. Nothing at all."
Yes, there is. I quote http://msdn.microsoft.com/en-US/library/windows/hardware/jj128256, "Windows Hardware Certification Requirements for Client and Server Systems":
"Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults. On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled."
No one, but no one, in the Linux community likes Microsoft's mandated deployment of the Unified Extensible Firmware Interface (UEFI) Secure Boot option in Windows 8 certified PCs.
I don't believe this. There's always one lunatic out there so in love witn Microsoft "technologies" that they'll love this. Miguel?
SJW n. One who posts facts.
"That a Microsoft-signed Linux secure boot key could be used to hack systems. Microsoft could disable the key, which would then disable *Linux* systems. We can argue about whether Microsoft would actually do this, but understandably, Linus isn't excited about placing that kind of power in anyone else's hands."
You're actually reading Linus' argument exactly backwards.
Howells and Garrett argue that revocation is a significant possibility, _therefore_ we (distributions) need to do kernel module signing (because unsigned kernel modules are an attack vector against a Windows install on the same system). One strand of Torvalds' argument is that MS is never going to revoke any keys anyway, therefore we (distributions) don't need to bother. There are other strands to his argument, but that's how the revocation one goes. That's what http://marc.info/?l=linux-kernel&m=136185309010028&w=2 is about: key revocation is what he describes as an 'unlikely and bogus scenario'.
It's important to note, though, that Linus isn't saying this just because "Itz Micro$OFT OMG run!11!!" Another nice quote from Linus:
"Encourage things like per-host random keys--with the stupid UEFI checks disabled entirely if required. They are almost certainly going to be *more* secure than depending on some crazy root of trust based on a big company, with key signing authorities that trust anybody with a credit card. Try to teach people about things like that instead."
Like I said elsewhere, Linus can be a big, furry anus, but all he cares about is his baby: the Linux kernel, keeping it free, and giving maximum freedom to the *USER*. I like that.
Cogito, igitur comedam pizza.
Somebody gets it:
Imagine if someone invented a protocol like ssh, but then suggested that of course, nobody should be able to use it except in situations where a host's key is signed by one of the global CAs, like we do on the web except without the possibility of self-signing or for new CAs to enter the market.
Nobody would call that "secure." They would call it a joke which goes out of its way to be less secure, by deliberately adding an untrustable link. And the fix to such a protocol would be obvious. Well, that's just what Linus did in the above paragraph: he told you how to turn SecureBoot from "just plain stupid" into "decent even if still mostly useless."
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
act like his wants and opinions are more important than anyone else's.
Actually, when it comes to the Linux kernel, his opinions are more important than anyone else's, because he has final say on it.
If Linus doesn't like the Intel/MS control over UEFI then let him conjure up a viable alternative and get it to market.
Like he does in the linked article?
It is still far preferable than giving control to anyone else.
His opinions regarding Linux are more important than anyone else's. I know you don't like it but that does not make it less true. And the best way to deal with UEFI is to disable it. Simple as that.
... he just doesn't want sign off the ability to boot Linux on UEFI+Secure Boot to some big company.
But I'll be you he would love to have control of it himself.
No: From TFA:
Torvalds concluded, "It really shouldn't be about Microsoft blessings, it should be about the *user* blessing kernel modules. Quite frankly, *you* are what the key-hating crazies were afraid of. You peddle the "control, not security" crap-ware. The whole "Microsoft owns your machine" is *exactly* the wrong way to use keys.
He goes on to give details of how this would work (each distro has a key and users have to explicitly grant permission to install non-distro apps)
Now read what you wrote.
"It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. *****This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.******"
So the minimum requirement is that you can delete all the keys.
"If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off."
So when you delete the keys, SecureBoot is turned off.
There's also an option to always put the Microsoft key back in place. But that's it. At no point does it guarantee that you can enter an arbitrary key and keep secure mode on. Which is basically what I said.
And "possible" can be provided by means of, say, a supplied disk available at extra cost from the manufacturer that has to be inserted for such action to be taken at all.
Lip service.
The second was failing to grease the right palms in Washington. They learned their lesson, began giving out the campaign donations, and all of a sudden the case went from seriously considering the breakup of the OS and application divisions to a settlement that amounted to a slap on the wrist.
Quoted for emphasis. Microsoft dramatically increased their campaign contributions at the same time they were being prosecuted by the DOJ. It's a perfect example of how corrupt this government has been for decades.
Give me Classic Slashdot or give me death!
Given the evidence of history, it's simple common sense.
"I've got more toys than Teruhisa Kitahara."
It's like democracy. It sucks but is better than everything else.
And if a user 1) lacks the technophilia to be the right person to do it, and 2) lacks the wisdom to defer to another party of their choosing (e.g. a distribution maintainer), then they are a lost cause anyway. There is no solution that is ever going to make their machine secure.
The neat thing about Free OSes is that there are many ways to approach #2, whereas proprietary OSes these days, insist that you must defer to someone (there is no option #1) and may not choose to whom you will defer.
If you happen to think that The One Party to whom you must defer, is unusually trustworthy and competent, then it seems fine. People who look at track records, though, will question the choice, and eventually it always leads to "of course they make it so that you have to trust them; if the choice were left to the computer's owner, they would never choose that company again."
Maybe it's all ancient history to you, but to me, these are the people who thought ActiveX ought to be in web browsers. These are the people who thought an OS should ship such that, by default, it loads and executes code from a CDROM when you insert it. These are the people who still (AFAIK, maybe I'm starting to get out of date) use file names (extensions) instead of permissions, to determine if a file is executable. These are the people who (again, AFAIK, maybe my prejudice is showing) basically invented the idea of a full-fledged programming language engine being in spreadsheets and word processors, which will load and run the code in a document when you load the document. Etc, etc, etc.
I would say that this one company, more than any other that we've ever heard of, has the least credibility if they ever say uneducated users shouldn't be in charge of security. Even an uneducated user isn't likely to make worse choices than Microsoft has. And now they want to be The One global root CA for all code, even outside their own OS. I would say that'd be the funniest thing ever, but then I heard something even more hilarious: some people are taking their proposal seriously.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
So the minimum requirement is that you can delete all the keys.
Wrong. There is no requirement that you *explicitly* can enter UEFI Setup Mode. The system vendor MAY allow such an explicit option, but the MINIMUM requirement is that he MUST allow Setup Mode to be entered by deleting all keys.
Read what you quoted again, please:
1) It SHALL be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
2) This MAY be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), WHICH puts the system into setup mode.
So the owner of the system can ALWAYS enter setup mode. He may have some direct way to do that, but he can ALWAYS delete the key databases, which will cause the system to go into UEFI Setup Mode.
"If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off."
So when you delete the keys, SecureBoot is turned off.
Correction: When you delete the keys the system enters Setup Mode. If you choose to exit the automatically invoked setup mode WITHOUT entering a new platform key, THEN secure boot is turned off. Which makes perfect sense as there are now no keys in the firmware which could validate anything.
There's also an option to always put the Microsoft key back in place. But that's it.
No, you can enter ANY key into the Platform Key database. From http://lwn.net/Articles/447381/ : "Before a PK is loaded into the firmware, UEFI is considered to be in "setup" mode, which allows anyone to write a PK to the firmware. Writing the PK switches the firmware into "user" mode. Once in user mode, PKs and KEKs can only be written if they are signed using the private portion of the PK, though KEKs can be freely written during setup mode. Essentially, the PK is meant to authenticate the platform "owner", while the KEKs are used to authenticate other components, like operating systems."
At no point does it guarantee that you can enter an arbitrary key and keep secure mode on.
And you are wrong. The PK (Platform Key) is the "owner" key. You can enter your own key if you like.
Which is basically what I said.
But you were mistaken.
And "possible" can be provided by means of, say, a supplied disk available at extra cost from the manufacturer that has to be inserted for such action to be taken at all.
Lip service.
So, basically you are spreading FUD: *Fear* that it may incur extra costs, *uncertainty* because you choose to disregard facts and present your own speculation and conjecture as facts, and finally *doubt* as to the "real" intentions behind secure boot.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Windows 8 isn't doing as well as Vista did.
act like his wants and opinions are more important than anyone else's.
Actually, when it comes to the Linux kernel, his opinions are more important than anyone else's, because he has final say on it.
True, but it's worth considering why it is that he has the final say. Sure, it was his baby originally, but 20 years later, Linux is an asset worth billions to many big companies with deep pockets and lots of top-notch engineers -- and it's GPLd. If, say, IBM wanted to they could fork the kernel and push their fork farther and faster, make it better-tested, more featureful and more reliable than Linus' fork. They could adopt better policies that would make contributors happier, and Linus would quickly fade into irrelevancy.
Or could they?
The fact is that Linus is still in charge of the 800-pound gorilla that Linux has become for one simple reason: he does a great job. He makes good decisions, manages the process well, and generally keeps things moving along well enough that no one is really even tempted to seriously try to fork the kernel in a way that pushes Linus out of the picture.
What all of that means is that his opinions are more important than anyone else's because he has good opinions. Not that he's perfect (in fact I can name a number of things I strongly disagree with him on), but by and large, what he says on kernel-related topics is worth listening to on its own merit. And because he has final say on it.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.