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.
Funny (Score:2)
Re:Funny (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Re:Funny (Score:5, Informative)
Windows 8 isn't doing as well as Vista did.
Microsoft and patents. (Score:5, Insightful)
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.
Re: (Score:2)
Microsoft can refuse to sign a UEFI binary for any reason they choose. Signing other people's binaries is an offer they are making voluntarily, not something anyone else is requiring them to do, therefore they set the terms.
Re: (Score:2)
Re: (Score:3)
And there are provisions for revoking signatures. AIUI, they can be even be distributed through something like Windows update (as long as the revocation is signed by MS), and certainly the revocation lists would be on new hardware. That is what people are worried about.
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: (Score:3)
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.
More promising option would be to just collect money and bribe someone inside MS to hand us the key.
Re: (Score:2)
I applaud your sentiment, but unfortunately, unless they have badly messed up (and I expect they got competent outside help for this to prevent messing up), cracking this key will not be feasible.
Re: (Score:2)
Most clueless comment today!
If course, if you ignore reality, every key can be brute forced (oh, wait, no, there _are_ cryptosystems that cannot be brute-forced). There is also the slight problem that this universe seems to be finite and have a finite amount of matter and energy in it, which incidentally is not even enough to brute-force AES-256.
At least get a minimal clue before making such stupid statements.
Whitehouse Petition (Score:5, Insightful)
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.
Microsoft (Score:5, Insightful)
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...
No one? (Score:4, Funny)
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?
woohoo! (Score:5, Insightful)
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."
Re: (Score:2)
Windows 8 certification guidelines [microsoft.com], specifically System.Fundamentals.Firmware.UEFISecureBoot Para.17:
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.
Para.18:
Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.
Re: (Score:2)
I think that if they had left that out, a few billions in fines form the EU would have reminded them of it. They are just being careful, well knowing that it is beyond most users at this time to add their own keys.
I will be very interested though what happens to their anti-competitive move on ARM though.
Re: (Score:2)
Indeed. You have it exactly right. Side note: SSH does support public X.509 certificates but nobody uses them as anybody competent enough to do that also sees that this does not help. SSH with private X.509 certificates is in use.
Re: (Score:2)
It would, by virtue of creating a whole new set of reasons it might fail of get replaced with telnet on a server.
CAs ARE worse than the random host key. Just think of all those AWS and other instances. Imagine the temptation to just use telnet rather than just senmding all your money to Verisign.
Re: (Score:2)
Requiring a global CA to sign a ssh key would in no way make it less secure. It can't.
The OP was apparently talking about a scenario in which the client is hard-wired to only trust host keys that have been signed by a specific, global CA. And that would be less secure. You would no longer be able to just create and use your own host key at any time.
Re: (Score:2)
Requiring a global CA to sign a ssh key would in no way make it less secure. It can't. If it could, the whole system is broken even without the CA's involvement. The CA is just another verification factor.
You really have no clue, do you? First, global CAs do not "sign" keys, they create keys and sign them. A little often overlooked detail is that having CAs in the X.509 systems sign user-generated keys is very hard to get right and a lot of effort and hence nobody does it. Have a look into the literature. Anybody that does understand the X.509 PKI actually know this, but you do not seem to. The second thing is that any false signature decreases the system security, unless nobody trusts this signature in the
No goatse? (Score:2)
I was expecting the link to take me to a goatse image. Maybe the article is really just an euphemism.
Re-license Linux (Score:2)
Just change the Linux operating system license from GPLv2 to proprietary and thats it!
And while doing it, just copyright all source code for Microsoft same time.
Then justice would be served...
(Yeah, just trolling as I don't have anything better to say).
That's a whopper of an aside .... (Score:2)
Since, as recent hospital deaths due to MRSA and medical errors have shown, centralized medicine offers dubious health benefits?
Just because there have been failures doesn't make the system dubious at all. Even with all the failures accounted, SSL is a phenomenal success -- effectively protecting billions in eCommerce revenue, trillions of emails and untold other secret
Re: (Score:2)
It would be if it actually existed. As is, Joe needs to understand that if his browser starts giving security warnings, someone's probably trying to steal his credit card info. Joe also needs to understand that SSL can't protect him if he visits sites through links (because they might direct him to amaz
Re: (Score:2)
The public X.509 PKI (what is used for SSL) is fundamentally broken. There are still a lot of people that do not get security and think otherwise, but those of higher competence in the IT security field have reached this consent a while ago. There is no-one with any credibility that disputes this. And it is not that the system has been broken in a surprising way that is unlike to happen again. The system has failed in the expected way and will fail time and again, because its architecture is fundamentally b
Re: (Score:2)
I'm 100% certain that my connection to Gmail is protected by SSL/TLS, so I think you have to troll harder than merely saying that it is "unsuitable for email protection".
Linus is right (Score:2)
Saying things like " If the user has explicitly enrolled a hash then they're stepping outside the trust model." indicates gross incompetence and fundamental non-understanding what security is. After all, all security must always reference back to the user as it is the user (and nobody else) that decides which OS/hardware/mechanism to trust in the first place. That initial security decision overrules all other considerations. If the user cannot be trusted, then all conceivable systems are broken from the sta
No one, but no one (Score:3)
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: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:Oh, Linus; so adorable when you are angry. (Score:4)
Re: (Score:3)
I'd say end users who are at a minimum configuring and compiling their own kernel modules are rather educated.
Re:Oh, Linus; so adorable when you are angry. (Score:5, Insightful)
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.
Re: (Score:2)
And than apple waltzed in with the same "there is no option 1, trust us" model with iOS, and while it hasn't been perfect*, it is certainly a million times more secure out of the box than anything Microsoft has accomplished.
*apple is a bit too draconian in what they do and do not allow in the app store (porn and bitcoin right off the top of my head) and there are still enough security holes that advanced users can still force option 1 by jailbreaking/rooting through exploits.
Re: (Score:2)
I never said it was OK for either company. stop putting words in my mouth.
Re: (Score:2)
That is marginally accurate of an Ubuntu user, but the other distros are still popular and have only been gaining users since Shuttleworth started sodomizing his userbase.
Also it misses the point entirely. Distro maintainers should decide how and why UEFI is used. It shouldn't be baked into the Linux kernel, and if you want to build your own kernel, then it's something you should decide yourself.
Re: (Score:2)
So what have you, oh AC, accomplished then that gives you the ability to judge his ego? His being the leading figure in one of the largest distributed projects in human history not enough for you?
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, Insightful)
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.
Re: (Score:2)
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.
True, but chances are there is somebody better. Linus got the ball rolling, but how much of that was due to personal awesomeness vs. pure luck and being in t
Re: (Score:2)
Red Hat maintains its own kernel. They can put whatever they want in it. Linus maintains his own kernel, and if people want to try and force him to include things, they have another thing coming. I don't know why that's so hard to understand. No one uses Linus's branch of Linux because they have to.
Re:Oh, Linus; so adorable when you are angry. (Score:4, Interesting)
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: (Score:3)
... 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. He's done a lot of good for computing in general, but his ego and attitudes often eclipses his accomplishments.
No he does not want control of this or any thing on the users machine. That is his whole point. He wants the user to be in control not some 3rd party.
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.
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: (Score:2, Insightful)
Except Microslop could change what passes for their mind tomorrow and there would be no recourse.
Re: (Score:3)
Re: (Score:2)
Everyone locks down ARM. It sucks when Microsoft does it, but no more than when Google does it (you can't boot whatever you like on ARM Chromebooks), or Samsung, or Apple, or...
If you want to run Linux on an ARM machine, don't buy one with Windows on it, sure.
Re: (Score:3)
you can't boot whatever you like on ARM Chromebooks),
Yes you can.
Re: (Score:2)
Sorry, you're right. I had somehow got the idea that dev mode wasn't available on the Samsung, but it is.
Chrome OS dev mode is more restrictive than MS' x86 Secure Boot requirements - see http://mjg59.dreamwidth.org/22465.html [dreamwidth.org] - but it is indeed less restrictive than MS's *ARM* SB requirements. So indeed an ARM Chromebook is relatively a better choice than an ARM Windows RT device.
Re: (Score:2)
Everyone locks down ARM. It sucks when Microsoft does it, but no more than when Google does it (you can't boot whatever you like on ARM Chromebooks), or Samsung, or Apple, or...
Have you not noticed that tablets and smartphones are dissolving away the PC market? There won't be a big consumer market for x86 for much longer. "It's just ARM" is a really shortsighted assessment.
Re: (Score:2)
That's why I didn't make it. And yes, I have noticed that, but SB doesn't really seem like the logical place to make your glorious stand on the issue, to me.
Re: (Score:2)
ARM hardware often has different financial models. It certainly has different cultures. I don't think we should think of them as a unit. You can support or oppose more open ARM entirely separately from the x86 discussion.
Re: (Score:2)
You can support or oppose more open ARM entirely separately from the x86 discussion.
You cannot support Microsoft without supporting locked-down ARM platforms, because they are free to share money across their various divisions. That's why you must consider a corporation as a single entity. They insist we do so, but so does reality.
Re: (Score:2)
Most governments can tax or subsidize as they will. So they are free to move money from one entity to any other entity. We don't say that doing any business with a society is supporting everything that society does. We weigh the complexities against one another.
Microsoft is mildly advancing lockdown on ARM. They are taking an already moderately locked down platform and further entrenching lockdown. On x86 so far they are providing a slight move towards avoid OS level hacks, a bit more security with lit
Re: (Score:3)
They probably aren't going to be the only signing authority on most machines. For example if you were to buy a Samsung laptop, Samsung might decide to have their own master key. I'd assume China is going to want their own master keys. I'd assume for the EU there is going to be someone other than Microsoft, say Unisys.
Re: (Score:2)
They probably aren't going to be the only signing authority on most machines. For example if you were to buy a Samsung laptop, Samsung might decide to have their own master key.
That's true. Now, will Samsung decide to use it and risk incurring Microsoft's wrath?
Re: (Score:2)
Microsoft doesn't expect to be the unique signing authority. They are trying to make sure there is one and acting as one. But they aren't really well setup for it. I don't think there would be any wrath if Microsoft could step away entirely from the signing business.
I'd assume Samsung's prime reason for supporting it would be for Android on x86 and Tizen development.
Re:Oh, Linus; so adorable when you are angry. (Score:4, Insightful)
Given the evidence of history, it's simple common sense.
Re: (Score:2)
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.
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: (Score:3)
"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":
Now please inform us as to under which conditions windows hardware certification may be revoked.
Re: (Score:2)
Why are you quoting from "Windows Hardware Certification Requirements for Client and Server Systems"?
How that can be applied to Linux or other systems? And more important, how it prevents Microsoft from changing those requirements?
Re: (Score:2)
Hardware ships with terrible firmware! Film at 11!
It is my previously stated opinion that the firmware engineers' union lists 'deep familiarity with a crack pipe' as a minimum baseline requirement for joining, so this shouldn't really _surprise_ anyone. Secure Boot sucks insofar as it's another firmware mechanism for the firmware engineers to fuck up, but it's not like we're _short_ of those.
Re: (Score:2)
Pick up the phone and ask the manufacturer. That's rather classic, what support is for.
Re: (Score:3)
but Windows triggers it less because it doesn't do certain things that are perfectly reasonable to do by the standards.
I do love how someone effectively wrote a "brickme.exe" for windows to prove this point. That shows some real dedication. I wonder how many times he tested it.
Re: (Score:2)
I think you are missing a layer here.
BIOS contains a key signing authority which signs keys which allows an OS to load.
The Microsoft key exists as an authority. There will probably be some fixed number of signing authorities.
In theory distributions could just pay a nominal fee (about $80 from Microsoft for example) per kernel and get signed.
RedHat decided that was a bad idea since they still wanted to support roll your own kernels without end users paying $80 per kernel and so they invented the shim system
Re: (Score:2)
Calm down. First off that's not Microsoft. They didn't write your BIOS. Second, the BIOS loads before the operating system so there is no way to "brick" a system like that. Just call the manufacturer and find out what the correct key is to get in.
Re:UEFI (Score:5, Insightful)
> 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. :)
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: (Score:2)
I'm not thrilled witht he manufacturers controlling the keys either, but I will agree it makes *more* sense. Just not much.
Re: (Score:2)
Microsoft chose to provide SB keys because it wants to. Anyone can provide SB keys. You can, if you like; knock yourself out. The trick is in persuading hardware manufacturers to ship with firmwares that trust your keys.
Anyone could step up and offer to provide SB keys for other operating systems, and try to get hardware vendors to ship them. So far, no-one has done so. Red Hat does not want to because a) we don't want to be seen to be in a position of privilege versus other distribution vendors, and b) Red
Re: (Score:2)
Linus can be a tyrant and an anus, but I like where his heart is at.
He's an asshole, but an asshole that gets shit done.
Kidding aside...
The best quote is this Linux's approach to UEFI is (again quoting), "based on REAL SECURITY and on PUTTING THE USER FIRST."
Indeed. Too many people seem to be focussing on the technical details and not on how this will actually work. UEFI can be OK (though I don't really see the improvement over Open Firmeware or Coreboot, but that's another discussion).
Sure, you can disable
Re: (Score:2)
What people want it to load an OS on to their computer with minimal fuss, which means having the signed bootloader, signed by Microsoft.
The entire complaint is silly because of this very fact. The user purchased a windows certified computer with secure boot so amazingly its easy to install windows. This isn't some shocking revelation here.
You can choose what to buy and what not to buy. Your continued complaints just prove to rational peop
Re: (Score:3)
Again, you're focusing on the technical details and ignoring what actually happens. ..and the reason that this is the case is because the user purchased a windows certified computer. If the user didn't want to run windows, then why did the user buy a windows certified computer at all?
Seriously, you actually asked that? Where the hell can you but a non Windows certified motherboard?
The entire complaint is silly because of this very fact. The user purchased a windows certified computer with secure boot so ama
Re: (Score:2)
Diverse inexpensive hardware in the hands of hostile end users is not trustworthy.
But... additional layers of security do make a difference. iOS has had far fewer problems that Android not because iOS is inherently more secure that Dalvik, probably the opposite, but a few extra layers of security and management. Internet browsers today are vastly more secure than those 15 years ago because of extra layers. Layers matter.
Re: (Score:2)
Microsoft could disable the key, which would then disable *Linux* systems.
Future Linux systems, until a new key is obtained. Unless you're suggesting that Secure Boot will connect to the Internet to obtain a CRL.
Re: (Score:2)
What do you think will happen when Windows Update runs on the Windows 8 install on the other partition?
Nothing, idiot. The keys are not programmable outside the bios config. If they were, Linus's argument would be even more silly.
Re: (Score:2)
I doubt that he's clueless, and I suspect that astroturfer is more precise than troll.
Please remember that not all anonymous cowards are the same person, or represent the same entity.
Re:Challenge in court? (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Which is great until you boot into the legacy BIOS setup and find just 1 option - Enable UEFI. Only seen one claim for that so far but it would be foolish to think this won't happen, it's not forbidden by Microsoft rules.
If you're lucky that board will work with all your hardware without tweaking any settings. If you're really lucky they'll update the legacy firmware side with fixes and new hardware support and won't just orphan it.
Do you feel lucky punk?
Re: (Score:2)
Only seen one claim for that so far but it would be foolish to think this won't happen, it's not forbidden by Microsoft rules.
But neither is it required, or even implied. It would be entirely up to the OEM to implement. Who could do the exact same thing right now with existing non-secure-boot UEFI firmware, or even BIOS, if they so wished.
But they won't, because they're not blithering idiots.
Re:Challenge in court? (Score:4, Insightful)
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.
Re: (Score:2)
If one wants a *nix machine, I presume that anyone can go over to newegg and buy whatever parts needed to build a *nix machine. It would probably cost more than the $500 that a Windows
Re: (Score:2)
Browser bundling was engaging in unfair competition. Microsoft has been working aggressively and cooperatively with Linux vendors to provide alternative solutions and helping to make sure they don't engage in unfair competition. Far from a stronger case, there is no case.
What everyone is upset about is stuff Microsoft could potentially do, not stuff they are doing. Well, in America, you don't get convicted for potentially being able to do bad stuff, at the very least you have to start taking steps towar
Re: (Score:2, Insightful)
What a bunch of hyperbolic twaddle.
Re: (Score:3, Insightful)
The issue is to run Linux WITH SECURE BOOT ENABLED.
Re: (Score:2)
Re: (Score:3)
No.
http://arstechnica.com/business/news/2012/01/microsoft-mandating-secure-boot-on-arm-making-linux-installs-difficult.ars [arstechnica.com]
Re: (Score:2)
So? It means you can't run any other operating system on ARM because of secure boot. But all of this doesn't matter because Microsoft only needs to make a small change in it policy and then all x86 devices are locked out.
Re: (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: (Score:2)
What the? do a search for 'tivoization'. It's a sticking point with Linus and RMS regards GPLv3.
Want to know why Nexus phones are so popular? Because historically numerous Android vendors supplied locked bootloaders, so if you wanted to install Cyanogenmod on them you required an exploit and even then couldn't compile your own kernel.