Linus Torvalds Clarifies His Position on Signed Modules 208
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.
Re:Oh, Linus; so adorable when you are angry. (Score:5, Interesting)
"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.
I have a better idea... (Score:5, Interesting)
Replace the kernel idle loop with a UEFI signing key cracker. Let it chow down on Microsoft's key.
Re:Oh, Linus; so adorable when you are angry. (Score:5, Interesting)
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.
Re:Whitehouse Petition (Score:4, Interesting)
Judging by your petition, it sounds like you don't even understand what UEFI is. You just use the phrase "SecureBoot UEFI" repeatedly. Secure Boot is a option in UEFI, which is a replacement for BIOS. Microsoft also requires that vendors make this feature able to be disabled, and allow users to load other, non-Microsoft keys, so your claim that it makes it "difficult, if not impossible to run other OSes" is false. Your silly petition demonstrates a failure to understand the actual issue, and makes factually incorrect and exaggerated claims. You clearly don't understand what's going on.
Re:Oh, Linus; so adorable when you are angry. (Score:4, Interesting)
Re:Oh, Linus; so adorable when you are angry. (Score:4, Interesting)
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.