"We believe that the intention of secure boot is to protect against
malicious use or modification of pre-boot code, before the
ExitBootServices UEFI service is invoked. Currently, this call is
performed by the boot loader, before the kernel is executed.
Therefore, we will only be requiring authentication of boot loader
binaries. Ubuntu will not require signed kernel images or kernel
modules."
That's completely different from what Fedora is doing (signing all kernels and modules). I hope for them Microsoft agrees with their interpretation and won't revoke their signed binaries. I'm not sure what advantage they would get from a signed boot loader, if you can run any arbitrary kernel from within the loader.
I was wondering about this too. From the user's perspective, this is great, as it basically means that everything downstream from the custom UEFI bootloader can be unsigned, user-defined code.
But at the same time, it pretty clearly defeats the purpose of the UEFI signature chain. A plausible malware vector would thus be to install the ubuntu loader, which then loads your malware payload and chains to windows, compromising the "secure" boot.
Basically, it undoes secure boot entirely. Which is a good thing. I hope Microsoft is willing to look the other way on this, but I fear that they are not.
A technical user, sure. But that's an awfully big step down in security guarantees: "Hardened, secure boot with guaranteed validity and authentication at each step." to "Wait, did we install Ubuntu on this box?"
Also it could have the effect of associating the Ubuntu splash screen with malware in the users mind. Given that many users associate a black linux commandline prompt with malicious hackers, this might cement in their minds that linux is bad.
They should have a splash screen saying: "Now booting Ubuntu Linux. If one of the next screens says "Welcome to Microsoft Windows", your system is probably infested with malware.
Who says "the user" will see that splash screen? Firstly, I think typical users will switch on their PC, then look elsewhere for a minute or so. Secondly, there is the case of having a nefarious sysadmin (Internet cafe, hotel, etc)
A splash screen that required acknowledgment would work for case #1, but would be annoying, too.
I don't see how. Flame managed to create signed malware with an MD5 prefix attack... but MD5 had known problems for over 10 years.
And Flame is widely thought to have been produced by a government intelligence service -- it still takes massive talent and CPU time to do something like that.
I'm not aware of any MS private key ever being leaked or cracked.
There will be weaknesses in specific UEFI implementations, but I don't think they'll be able to produce anything general purpose.
I think the point was that Flame was signed with a Microsoft key.
It's true that key shouldn't have been trusted for what it was used for, and that the MD5 attack basically elevated the rights of the key, but the parent's point isn't 100% wrong (nor is it 100% right..)
Flame used a prefix collision attack that had not been seen before. The concept was demonstrated a couple of years ago but the attack itself was novel.
While that's true, what enabled Flame to use that to sign code was a chain-of-trust mistake as nl pointed above -- and there's no guarantee that such chain-of-trust mistakes will not happen in the future.
Not every malware, but does, for instance, the NSA run Microsoft signed binaries or are they able to sign their own? If they have valid signing keys, how much can you trust they (and other agencies) will always use those keys for your own good (and that you'll agree it's for your own good) when they use them.
I think you need to be more careful with that argument. While I agree in principle that this sort of flaw is inevitable in the future, and puts a hard cap on the value of measures like secure boot (and I'd go even further and argue that it makes the costs of secure boot higher than the benefit), it's not correct that the signature process is inherently compromised. Public key encryption works, and it works very well. There have been a handful of goofs, and there will be more in the future. But the number of key regimes that attackers would want to compromise (consider even banal stuff like the signing keys for console games, which remain secure after many years) vastly (vastly!) outnumber the few exploits.
It is a fallacy to assume that because private keys have been leaked in the past, private keys will necessarily be leaked in the future.
Remember, the DRM-can-never-work argument doesn't apply here. DRM-can-never-work is that the user must be supplied the decryption key with the encrypted content. That does not apply to signing; you must be supplied the public key, but the private can be held private.
Many private keys have remained private. (So far as we know... and note here I'm talking about private as in asymmetric public/private such as can be used for signing, not "keys that were meant to be private but got leaked".)
In fact, I'd observe the Microsoft private key wasn't even leaked. Another private key was created that due to flaws in MD5 allow someone with vast, vast resources to figure out how to forge another one that would be accepted. One can equally read this as proof that the system is pretty strong, if it took government-level resources to attack a known-weak system that I would imagine won't be in the next signing standard.
We can not assume that private keys will leak. We can not even assemble an argument that the probability is high, which is because it isn't.
This year. The next year, it will be half as much. In 10 years, a thousandth. Are we willing to expire boot signing keys every couple years? Are we really comfortable only governments have such power because governments can do no wrong?
In the encryption wars it goes the other way. Encrypters get to make decrypters exert exponentially more effort for only polynomially more themselves, and the systems get stronger over time, not weaker. We've long since passed the point where handheld devices like cell phones can use encryption that would take resources in excess of the entire universe for the rest of time at the maximum theoretical computation rate to brute force. We don't always use that, and there may be (and probably are) weaknesses that can cut that down, but that's the direction this goes in over time, and I can't think of anything that has any chance of changing that dynamic. Even a proof of NP = P wouldn't do it (that only potentially nails certain forms of encryption used today, there are others that would still not be vulnerable), and if that's not enough....
I know all that, but you have to agree UEFI makes everybody put a lot of trust on a series of black boxes we cannot inspect. Even if we assume getting a set of signing keys requires more computing power than physically available, we cannot rely on it not being available through less compute-intensive ways.
Actually, it only demonstrate it's possible for them to be leaked. This is a rather obvious conclusion.
However, if the signing keys remain valid forever and signed binaries don't have to be re-signed when keys expire, you have essentially an infinite amount of time to leak (or crack) the signing keys and the likelihood of a leak will approach 1.
I am much more concerned by the increase in computing power than with leaks. The value of a valid signing key in a UEFI secure-boot world is high enough to ensure someone somewhere will spend inordinate amounts of money and/or computing resources to obtain a valid key. How much does leaking a key cost?
Do you leave your door unlocked because locks have been demonstrated to be easily broken?
The first rule of security is that security is all about layers.
Also, I sent a copy of your comment to Phil @ Apple, I think he's going to drop all the DRM restrictions on iOS binaries and release Apple's private keys used for signing iOS apps after reading your comment.
Okay, where are the private keys for Apple's iOS signing key, Motorola bootloader for the Droid phone, XBox360 bootloader signing key etc. etc.?
Are they imminently going to be released?
While there are definitely flaws in implementations and leaks, assuming them to be foregone conclusions is a mistake.
"Booting our CDs will rely on a loader image signed by Microsoft's WinQual key...the UEFI specification only allows an image to be signed by a single key."
This is anti-competitive and should not be acceptable. The UEFI specification needs to be fixed before vendors are forced to comply with it. It is disappointing that this won't happen.
I'm willing to put a few K$ towards the cause of starting an antitrust inquiry against Microsoft for this (and the related ARM landgrab).
Any lawyer (or otherwise knowledgeable non-armchair HNers) knows how I can go about that?
Given that the EU and China antitrust authorities also need to okay things these days, I believe that the we should bring the legal fight to MS, rather than receive the technical battle and fight it on our turf.
It's my opinion that you should look deeper into the issues than just skimming it before throwing thousands of dollars away.
First, Microsoft has mandated(as much as they can mandate to OEMs without violating antitrust!) that in order to receive Windows 8 logo certification, the OEM must provide a way for a physically present user to turn off UEFI secure boot in the setup menu and for that user to be able to add remove signing keys(including removing Microsoft's key!) at their will.
Coming to ARM and Windows RT, perhaps your antitrust inquiry might want to look at the elephant in the HN discussion - Apple - first, instead of being laughed out of the courtroom about picking on a platform with 0% marketshare compared to a platform which does the same thing with ~80% marketshare and >90% profit share.
Coming to actual meaningful things that can be accomplished for F/OSS desktop, you might want to consider reading the Red Hat blog post about secure boot. OEMs are willing to add signing keys of other players, but no one is interested in starting or running an operation that can sign F/OSS kernels with their key(after checking if that it's not malware).
Perhaps your few K$ might be better spent on such a nonprofit organization or division of the Linux foundation instead of throwing it at lawyers? Just my thoughts.
> Microsoft has mandated(as much as they can mandate to OEMs without violating antitrust!)
And similarly, everyone can install the browser of their choice on Windows. But it was still an antitrust violation, because it was, in effect, leveraging a monopoly in one market (Operating Systems) to produce gains in another (Browsers). This is along the same lines, except it is using a monopoly in the Operating Systems market to farther same monopoly.
> picking on a platform with 0% marketshare compared to a platform which does the same thing with ~80% marketshare and >90% profit share.
There's a huge difference here; Apple makes both the software and the hardware. Microsoft makes software and forces hardware makers to comply. And no one would even care about that requirement, if it weren't for their desktop OS monopoly. Again, leveraging monopoly in one market to farther gains (limit competition) in another.
It's not the 0% marketshare I care about. It's the monopoly abuse.
And I don't think anyone has a reasonable legal complaint against Xbox360 not running Linux even if it were 90% of the console market. Apple sells (Hardware+Software) they make themselves. Xbox360 is (Hardware+Software) Microsoft makes themselves. This is NOT the situation in the PC or non-apple phone or non-apple tablet market.
> OEMs are willing to add signing keys of other players, but no one is interested in starting or running an operation that can sign F/OSS kernels with their key(after checking if that it's not malware).
Microsoft charging $100 for certifying something is not malware is a joke. As was mentioned earlier in this thread, it is much more likely that they are after pirate OEM Win7 activations.
If I was a malware distributor, I would make sure that I submit - directly and indirectly - hundreds of bootloaders and kernels, many of them exploitable through buffer overflows or similar tactics.
I've been burned too many times with hardware that supposedly worked but turned out to only work well under windows (With bad ACPI kernel tables, and other such stuff), to trust the theory that everything will work out well.
The only way to fight this is legally.
> Perhaps your few K$ might be better spent on such a nonprofit organization or division of the Linux foundation instead of throwing it at lawyers? Just my thoughts.
>This is along the same lines, except it is using a monopoly in the Operating Systems market to farther same monopoly.
None of the millions of apps written for DOS and Windows will ever run on Windows RT. How is that leveraging a monopoly? Doesn't your argument apply to Windows Phone too?
>There's a huge difference here; Apple makes both the software and the hardware. Microsoft makes software and forces hardware makers to comply.
Why would you want the government to exclusively punish the software OS makers who don't sell hardware with that software? So, a company making software that is open to running on hardware made by different companies should be burdened with additional restrictions that companies like Apple are not? Sounds like a nice way to kill the whole concept competing on hardware(which drove down PC prices in the latter 80s).
So the lesson here for MS is to go with Windows RT only on the Surface and follow Apple's model? After all there is Android for the OEMs(HTC and LG just dropped out due to bad sales).
>Microsoft charging $100 for certifying something is not malware is a joke. As was mentioned earlier in this thread, it is much more likely that they are after pirate OEM Win7 activations.
Perhaps, they're not mutually exclusive with rootkits.
And maybe you missed the memo that UEFI secure boot must be able to be turned off by the user? The pirates can simply disable it.
>If I was a malware distributor, I would make sure that I submit - directly and indirectly - hundreds of bootloaders and kernels, many of them exploitable through buffer overflows or similar tactics.
Good luck with that, I am sure the requirements will be like the iOS app store, requiring a credit card and a tax id which they can track across all your accounts. One piece of malicious software detected will lead to the keys of all your submissions revoked.
>I've been burned too many times with hardware that supposedly worked but turned out to only work well under windows (With bad ACPI kernel tables, and other such stuff), to trust the theory that everything will work out well.
Just turn off the secure boot? Too hard to go into UEFI setup and turn this off?
I can understand why bright kids these days want to be lawyers these days instead of going into the tech space.
What are you trying to fight legally on what grounds? Windows RT secure boot or Windows 8 UEFI requirements too?
How is it Microsoft's fault that OS vendor don't want to bother to create a mechanism to sign kernels with their keys that the OEMs are perfectly willing to add and if not, the user can add themselves?
> How is that leveraging a monopoly? Doesn't your argument apply to Windows Phone too?
It is leveraging the desktop monopoly to make inroads into the tablet and phone market. If I start a company tomorrow called "Zikrosoft" which produces "Win Zit 8 ZT", a phone OS on par with WinRT 8, I might get some traction or not, but I most definitely would NOT got anyone to lock down hardware they produce for use with my software. The only reason someone takes the Microsoft requirement seriously is that MS has a monopoly in desktop and business software. Ergo: leveraging monopoly in one market (desktop operating system / business software) to gain an advantage in another market (phones, tablets).
> Why would you want the government to exclusively punish the software OS makers who don't sell hardware with that software?
> Sounds like a nice way to kill the whole concept competing on hardware(which drove down PC prices in the latter 80s).
Dude, Microsoft is a convicted monopolist. They've killed tens of companies with practices similar to this. Antitrust laws exist for a reason, and microsoft is arguably abusing its monopoly position in the os market here.
Instead of asking me, ask yourself - how is this different than the integrated browser thing, which was decided by both US and European court to be an antitrust violation. I can't see a material difference.
> Good luck with that, I am sure the requirements will be like the iOS app store, requiring a credit card and a tax id which they can track across all your accounts. One piece of malicious software detected will lead to the keys of all your submissions revoked.
There are apps on the app store that give you proxying ability. (A "trojan" against Apple's and the carrier's tethering income). Whenever one gets famous it is pulled from the store. I cannot name one that is active right now, but I'm aware of at least 3 which were available for months each.
Furthermore, I'm sure there are hundreds of apps which unintentionally can be exploited through buffer overflows (source: I found those in every C program I've evaluated) - the exploitable code can be useful; it doesn't have to be malicious - just exploitable.
Certification against malware is a joke. Just like the SSL certification process is supposed to guarantee identity. If you think this is going to work better than SSL certificates and Authenticode signatures for ActiveX, you have to know something I (and most of the public) doesn't.
> Just turn off the secure boot? Too hard to go into UEFI setup and turn this off?
I don't know. I would think that including reliable ACPI tables would be simple, rather than non-standard ones that only Windows could read (or that are overridden by Windows drivers). And yet, it isn't. I'm not trusting that it is possible to comfortably turn off secure boot until I've seen it happen.
> What are you trying to fight legally on what grounds? Windows RT secure boot or Windows 8 UEFI requirements too?
Yes. Microsoft's monopoly abuse. Both are examples of it.
> How is it Microsoft's fault that OS vendor don't want to bother to create a mechanism to sign kernels with their keys that the OEMs are perfectly willing to add and if not, the user can add themselves?
How is it Microsoft's fault that they give away IE, when everyone is free to install a new browser themselves?
It is, because of antitrust laws. And they are there for a reason.
IE was, at the time, a much better browser than Netscape. But it didn't get any significant market share until it was getting bundled with the OS. And a few years later Microsoft had 90% of the browser market. Yes, Netscape was just as much to blame -- but if IE wasn't bundled, perhaps they (or Opera) would have used the slower IE adoption to get their act together.
You are arguing theory, and I'm arguing practice (as shown by history). History doesn't usually repeat itself, but it rhymes very well.
I'm surprised that Microsoft pushes this in such a blunt way. They could have at least created a semi-independent non-profit to take care of signing. It seems like EFF or some other organization should push for antitrust investigation on this issue.
Although I would like to agree with you, I'm not convinced.
The reason Ubuntu (and Red Hat) aren't pushing to get their key included in the hardware is clear from the article:
"Microsoft's WinQual key, for much the same reasons as Fedora: it's a key that, realistically, more or less every off-the-shelf system is going to have, as it also signs things like option ROMs, and the UEFI specification only allows an image to be signed by a single key."
The Microsoft WinQual key monopoly is there because option ROMs (and other drivers) are only given one slot for a signature. After Microsoft signs the ROM, the manufacturer _can't_ add a Red Hat or Ubuntu signature to the drivers for their hardware.
This means even if you convinced all the manufacturers to include, say, a Ubuntu key, you still couldn't verify option ROMs were secure. Only Microsoft's key would work for that - thus, Microsoft's key will be the only one installed by the manufacturers.
Your next solution - creating unstickered hardware - is not a solution. There are a few manufacturers offering a linux option (Dell, Lenovo), and a few who sell only linux hardware (system76.com). In a UEFI secure boot world, there would be < 1% of hardware that wasn't locked to Microsoft's key, while 99%+ would be locked. I know users are supposed to be able to access a BIOS screen to disable secure boot, but that makes installing Linux much more painful than installing Windows 8. Why cede the advantage to Microsoft?
The best way to fight this, I believe, is to put your time and resources into coreboot.org and the FSF.
I'm not arguing that unstickered hardware solves anything, I'm arguing that it is hard to construe the sticker program as anti-competitive. As long as the stickered hardware can boot anything, then it is a reach to say that it is harming anyone (I don't find the confusion and unnecessary difficulty arguments very compelling, people that have difficulty twiddling the bios are going to run into problems anyway).
I don't understand the details of the option rom stuff, but my superficial impression is that no other entity is particularly motivated to run a meaningful program for signing such code. And it's still an open question if Microsoft can run such a program and have it end up meaning anything.
The context of my comment was someone labeling the practice anti-competitive. That's where harm comes into the picture.
I'm sure that the stuff will continue to get bad press, the idea of centrally controlled hardware is offensive to a large chunk of the people that bother to think about it.
Anti-competitive includes future harm. The way bundling IE was found anticompetitive by US and EU courts. Specifically, it is illegal to leverage monopoly in one market to gain entry to others - because history has shown that this is always abused and eventually harms society.
>Otherwise, Microsoft, Secure Boot-enabled laptops, and anything with a Windows 8 sticker will continue to get lots of bad press.
The iPad and iPhone got loads of bad press about the lockdown, the 30% cut of all in app payments and rejecting things like Android magazine apps and a bunch of other stuff. And Apple still can barely keep up with the demand. I think consumers have been conditioned by iOS not to think about openness.
By iOS? I do not remember seeing people walk the streets in protest against the closed nature of XBox, PS2, Playstation,…, or the Xerox 9700.
If you disagree, please give some proof of consumers (at large, as opposed to small groups, or at least in greater numbers than they do today) thinking of openness before iOS.
Look at the media coverage of Palladium, Trusted Computing etc.... it was brutally against it. When the iPad hit, the media was mostly about fawning over it and pushing the openness concerns under the rug for the most part.
Thanks reminding me of that case. Thinking of this, it is a nice example of why one has to start shouting for the tiniest infringement of rights. Trusted computing got press because people knew it was a battle that could lose the war. iOS and the App store, on the other hand, seemed a battle not worth fighting over when they debuted.
> The logo program doesn't stop manufacturers creating similar unstickered hardware
Effectively, it does. Microsoft routinely audits OEMs' products for logo/MDA compliance, and if any product offered under the same brand name fails the audit, then the entire company could lose all of its MS 'discounts' (that they've already likely baked into their cost accounting.)
In other words, if MS audits you, and any of your products fail the audit, then your unit cost for Windows licenses goes up significantly across all of your product lines.
It's very difficult for an OEM to simultaneously offer some products which are covered by the MS logo agreement and some which aren't.
Source: I used to work for a large OEM, and dealt with MS logo compliance on a daily basis.
That's orthogonal: the issue here is that if you want to sign a bootloader (or anything else) then you can only do it with a single key. While there's nothing stopping Win8 stickered machines containing two keys, you can be sure that not all of them will, so you need to sign your code with a Microsoft-derived key if you want it to work everywhere. That means you can't sign it with your own key.
Why is this whole SecureBoot saga not being considered as anticompetitive behavior by Microsoft? It's pretty clear that the only "advantage" of SecureBoot is to hinder competing OSes.
And that Microsoft has only been able to obtain such a favorable result from the UEFI forum by throwing its weight around.
As much as I'm not a Microsoft fan, this strikes my as conspiracy theorizing.
Firstly, nobody--not Linux or anyone else--seriously threatens Microsoft in the commodity PC space. They probably see Apple as a threat, but this move has nothing to do with Apple, since they build their own hardware and won't be affected by these signing key requirements. Linux users make up a tiny percentage of desktop and laptop users, and many of those bought OEM machines with Windows pre-installed, meaning Microsoft got paid anyway. The idea that Microsoft would undertake this kind of technical hurdle to stave off the coming hoards of Ubuntu users simply isn't realistic.
Secondly, pre-boot security vulnerabilities are very much real, and exceptionally difficult to detect in an already-booted operating system. Here's an area where Microsoft does feel competitively threatened, since Apple has been able to win market share on the back of Microsoft's poor security record, so Microsoft has had to come up with some way to shore up this gaping hole in their anti-malware strategy. Matthew Gerring of Red Hat, who's basically been leading the Linux efforts to figure out this UEFI stuff, readily admits that there are attacks already in the wild that UEFI addresses, and that no viable solutions other than signed OSes have been proposed to deal with them (see http://mjg59.dreamwidth.org/10971.html for a more thorough treatment). It's a hard problem, and while I would concede that Microsoft doesn't care how this affects the Linux world, I don't think hurting Linux was their primary motivation.
Yes, pre-boot vulnerabilities were a motivating factor.
But why forcibly disable Custom mode on ARM then? This is especially disturbing considering that ARM may very well be the major computing platform of the future.
Yeah, I think this is a big part of it. The mobile ecosystem has evolved in such a way that locked-down devices are the standard, and content providers have had a lot to do with that (apparently B&N's decision to lock down the Nook Tablet after having released the super-hackable Nook Color was made almost entirely at Netflix's insistence). I'm certainly a lot more annoyed at MS over their ARM positions than their x86 ones, but this attitude predates their entry into the sector.
Part of it might be the same reason why Amazon, BN, Apple and many Android tablets have the bootloader locked. The Windows RT tablet has ties to content consumption, like 30% or 25% cut of apps and also media sales like movies, tv shows, books, music etc. which are used as revenue(and even shared with OEMs according to rumors). Think about the how consoles are sold at near cost or a loss to make up on the games.
Loading Android or Ubuntu onto Surface or any other Windows RT tablet undermines this, that's why even the Nook, Fire and iPad come with locked bootloaders.
>This is especially disturbing considering that ARM may very well be the major computing platform of the future
Which ARM device has the biggest share of ARM computing devices like tablets? Apple with 80% and rest Android(many with locked bootloaders)?
Why does this come up only about Windows RT tablets that are going to start from zero against the iPad juggernaut? Where are comments like yours in the iPad discussions? What am I missing here? Why is it disturbing when Microsoft is starting to try to do something which Apple has already implemented with wild success?
> Why is it disturbing when Microsoft is starting to try to do something which Apple has already implemented with wild success?
I think Apple (and certain Android manufacturers) have made the wrong choice for long-term consumer welfare as well. Apple's increasing dominance is a tremendous threat to consumers' ability to control their own hardware.
In fact, Microsoft has historically been the good guy on this point. They are a big reason why we have such a large selection of cheap PC hardware. It's disturbing because, if Microsoft decides to move in the direction of locked-down hardware, there will be no major player left to support generic, OS-agnostic hardware. Which in turn leaves Linux users very much high and dry.
So really I sympathize with your perspective. It's ultimately the people who buy Apple products who have subsidized this disastrous trend.
Agreed. Microsoft has used their dominant position to strongarm the hardware companies into putting up a tollgate, which forces all of Microsoft's competitors to pay Microsoft if they want to keep competing.
$99 from a vendor for all of their sales is not a big financial deal.
The interesting part comes the first time Microsoft decides to revoke a competitor's key as part of a Windows update, and people who dual-boot find out about it because they no longer can dual-boot. Even if the mess gets fixed quickly, it will be a cause of FUD. How blatant will they be in taking advantage of that?
>Sorry, didn't realise the fee was only $99; you're right, that's more of a nuisance fee than anything else
That's not your fault. It's part the press writing flamebait headlines to drive page hits and intentional FUD from some people repeating the story as 'RedHat forced to pay MS' and gloss over the $99/year which won't even start to mitigate MS' cost to run such a signing service.
People ignore that this has nothing to do with desktops, but the newly forming tablet (or whatever is to came) market.
How many touchpads run webos now? Heck craigslist is filled with $50 offers to install Android there.
MS knows they will heavily subside their new hardware to kill competition, just like the do with xobox, and the last thing they want is Android or something there.
Safeboot never took off because ms never had a reason to push it before. As another post here correctly say, they own desktops already with no threat in sight.
What a catch 22. We want commitment to OSS so we're GPL v3, but because of our commitment we can't supply OSS so instead we're going to go for something else that's not OSS so we don't disclose the key.
Someone, somewhere, has just torn their beard out in fury.
The GPLv3 does not require you to provide a key. It only requires you to provide a way to bypass the need for a key. Allowing a user to add their own keys or even the option to disable the need for a key is fully within the bounds of the GPLv3.
There's also the outstanding issue that if you only supply software, then you might not even need to do anything to comply with the TiVo-ization clauses of GPLv3.
Interesting, but I think this needs further analysis. That bypass mechanism must also comply with the “no additional restricions” aspect of the licence.
While true that you will be able to modify the efilinux code, you won't be able to run the modified version, since it won't be signed, making it a very theoretical sort of open source. That kind of open-source-but-not-really situation is exactly what GPLv3 was trying to prevent.
If you're able to build your own version, you are certainly able to disable secure boot or install your own keys (both of which are mandatory for Intel hardware). The big drawback is that you have to splash out on your own $99 key if you want to distribute your alternative to people who don't want to disable secure boot.
> ...you won't be able to run the modified version...
"Tivoization"[1] is a different problem than "can't run because of [any reason besides the hardware owner doesn't want you to]", unless you're talking about another aspect of v3. For instance anything that is AGPL'd presumably is released without the passwords to the database, which presumably doesn't allow remote connections! Are you saying that doing such is a violation of the A/GPLv3 in either legality or spirit? (And you can't license all the data in your DB--think of all the poor sites storing user passwords in plaintext. Also data licenses are more tricky than software ones, but if code is data and data is code...)
And of course, even with DRM that supposedly makes it so unauthorized code cannot be run, it's more or less really just saying "we make it harder." I've seen a lot of "we got our tivo to run Linux or something else" posts, and the PS3 drama was interesting to watch unfold.
[1] I side with Torvalds with a dislike for this word: "[Stallman] calls it "tivoization", but that's a word he has made up, and a term I find offensive, so I don't choose to use it. It's offensive because Tivo never did anything wrong, and the FSF even acknowledged that. The fact that they do their hardware and have some DRM issues with the content producers and thus want to protect the integrity of that hardware.
"The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want. Whether that means "booting only a specific kernel" or "sharks with lasers", I don't care."
>We want open source because we want control of what run on our machines
>That standard goes against it.
>Why not have a per machine signature that you sign your code against?
And the Microsoft UEFI rules for getting a Windows 8 Logo REQUIRES UEFI setup to provide to a physically present user the option to turn off secure boot and add/delete your own keys.
How many times has this to be repeated to the same seasoned and regular commentators on this site and many others in similar stories from the past few months?
Is there a problem with communication here? Or is it intentional misunderstanding with an aim to spread FUD?
Sorry for the outburst, but I am really lost here with the same people making the same 50 silly wrong comments many, many times over and over again about UEFI secure boot. It's like they just see the headline like 'Red Hat to pay MS for booting Linux' and don't care or bother to read Microsoft's, Red Hat's and Ubuntu's take before spouting off in the comments about evil lockdown.
the Microsoft UEFI rules for getting a Windows 8 Logo REQUIRES UEFI setup to provide to a physically present user the option to turn off secure boot and add/delete your own keys.
Can you please provide an authoritative link for this? The only thing I turned up was this "Secure Boot Overview" updated a few weeks ago:
[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
[A]fter final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot.
EDIT: Just found this (tl;dr - disabling Secure Boot is mandatory for x86 and forbidden for ARM):
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:
a) 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 will put the system into setup mode.
b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with SecureBoot turned off.
c) 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.
Ahh, I went to the trouble of finding that and had it in my clipboard :)
Took me a few mins and was really hard to find on Google and was buried amongst all the noise generated by these FUD stories and discussions about UEFI secure boot. It's almost as if it was Google-Bombed.
Sorry about that, recoiledsnake. Thanks for the followup. Do you not consider Secure Boot and the prohibition against disabling it on ARM devices a slippery slope?
>Do you not consider Secure Boot and the prohibition against disabling it on ARM devices a slippery slope?
Yes, it definitely is. But the seeds for that were planted by Apple which can't keep their devices in stock, so when I see the ragefest directed towards Windows RT and Microsoft evil dominance with nary a mention of Apple(see Mozilla's FSF, and EFF's(?) blog posts about UEFI Secure Boot and almost all the discussions on HN and other sites) it feels like people are actively trying to avoid mention of Apple since it undermines the point they're making about Microsoft.
And many of these folks call it an antitrust issue because Microsoft was previously declared a monopoly on the PC and had successful antitrust suits against it.
But forcing MS to open up Windows RT while leaving the iPad alone(which has tremendous marketshare and profitshare in tablets) will only leave Windows RT weaker against the iPad(because they can't subsidize them with the app and media sales on Windows RT, see XBox). And every time I mention this, I hear crickets as people move on to other threads to continue piling on MS and ignore Apple.
I am in complete agreement with you on this. It is very sad to see the direction Apple has taken computing devices in, the blind acceptance by the public, and perhaps most disturbingly, the thunderous silence of the geeks. (Downvotes away! (assuming anyone is reading this far in.))
I think the major difference is that Microsoft is able to strongarm 99% of PC manufacturers due to their dependence on Windows, whereas Apple can only control their own hardware.
A more apt comparison would be if Dell decided to enforce UEFI secureboot (with no way of disabling it). The users wanting to run linux would be able to simply not buy from Dell anymore, just as right now you can still choose not to buy an iPad.
But the concern here is that Microsoft will control ALL PCs (minus the small minority of computer manufacturers willing to stand up to them), meaning a Linux user's options are to pay more for "unlocked" hardware or jailbreak a Windows 8 machine.
would changes to the windows kernel by the update require user action? will it end up being the "press OK to allow administrator rights to this application" but at boot time. or if it's the same signature it just updates silently?
I would imagine secureboot work this way - you start machine, UEFI detects that signature of bootloader or kernel or whatever fails signature verification. If it fails - ask user if he wants to save new signature instead or if he did not install any updates to kernel/boot/etc.
This way it will be:
- universally between OSes
- will allow GPL code to be used
- will not lock people into particular software platform
Yes. The classic "People ignore popups" dilemma. The thing is, 99% of people on the planet either wouldn't know what a change to their boot sector is, or what to do if one occurs. So they would just leave it and go on with their root kit installed.
The same reason why browsers are now making it so tough to get to a website without a "valid" SSL certificate -- the average user will ignore the warnings and accept anything to get to their objective. This is one of the reasons why Google Chrome now prevents users from accepting invalid SSL certificates for some Google properties.
This is just disgusting. How in the world did our hardware get hijacked by MS and nobody anywhere did anything to stop it? Seriously! I can only hope that there's enough backlash to stop this mockery of consumer freedom to put things back to the way they are now.
Apple and smartphone manufacturers started the locked down hardware trend, Microsoft are riding their coat tails to achieve what they've wanted all along.
To be fair, these standards aren't controlled by Microsoft, but they've thrown their weight at the manufacturers to make sure the standards are implemented in a way which grossly favours them as the PC OS incumbent.
But they are using the recent success of Apple & co in consumer circles to diminish the appearance of their monopoly and make it look as if choices abound to the consumer.
Yes, but Apple was the first to make lockdown an acceptable, or even desirable, thing for general-purpose consumer computing devices on a large scale. The idea was around, and implemented in a number of places (especially on phones), but Apple was the first to pull the marketing trick of getting the world to accept or welcome it in a domain thought of as computing rather than peripheral or special-purpose devices.
How the fuck do people tolerate Phoronix? I know they do good reporting and are awesome in the Linux community ... but good god browsing their website is like walking through an old minefield in Vietnam. Every other word opens a popover, popovers on load, popovers if you scroll. Look at the sidebar and an ad will appear somewhere.
Its because "they do good reporting and are awesome in the Linux community" (also BSD). If someone else had the same level of reporting, I would go there. It is not much fun and I tend to hit "Read Later" and read it in InstaPaper.
I understand Phoronix's stated reason for papering themselves with ads, though I think it actually does them more harm than good. (They state it's because they are a one-man show and don't make much money.)
Though Phoronix occasionally puts up a plea not to do this, I just installed AdBlock Plus.
> To perceive the computer as an appliance instead of a piece of hardware.
For many (most?) computers are appliances. Which does not contradict them being pieces of hardware.
> Alienate the users on their machine, not something that can be hacked,
> studied and understood as a computer, instead a piece of magical wisdom.
What a load of bullshit.
> Dumb down the mainstream user, and tie them up on their products.
It seems it is extremely hard to grasp the simple true: only minority of the population is interested in being hackers, programmers and IT guys. They just want to use computers — much the same way like they drive their cars without any wish and ambition to be a car mechanic.
It is not "dumbing down" — it is freeing them from caring "how do I make this fucking thing work" to just doing what they want to do: be it browsing Facebook, writing a research paper or calculating orbit to Mars.
I'm blown away that this comment is getting down voted. I don't care of you disagree with Microsoft locking down their boot loader, the above is the most accurate answer: 99% of users don't know what dual-boot means or care to find out. This secure boot only helps their experience, even if it's at our expense
Helps them from shooting themselves in the foot. My Grandpa/parents/non-technical friends could care less about anything other than Facebook, email, and maybe some Quicken type software. To them, alerts and pop-ups are just annoying things that they just click on until they go away. For them, 'secure boot' shuts down one of the possible attack vectors for malware that prey on this mentality. I know secure boot isn't a good solution, but when a company can make a change to make 99% of their customer base "feel" more secure, and in turn drive more sales, they will do it every time. Sucks for people like us, but hackers (that care about boot loaders) only make up a very small portion of the market.
It seems it is extremely hard to grasp the simple true: only minority of the population is interested in being hackers, programmers and IT guys. They just want to use computers — much the same way like they drive their cars without any wish and ambition to be a car mechanic. It is not "dumbing down" — it is freeing them from caring "how do I make this fucking thing work" to just doing what they want to do: be it browsing Facebook, writing a research paper or calculating orbit to Mars.
Being that the case, what does DRM and the secure boot feature in UEFI add to that experience?
Secure Boot adds protection against certain classes of malware. It's not complete protection by itself, but it's blocking off one possible kind of attack.
> Why would I buy a computer that's crippled like that?
Because I want a computer. I go to the store, I see a cheap one, and I pay for it. Then I go home and use it. I'm an end user that just wants to get to email, youtube, and Google. I don't know what secure boot is, what a BIOS or an EFI is, all I care is that I don't have to spend money.
I don't know it's crippled. I have no way of noticing. Hell, I'm still using Internet Explorer.
If you're corporate you buy it to make sure that the OS and Drivers are both signed by the people you bought them from, and thus nobody has tampered with them.
I'm really having a hard time getting worked up over a $99 key which will all but completely eliminate boot sector infectors and the like. I think a lot of this storm and strife comes as a result of who is pushing it, less than the concept.
It's not the fee that's the problem. It's the permission.
Suppose Wikileaks developed installable software that embarrassed the U.S. government. Would their key have been revoked, making it impossible for anyone to run their software? Yes.
You will still be able to run any software on your computer once it has booted, the signature is for the bootloader. So this would only be an issue if Wikileaks for some reason had to implement their own operating system. Even then, users would have the option to disable secure boot and run the unsigned bootloader.
..Unless you run on an ARM chipset, at least in the case of Windows. I don't advocate government intervention often, but I would really like to see that particular requirement struck down on antitrust grounds.
There is a fine line between slippery slope as a fallacy, and the legitimate concern that the very existence of a feature like this invites abuse. Or the even more legitimate desire to build a world in which bad actors (corporations, governments, etc.) cannot do remote evil, rather than a world that works only because they don't do remote evil.
That which does not exist cannot be abused. I'd much prefer a world where authorities cannot disable software, not a world where they merely don't.
That's not fallacious slippery slope reasoning. It's an argument for structural and technical rather than merely moral, ethical, or legal impediments to abuse of authority.
>It's an argument for structural and technical rather than merely moral, ethical, or legal impediments to abuse of authority.
I've got to disagree with you there. Every piece of modern technology out there has the potential for abuse of authority - but you don't crap on the tech wholesale simply based on that alone. The moral/ethical/legal impediments are how you rein in abuse, not by hamstringing yourself.
>Suppose Wikileaks developed installable software that embarrassed the U.S. government. Would their key have been revoked, making it impossible for anyone to run their software? Yes.
You mean like a CA? Of course they could do that, but then it wouldn't be Windows Certified (it would just be Somebody-Else Certified), which is how OEMs want to brand their products. This is all about dealing with Microsoft's hegemony.
I agree.
It looks like all the Distro's will have to jump on the bandwagon so to speak in order to be used by the new Windows 8 boxes.
Then in this case, why are all the distro's having to shell out to get a licence key from Microsoft?
I know of a lot of small distro's that dont produce any income, and pay for their webspace out of their own pocket.
Why are we going to force them to purchase a key to allow their distro to run on a Windows 8 box?
If they don't want Secure Boot then the user can turn it off.
If they do want secure boot then it needs to be signed by _someone_, and none of the Linux distributors have been willing to step forward and be that someone.
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 [...]
On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.
I thought it was that anti-competitive actions were illegal (or just heavily frowned upon?) and monopolies in and of themselves aren't bad, just if they abuse their power in an anti-competitive way.
IIRC, it's basically has to be the combinations of the two. Monopolies aren't illegal in and of themselves. But neither are actions that may be deemed anti-competitive. It's only illegal when a monopoly (or a dominant player - doesn't have to be a monopoly) exploits its position to gain further advantage through anti-competitive actions.
Having long lost the appetite to stay on top of PC hardware, could someone kind please post a pointer to an article that explain what this UEFI SecureBoot actually means for generic hackers intending to run Linux or $whatever on their computers? What's all the fuss here?
I know how secure booting works and that it would be detrimental if enforced unilaterally but I've also read you can just turn off the UEFI SecureBoot from the equivalent of BIOS settings of these Windows 8 compatible machines.
So, in order to boot into whatever I want, I just tick that check off and go play with my computer like before? If so, then what's the problem?
Because, as mentioned in the article, there was more interesting information to be found in the mailing list, which Phoronix combined into their blog post.
"We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code, before the ExitBootServices UEFI service is invoked. Currently, this call is performed by the boot loader, before the kernel is executed.
Therefore, we will only be requiring authentication of boot loader binaries. Ubuntu will not require signed kernel images or kernel modules."
That's completely different from what Fedora is doing (signing all kernels and modules). I hope for them Microsoft agrees with their interpretation and won't revoke their signed binaries. I'm not sure what advantage they would get from a signed boot loader, if you can run any arbitrary kernel from within the loader.