After Fedora, Ubuntu has now also announced how it’s going to handle the nonsense called “Secure” Boot. The gist: they’ll use the same key as Fedora, but they claim they can’t use GRUB2. “In the event that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn’t then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would end up worse off.” So, they’re going to use the more liberally licensed efilinux loader from Intel. Only the bootloader will be signed; the kernel will not.
Of the various proposed solutions I’ve read about, this one seems to be the least evil. The only thing that would be better IMO is for the option for disabling EFI secure boot be mandatory and not be to terribly different from vendor to vendor. If only everyone making consumer hardware would just use the reference implementation and stop screwing around reinventing things =/
I’m certainly not an expert in this, but from what I’ve seen, I agree. (In fact, I half wonder why Fedora isn’t going the same route.)
This whole “Secure Boot” thing has me upset at Microsoft to a degree I haven’t been for several years. The x86/x64 situation is bad enough, but the ARM (WinRT) situation really burns me up.
The only real difference is that Fedora will be requiring a signed kernel and Ubuntu won’t. I think we’ve explained why we believe a signed kernel is necessary.
mjg59,
“The only real difference is that Fedora will be requiring a signed kernel and Ubuntu won’t. I think we’ve explained why we believe a signed kernel is necessary.”
I understand the reasons for your decision, but man locking up the kernel from user tinkering must have really clashed with your open source philosophy.
I’m sure you’ve thought this through more than I have, but my pragmatic impression is that running Fedora under MS’s keys offers short term benefits, but comes with severe long term consequences and legitimises microsoft’s control over secure boot.
Of course I’m not blaming you guys at all, the situation sucks all around, but a tiny spirit in me wishes you might have put up more of a fight. If the largest linux distros fold, then it seems pretty hopeless for the rest of us.
We’ll be providing tools for users to install their own keys if they want to build their own kernels or use third party modules – it’s vitally important to us that users be in control of their system, and we won’t support any scenario where they’re not.
mjg59,
“We’ll be providing tools for users to install their own keys if they want to build their own kernels or use third party modules – it’s vitally important to us that users be in control of their system, and we won’t support any scenario where they’re not.”
Correct me if I’m wrong, but your stock kernel, which is to be validated under microsoft’s chainloader, will reject 3rd party/end-user modules signed with user keys not approved by microsoft, right?
The only way for users to load/run their own modules would be for them to get their own keys approved by microsoft. If this user distributes code as “open source” to another user, they then face the same problem all over again. Each user who obtains the source code will loose the ability to compile & run it without permission from microsoft.
Your claiming that it’s vitally important for users to be in control of their system, yet in my opinion this scenario doesn’t permit that. It gives microsoft control. Can you help me understand your point of view better?
Edit:
I’m aware that you mention disabling secure boot or changing the keys in this link.
http://mjg59.dreamwidth.org/12368.html
But I’m talking about being able to use Fedora with secure boot enabled on a typical consumer system where the keys cannot be changed.
Edited 2012-06-23 04:05 UTC
Microsoft require that all x86 systems permit the user to modify the keys. They forbid that on ARM, so we won’t be supporting secure boot on ARM.
mjg59,
“Microsoft require that all x86 systems permit the user to modify the keys. They forbid that on ARM, so we won’t be supporting secure boot on ARM.”
Well that’s great to hear that the keys can be overridden and not just disabled! Your earlier statement makes more sense to me now.
Lazarus,
“The only thing that would be better IMO is for the option for disabling EFI secure boot be mandatory and not be to terribly different from vendor to vendor.”
Please please please don’t forget about allowing us to control the keys in our own hardware. I don’t think it’s acceptable *just* to be able to disable secure boot in UEFI, it should be mandatory that owners can choose to enable secure boot for any operating system that supports it.
Unfortunately the path we are now on seems to be headed in the direction where microsoft, having it’s keys embedded in all consumer machines, will become the defacto secure boot gatekeeper and secure boot enabled alternative operating systems have no choice but to become subordinates within microsoft’s chain of trust. We already see it beginning.
To top it all off, secure boot is even less secure now because owners don’t know who’s code is running under microsoft’s keys. It’s very likely that malware will eventually get a key under MS’s $100/year program. Sure, widespread worms will have their keys revoked after the fact. But narrowly targeted attacks are likely to remain undetected because the owners are kept entirely out of the loop, we’re never informed by secure boot that something bad is afoot with our boot chain – secure boot my ass!
Being able to disable it is important, but I’m disappointed this crap security standard got adopted in the first place.
In all fairness, being able to disable (in)secure boot is a requirement for the Windows 8 certified/logo thingy on x86. Somewhat ironic that if you want to make sure you can run a non-MS OS you should get hardware that is certified for Windows 8.
Can’t the Linux community create a global key that will have to be shared among all Linux distributions if they want to be compatible? This will also create some sort of standardization the way Linux boots which would mean consistency.
OSGuy,
“Can’t the Linux community create a global key that will have to be shared among all Linux distributions if they want to be compatible? This will also create some sort of standardization the way Linux boots which would mean consistency.”
Short answer, no. If they shared the same key, then a security flaw with “Bozo” Linux would mean revoking Debian’s key as well. (I’m expecting key revocations could become a common occurrence).
Longer answer: There’s no way under secure boot for the owner to tell his computer to trust Debian & Windows but not “Bozo” Linux. The privilege of choosing what can run is left to microsoft & friends since they hold the master keys to our hardware and they’re running the certification program. Microsoft’s bootloader will hand off to 3rd party bootloaders that are authenticated with a valid certificate.
An unfortunate side effect of this security model is that a vulnerability in ANY approved operating system opens up ALL operating systems to trojans. Bootloader trojans can hook into the system using a BozoLinux flaw and then continue to boot another OS such as windows.
Ideally the owner would be given explicit control over secure boot keys, then they’d just trust Debian’s key and that’d be the end of it, no need to trust anyone other than Debian to boot my machine. Not only would it give owners more freedom, it’d be more secure too. It’s a real shame secure boot was designed as it was.
Thank you very much Alfman for that comprehensive reply.
Sorry Thom, but I’ve been here for a few years now, and whilst Secure boot might not be nice for Linux, it does exist for a good reason. And I was hoping that OSNews of all people would take a fair all-rounded look at it, rather than jump on the “microsux-bandwagon”
Security. Being able to shove any boot code in a system is a security risk. It makes it possible for a virus to persist on a system, and eliminate anti-virus programs from being able to ever delete the files. I can’t blame Microsoft for wanting to patch it, particularly because every-time windows gets a virus, Apple and Linux users beat their drums about “Microsoft’s security sucks, blah blah blah”.
Is it good for Linux? In some ways, yes, but in others no. Its not Microsoft’s fault that Linux vendors aren’t working together, and that they have made it near impossible for all of their keys to be pre-installed on computers. If they did though, the key would be pre-installed.
And yes, I do want to see Linux succeed in the future. However, the reason why it hasn’t already, is that we keep making excuses for shortcomings.
Preventing the loading of unauthorized boot code is potentially quite useful.
However, unless Secure Boot allows you to sign your own software and upload your own keys easily, it comes at the cost of using your hardware as you see fit.
In general, this is the cost of “appliance-ware” in which hardware and software are bundled and difficult to tease apart.
This is not only a problem for Linux, but any software and hardware freedom — your only remaining option is to choose between bundles.
Edited 2012-06-23 01:52 UTC
I really have to say that all this feels more like trying to kill a fly with a god damn nuclear weapon; there are extremely few modern boot-sector viruses — I atleast am not aware of a single one — and you don’t need boot-sector viruses anyway to cause damage. As long as the virus/malware has access to users’ files and input devices then the users are already screwed and Secure Boot does not prevent that. Besides, a virus shouldn’t even get to the point of being able to infect the boot sector in the first place.
That is to say that Secure Boot solves only a highly theoretical issue that really isn’t all that pressing a matter, atleast for now. It doesn’t mean it’s useless, but it’s given way too much weight. The bigger issue, though, is that Secure Boot is all controlled and designed by Microsoft. If it was really aimed at securing end-users then there would be a public design-and-approval process and some sort of a multi-party committee to govern the keys and Secure Boot-usage in order to ensure proper cross-platform functionality, to find and fix any faults with the implementation and to not let only a single party control the whole thing when it has the potential of affecting every single PC-user and manufacturer. That right there is my one, single biggest issue with Secure Boot.
I agree with WereCatf and would add this reeks of ‘Security Theater‘ to move an agenda forward that has more to do with control of revenue opportunity then real security.
Not to say that boot security is not a concern without veracity, but the aggressive move to adoption, lack of anything that resembles peer review, and obvious pressure from the Vole — just smells bad.
Well, Stuxnet contained a rootkit, which is SecureBoot would prevent from operating.
Granted, it also ran in user mode, which SecureBoot wouldn’t stop, but that’s a freakin’ complicated bit of malware.
Yeah, sure, until one of the companies that has had their keys signed by MS have their private keys leaked and it’s a matter of when, not if. When that happens everyone is screwed and back to square one.
Not to mention that this “security” measure in no way will prevent companies from installing malware or rootkits.
Trusting big business to do what’s right and safe for you? Never a good idea.
I read the linked story, and found this part particularly interesting:
GRUB Legacy with Red Hat’s EFI patch stack would probably do, but we really don’t have much interest in resurrecting that code if there’s any possible alternative at all…Our current plan is to use Intel’s efilinux loader with some modifications to add a relatively simple menu interface.
There wasn’t any explanation, but I’m surprised that GRUB Legacy is not getting more love. I personally prefer it way more than the overly complex GRUB2 (which I considered a step backwards), and not sure why Intel’s efilinux loader is considered superior. Anybody know why?
Edited 2012-06-23 01:44 UTC
Flexibility over simplicity? (I’m not involved in either project, but having hacked on both quite a bit for the systems I administer, it certainly feels that way.)
I can’t remember when was the last time I heard about a “boot” infection (I’m not saying it doesn’t happen). It’s just crap designed to make life difficult for competitors; classic Microsoft move. All this with the excuse of more security; their own personal “think of the children”.
I can’t believe this goes without a antitrust trial or something, at least in Europe.
And another thing, they chose to go with the CA system? Really? After all the Comodo, Diginotar, secretly issued wildcard certs and so on? What kind of integrity does this system still pretend to have? It should be made illegal.
Right now I feel like this guy:
http://www.youtube.com/watch?v=QRO3RJ9cYSo
Edited 2012-06-23 01:49 UTC
Just a sidenote: Maybe you’re intrested in reading this article regarding boot infections:
Marco Giuliani:
Mebromi: the first BIOS rootkit in the wild
http://blog.webroot.com/2011/09/13/mebromi-the-first-bios-rootkit-i…
But even with SecureBoot seen in all its glory and wonderfulness, there are many other attack vectors remaining. Security theatre as usual.
Doc Pain,
“But even with SecureBoot seen in all its glory and wonderfulness, there are many other attack vectors remaining. Security theatre as usual.”
Well, the trouble is, even when secure boot is functioning properly, boot malware will slip right by unnoticed if it’s signed by someone who’s purchased a microsoft code signing cert. That’s not going to stop a determined attacker. In my opinion secure boot ought to have been designed to alert the owner to system alterations such that even signed malware would raise flags if the user didn’t make those changes.
Thanks for the link. As I said I’m aware this kind of threats exist, but as someone said earlier, it’s just like killing a mosquito with a pick-hammer. It is unreasonable.
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/stateme… sign it people!
It’s the Nth time recently that this quote comes to mind:
“He who sacrifices freedom for security deserves neither.”
I have, but exactly what do you think that will accomplish? Microsoft doesn’t give a shit how many signatures are on a stupid petition. It does not matter. Even if they get a million signatures, that’s a million out of a potential customer base of several billion. Do you honestly think Microsoft’s fat cats are going to lose a single bit of sleep over FSF’s petition? Some better questions are, where is the EFF? Where is the SFLC? How about the rest of FSF’s lawyers? Why aren’t they combating this in a way that might, however unlikely, actually work? Petitions have no teeth, and we’re going to need to bite hard to even have a chance at stopping this before it spirals out of control. It’s probably already too late.
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/stateme…
A million signatures will carry weight in the EU and an EU antitrust lawsuit MS will care about. In fact politicians in general care about organized groups of voters.
Of course if your considering direct action and whacking some MS top brass that might work – I’ll enjoy reading about it in the papers.
Edited 2012-06-24 06:01 UTC
Gone fishing,
“Of course if your considering direct action and whacking some MS top brass that might work – I’ll enjoy reading about it in the papers.”
Where’s that petition at?
Over 35000 not a million but …
Wow, talk about going way out into right field. Still, at least we now know your secret desire
. I specifically asked where the EFF and SFLC are in this. I don’t agree with getting governments involved but, if you insist, forget the petition and get the old-hands in trying to fight shit like this in on it. Petitions mean nothing in the US and, guess what, that’s where Microsoft is headquartered. Plus, if the EU hasn’t gotten involved in this yet even with what we already know, why would they care later? What are they going to do, demand Microsoft make yet another separate edition of Windows? Yeah, that worked oh so well with the “N editions”, didn’t it? My point is simply that experienced lawyers should already be attacking this, if legal action is what’s needed. Forget waiting for the petition, since by the time that gets anywhere it will be too late. Nip it in the bud right now, or else we’ll all be stuck with it for a damn long time.
No it won’t, because it will be very clear to a court that Microsoft aren’t even close to breaking anti-trust laws in this case.
Yes, they’re forcing their vendors to support a technology that could have anti-competitive consequences. But they’re also openly taking steps to mitigate those consequences – they’re forcing vendors to allow secure boot to be disabled by the user (except on ARM), and they’re also providing their key-signing service to those who don’t have the influence to get their own keys distributed by vendors.
In short, it’s certainly an anti-competitive move, and a rather devious one at that. But it’s done in such a way that there’s no way the laws can touch it.
http://en.wikipedia.org/wiki/Alureon
The problem solved by Secure Boot is real. The solution may make it harder to keep hardware “open” – but secure boot will definitely address TDL-4 / Alureon and the likes which infects the MBR.
BS
Microsoft does not control UEFI. Indeed, Red Hat and others sat in at the table when UEFI Secure Boot was spec’ed. It will be very hard to claim this is an anti-competitive move when MS has clearly allowed (not taken a position) on an off-switch.
As for ARM – MS doesn’t hold a monopoly there – so no basis for anti-trust. And in any case this is just what Apple and Android OEMs does for practically all ARM devices: Locks them down to ensure that only the supplied OS can be booted.
If you don’t want to secure your OS by this method then help either the openbios group or make one that can replace the bios.
Ummm…
I hate to say it but we’re a long way off…
1. http://www.openfirmware.info/OpenBIOS
And just the line above it tells it can be used as a payload to CoreBoot. In other words, there should be possibilities.
Canonical’s approach sounds much more thought out than Red Hat’s. Or at least more appealing, both for Ubuntu users and for the many developers remixing Ubuntu.
I’m a little surprised they don’t want to revert back to GRUB Legacy, it has a long life and was widely used, I would imagine it would be the most logical choice. However, just about anything after GRUB2 will be a step up. I really don’t like mucking about with its giant, complex configuration files.
It appears there are two paths ahead for those of us who wish to continue using obscure operating systems like Haiku and Syllable, or Linux distros like Arch, Slackware and Puppy.
One path is to hold on to our existing non-Secure Boot hardware, perhaps even spending the money to get the latest and greatest before the manufacturers stop making traditional motherboards.
The other path is to begin the move towards open ARM devices, since we all know that Microsoft will never be able to assert as much control over that architecture as they seem to be doing with the x86/64 world. As GNU/Linux, BSD and Haiku all either have existing ARM ports or are in the process of porting, those particular OSes will still be able to thrive.
I’m not saying ARM is the solution, just a consideration. I’d greatly prefer it if Microsoft would just leave the hardware be and focus on security at the kernel level on up, like they always have with Windows NT. Unfortunately that’s like asking a child not to stick unhealthy objects in his mouth.
Or buy systems that support CoreBoot!
And the walls fell!
Damn it people. Wake up! We should all be MAD AS HELL about this. How have we become so passive as to sit idly by “making the best of the situation” while one company effectively takes control of the entire PC industry with a single edict.
Remember Microsoft just wrapped up long drawn-out anti-trust litigation not so many years ago. How did that turn out? Looks to me as if they greased every filthy politico palm they could. Now that they’ve paid their graft it seems they are free to run rough-shod over anything and everything.
We should not accept this situation whatsoever. It is unacceptable for a single company to dictate that every other company must pay them to have the right to run software on a computer solely on the basis that they write more popular software for that computer. A company can only get away with such a thing if they are exerting monopoly power. This is obvious!
If secure boot is to be acceptable, licenses must be essentially free and handled by an independent not-for-profit standards body.
Where are the lawyers? B/c this has to be stopped.
So you figure that the way towards software freedom is having the government regulate what software and hardware we may make?
“independent not-for-profit standards body” != “the government”
For example:
“ICANN (From Wikipedia, the free encyclopedia)
The Internet Corporation for Assigned Names and Numbers (ICANN, /ˈaɪkæn/ eye-kan) is a nonprofit private organization headquartered in Los Angeles, California, United States, that was created on September 18, 1998, and incorporated on September 30, 1998[1] to oversee a number of Internet-related tasks previously performed directly on behalf of the U.S. government by other organizations, notably the Internet Assigned Numbers Authority (IANA), which ICANN now operates.”
“Where are the lawyers? B/c this has to be stopped.”
Suing to prevent the implementation of Secure Boot is certainly getting the government involved. Also the definition of what is a “standards body” seems to shift very quickly with how the person defining it feels about what they are doing. I could certainly start a non-profit that publishes documents that say that everyone should implement secure boot all day.
Good point, but you’re missing mine.
Having the “government regulate what software and hardware we may make” is not the same as asking “Where are the lawyers” to pursue enforcement of existing anti-trust laws.
For example, a lawyer can sue (in the judicial branch) to stop Microsoft from using their dominance in the OS market to drive all competitors out of the web browser market in an effort to control the Internet.
But that’s very different from the government (in the executive or legislative branch) specifically regulating what software can be made to browse the web.
Rephrased, citizens can leverage the government for anti-trust and consumer protection from dominant businesses without demanding that the government actively run those businesses.
Or yet another way, the government can function as the referee without also playing quarterback for one or both teams.
Hope I’m making the distinction clear.
There is a point there, though I think people are a bit quick to jump to the legal attacks based on the convicted monopolist status of Microsoft. One has to understand that Microsoft is not the only company in the Secure Boot game. I also think that one has to accept at least that Microsoft implements Secure Boot and pushes for it a bit.
The thing one could consider is preventing Microsoft from making Secure Boot a Windows 8 logo requirement, but on the other hand the logo requirement is likely the only thing that is ensuring that all x86 systems will have a toggle and key update facility for Secure Boot. Left to themselves many motherboard manufacturers would likely implement Secure Boot (simple checklist feature) either way, but putting in the key update stuff probably has somewhat poor returns in reality.
Mostly what I want to get said though; legal interventions is a dangerous game. Launching challenges against Microsofts uses of cryptography will make principled stands against limitations on cryptography use a bit trickier.
Agreed.
Note that my objection is Microsoft’s direct control over the key infrastructure.
I have no problem with requiring secure boot for Windows 8 as long as identity management is with an independent third party such as Thawte, and an end user can replace the OS (or pay a service company to replace it) if desired.
I have a better idea: Don’t allow Microsoft to be the primary control on secure boot. It could still be a logo requirement and yes, machines can come with Microsoft’s keys preloaded, but you should not have to go through Microsoft to get a key. That’s what everybody’s upset about, and why they’re extremely quick to bring up anti-trust. Microsoft, like it or not, has a proven track record of power abuse and allowing them to be the controlling influence behind the keys used for secure boot is, like it or not, a recipe for disaster. Keys should be given via an independent third party. Thawte is a good example as someone already mentioned.
I couldn’t agree with you more. Any time you bring the government in on something like this, you set precedents whether you realize it or not. I am not in favor of having a government, no matter who it is, getting involved in this. The US government is already trying to choke the life out of the internet after all and, given that Microsoft is a US company, setting any precedent here could be just as disastrous. People must realize that legal force can backfire spectacularly. Imagine what would happen if, rather than siding with those of us who are against Microsoft’s control over secure boot, they instead side with Microsoft? There’s your precedent, and it goes completely against what you were originally trying to accomplish. Given that the US government has a vested interested in keeping their support contracts useful, exactly whom do you think they would side with? If that happens, the EU might contest it, but what are they going to do? Bar Microsoft from selling their products? This, unlike integrated software, isn’t something they can demand a different edition of Windows be produced in order to comply. They could forbid secure boot on equipment sold there but then what? Demand that every OEM make two versions of their products, and pass the extra cost on to the buyer? I say we need to keep the political bodies out of this, if at all possible. Going that route will backfire later, most likely in ways we haven’t even thought of yet.
vaette,
“There is a point there, though I think people are a bit quick to jump to the legal attacks based on the convicted monopolist status of Microsoft. One has to understand that Microsoft is not the only company in the Secure Boot game.”
Microsoft’s monopoly gives them tremendous power to dictate what manufacturers have to implement regardless of the standard. Microsoft’s requirement could outright contradict the standard and manufacturers would be forced to obey whatever microsoft says…. Their monopoly status is exactly what makes them so dangerous to the industry.
What makes you think this breaches existing anti-trust laws? Because while I agree that it’s intended as an anti-competitive move, the courts will see that Microsoft are *requiring* their vendors to provide a “disable secure-boot” function, which kind of defeats the argument. Not only that, they’re offering (for a nominal charge) a certificate service to competitors who might lack the influence to get their own certificates distributed by vendors.
So, you still think enforcing existing anti-trust laws will help?
I didn’t make that assertion. You are leaping from a theoretical argument (that anti-trust enforcement isn’t the same as the government running a business) to a specific claim that I didn’t make (that Microsoft controlling the ability to load signed operating system images on PCs breaches existing law).
The latter would require a court ruling to know for sure.
You would also need a court ruling to know what “the courts will see”, of course. Unless you’re just expressing hope, which is a pretty weak argument.
However, when a company that HAS been determined by the courts to hold an illegal monopoly on PC operating systems makes an “anti-competitive move” in that business area, as you claim… then yes, it makes sense for the Justice Department to act in preparing and (if the facts justify it) bringing to court an anti-trust action.
Obviously, yes.
More important, while signed boot images would only provide a minor additional layer of defense, if the PC industry goes to the trouble to add it, they might as well do it right. And “right” includes an independent signing authority.
Can someone explain to me why they don’t implement a Damn Simple Bootloader in the MBR that is signed and chainloads grub2 from the currently active partition?
Also, why on earth does it seem like none of the UEFI designers ever heard of Trusted Boot? This would be the obvious solution for measuring exactly what you’re loading, but reacting on it only later on after sufficient infrastructure is loaded to flexibly detect the situation(online revocation etc). At the same time, it allows anyone who doesn’t care to load anything they want.
For those who don’t like TPMs, UEFI can implement the necessary base function in software.
Making a signed bootloader that chainloads into an unsigned bootloader would break Secure Boot completely since malware makers would just install your signed bootloader and have it chainload into their unsigned malware (which in turn will set up various hooks then load the OS in a controlled way). This is also the reason why it seems improbable that Ubuntu will be able to do what they are planning to do, since loading a unsigned kernel amounts to chainloading. Malware makers will be able to use Ubuntus signed bootloader and have it launch what looks like an Ubuntu Linux kernel, but which is actually a small piece of malware that just installs hooks and then launches Windows, faking a secure boot.
Trusted Boot does not, as far as I can tell. Load sufficiently early, if a piece of malware manages to write to the MBR it will just refrain from running Trusted Boot and instead load the OS in an insecure way itself.
Edited 2012-06-23 10:16 UTC
As you point out, this is equivalent to chainloading an unverified kernel. So its the same security level as the proposed Ubuntu solution, but you can easily implement it and don’t have to drop the most mature and flexible bootloader out there.
No, trusted boot is started by the initial BIOS and in fact also measures extended BIOS firmware. So its in fact “earlier” than Secure Boot. And it gives you actual evidence of what happened. And it gives you an option to do something about it, instead of just stop booting. And it does not need a revocation infrastructure in the BIOS/UEFI.
Trusted Boot was specifically invented because Secure Boot is unsuitable for general-purpose PCs, where there are multiple parties that can determine what is “legitimate” and what not (you, your company, your vendor, …).
With a system like UEFI and/or SMM, you could even let the TPM chip be implement in software by the BIOS. Still same security level as UEFI/secure boot but much more flexible and also more powerful.
Everybody is talking about Microsoft and how people will or won’t be able to install other operating systems on tablets featuring Windows RT.
But can someone please tell me how can one install Ubuntu, or Fedora or FreeBsd on Apple iPad ? Right now the biggest vendor of tablets and tablet OS is Apple, not Microsoft.
So before asking Microsoft about making it easy for other oses to boot or install, please ask Apple.
Oh, I know, Apple is cool, Apple’s monopoly isn’t bad, Google’s monopoly isn’t bad, the only bad company in IT is MS.
You’re missing the point. MS requires these modifications as part of their compatibility program and it it likely to affect the general-purpose PC market. This means users may unexpectedly not be able to install the software they like.
In contrast, everyone who buys an Apple iPad already knows that he got fucked. It is also common knowledge that special-purpose systems like smartphones cannot be freely modified, they mostly already ship their own proprietary versions of secure boot.
Not quite, though that may be the future. For now, Microsoft requires secure-boot for all Windows8-certified hardware – however, for non-ARM hardware, they also require that the vendor provide a way to disable it.
So for now, at least, tablets and other ARM devices will be completely locked down (as they are for Apple now), but regular desktop/laptop hardware can be unlocked.