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, Informative)
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.
Re:Oh, Linus; so adorable when you are angry. (Score:5, Informative)
Re:Bravo Linus! (Score:2, Informative)
You do, of course, realize that "UEFI" and "Secure Boot" are neither synonymous, nor mutually inclusive, right? UEFI has been replacing BIOS for almost a decade - obviously, you're a bit out of date when it comes to the state of desktop hardware. Secure Boot is just a single available setting in UEFI, and there's nothing in the current or proposed implementations that requires you to use it.
Re:Oh, Linus; so adorable when you are angry. (Score:5, Informative)
"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 [microsoft.com], "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."
Re:UEFI (Score:5, Informative)
"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 [marc.info] is about: key revocation is what he describes as an 'unlikely and bogus scenario'.
Re:Oh, Linus; so adorable when you are angry. (Score:5, Informative)
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?
Re:Oh, Linus; so adorable when you are angry. (Score:5, Informative)
... 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)
Re:Oh, Linus; so adorable when you are angry. (Score:5, Informative)
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/ [lwn.net] : "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.
Re:Funny (Score:5, Informative)
Windows 8 isn't doing as well as Vista did.