Ubuntu's Plans To Implement UEFI SecureBoot: No GRUB2
phoronix.com
phoronix.com
"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.
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.
http://arstechnica.com/security/2012/06/flame-malware-was-si...
Then you can proceed searching for ssl cert fiasco...
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.
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.
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?
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?
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.
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.
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..)
http://arstechnica.com/security/2012/06/flame-crypto-breakth...
A splash screen that required acknowledgment would work for case #1, but would be annoying, too.
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.
The logo program doesn't stop manufacturers creating similar unstickered hardware or putting more than one key in the stickered hardware.
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 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.
You have to convince me that Microsoft's UEFI Secure Boot requirements aren't a threat to Software Freedom (as defined by the FSF).
Otherwise, Microsoft, Secure Boot-enabled laptops, and anything with a Windows 8 sticker will continue to get lots of bad press.
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.
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.
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.
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.
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.
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.
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.
I don't think so. EFF and ACLU, perhaps.
edit: added note about xbox360
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.
http://www.zdnet.com/blog/security/study-rootkits-target-pir...
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?
http://i.i.com.com/cnwk.1d/i/tim/2011/09/26/secure-boot.png
>The only way to fight this is legally.
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?
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.
And that Microsoft has only been able to obtain such a favorable result from the UEFI forum by throwing its weight around.
Right?
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?
I'm still concerned that MS is manning the tollbooth, though, for roughly the reasons you state. :)
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.
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.
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.
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?
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.
I think it just happens to be extremely convenient for Microsoft that doing this makes life a little harder for Linux/Alternate OS people.
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.
Someone, somewhere, has just torn their beard out in fury.
"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."
That standard goes against it.
Why not have a per machine signature that you sign your code against?
Centralize it and have no more control. That's no catch22 whatsoever.
>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.
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:
http://technet.microsoft.com/library/hh824987.aspx
[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):
Windows Hardware Certification Requirements http://download.microsoft.com/download/a/d/f/adf5bede-c0fb-4...
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.
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.
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.
btw, this is the first time i hear about this.
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.
[1] http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and...
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035...
This way it will be:
- universally between OSes
- will allow GPL code to be used
- will not lock people into particular software platform
Are there any problems with my approach?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.
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.
Though Phoronix occasionally puts up a plea not to do this, I just installed AdBlock Plus.
I use Adblock Plus, and I never experience any ads or popovers on Phoronix.com.
We really need to start thinking about the post advertising economy dont we
It has absolutely no security soundness. It may protect you against evil maid attack. But even so, less than decent fs encryption.
It's nothing more than a ploy to help Microsoft, and Ubuntu and RH are falling for the sole reason of having too much money.
It's like ssl certificates for bios. Burn it.
Alienate the users on their machine, not something that can be hacked, studied and understood as a computer, instead a piece of magical wisdom.
Dumb down the mainstream user, and tie them up on their products.
"Protect" their software, being the computer just a black box projecting their knowledge / entertainment.
I hope DRM backfires really hard on the companies advocating for it.
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.
> 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.In my opinion secure boot just means that my computer is owned by the company that has certified it.
Being that the case, what does DRM and the secure boot feature in UEFI add to that experience?
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.
Also, slippery slope. Cmon.
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.
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.
Perhaps you posted this in the wrong story?
http://www.readwriteweb.com/archives/wikileaks_app_yanked_fr...
In which case, would it not be worth clubbing together to have a root key manager, who can take the place of MS in signing packages?
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 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.
Unless you're on ARM, in which case you're screwed.
From the "Requirements for certifying Windows 8 systems" PDF available at http://msdn.microsoft.com/library/windows/hardware/hh748188 :
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. On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.
Does this mean that , on compliant ARM devices, only Windows 8 may be run? If so, how is this not anti-competitive?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?
http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and...