Microsoft dragging its feet on Linux Secure Boot fix The Linux Foundation's promised workaround that will allow Linux to boot on Windows 8 PCs has yet to clear Microsoft's code certification process, although the exact reason for the hold-up remains unclear. As The Reg reported previously, the Secure Boot feature of the Unified Extensible Firmware Interface (UEFI) found on …
"Microsoft has previously denied that Secure Boot is designed to lock Linux out from Windows 8 PCs, but the open source community's ongoing difficulties with UEFI have led many to doubt that claim. The Linux Foundation's latest woes are only likely to add fuel to the speculation."
Much as I detest much of what Microsoft has done, I am reminded of the old adage
Never ascribe to malice that which can adequately be explained by incompetence
This post has been deleted by its author
Fool me once, shame on you; fool me twice, shame on me.
Once is happenstance. Twice is coincidence. Three times, it's enemy action.
The fun part about having all these old adages around is that it's often not until you have the benefit of hindsight that you know which one really fits a given situation.
Between this and the browser ballot screw up I can see how someone could read conspiracy into it. I'm no fan of Microsoft (and not excusing the browser situation either), but it seems to me that it might be a little early to cry foul here. Could be wrong of course...
I think that a better example of Microsoft's malicious intent would be their old OEM contracts. Many companies were locked into 'agreements' where they were charged a fee for Windows on every machine produced... regardless of whether Windows was installed or not. Other companies were given significant price breaks if they refused to supply any systems without Windows pre-installed.
If the above isn't deliberate abuse of position, I don't know what is. This current issue just smells like a continuation ofthat ppolicy.
Given the Microsoft history of dirty tricks going back decades (remember the AARD code? Google it if not), I would say it is not too early.
I had a variation on that. Windows NT4 refused to do an image copy of a DR-DOS floppy which came with a disk drive.
The WIn98 installation would give you no choice but to reformat all disks if it found Linux already on the system too; the solution was to physically disconnect the disk with Linux on it while doing the installation.
"Then there was the problem that the entire process of uploading code to be signed assumes developers are running Windows and using Windows-based tools. Even the file upload window required Sliverlight, which ultimately meant there was no way for Bottomley to submit the Linux Foundation's pre-bootloader without loading up Windows 7 in a virtual machine.
Only after Bottomley had completed all of these steps was he able to find out that the code-signing process didn't seem to be working. As of Tuesday, he was still at an impasse."
Ahhh, "Security through obscurity" is alive and well.
This sounds too cunning and devious to be mere incompetence. How can anyone expect ms to go out of its way to ensure that non-ms operating systems, browsers, and applications can smoothly and legitimately obtain, sign, deploy, and maintain working, valid UEFS code?
No, this definitely is fiendishness in play. Otherwise, from ms' perspective, why not just cede the hardware market to anyone refusing to stanch ms' hemhorraging?
Or even better stop forcing tax payers to fund Microsoft in the first place.
All tax payers fund Microsoft whereever they like it or not.
And its things like this that prove do not allow fair competition - thats the reason we're forced to fund Microsoft through taxes in the first place.
They got their monopoly when there was no viable competition - now Microsoft do their upmost to prevent fair competition - the tactics are fully outline in the Halloween Documents - UEFI is yet another example of those tactics.
Slowly but surely the are losing their grip though...
The signed pre-bootloader allows unsigned code to be run. MS don't want to allow OEMs to use the same hardware design for Windows and Linux/Android slabs, it'd cut hardware costs for OEMs and customers would also start to ask questions about why same spec hardware is more expensive if it comes with Windows 8. MS want OEMs all-in or all-out, betting on that they'll decide all-in and lock out the competition.
In the long view, malice is simply a subcategory of incompetence anyway.
Only if there's an afterlife. Otherwise if you can make off with a large amount of someone else's money or other valuables, and get away with it until you draw your last breath, then in the long view malice has paid handsomely.
Sorry, but I disagree.
This is another one of Microsoft's crude attempts at inflicting DRM on the computing public.
The proof of this will be in 3 to 5 years down the road, as corporate PC's get retired, and hit the resale market. How difficult will it be for a second owner to put whatever O/S on it remains to be seen. I have supposed that, in order to "assist" its hardware "partners", Microsoft went down this shitty road. After all, if an OEM can turn a PC into the equivalent of a throwaway toy, like cell phones have become, then why not profit from planned obsolescence.
Its more like fuck the user.
"The proof of this will be in 3 to 5 years down the road, as corporate PC's get retired, and hit the resale market. How difficult will it be for a second owner to put whatever O/S on it remains to be seen"
Not sure what you think the difficulty would be. You don't need Microsoft's assistance or any of the original install keys or discs to replace the OS that is on there. You just go ahead and install what you want, turning off Secure Boot if need be. Secure Boot prevents malware from changing what can boot on a PC, not what a physically present user can install.
Not sure what you think the difficulty would be. You don't need Microsoft's assistance or any of the original install keys or discs to replace the OS that is on there. You just go ahead and install what you want, turning off Secure Boot if need be. Secure Boot prevents malware from changing what can boot on a PC, not what a physically present user can install.
The difficulty is that in the current scheme the root certificate is issued by an untrusted entity. And this cert cannot be substituted for one of choice.
"The difficulty is that in the current scheme the root certificate is issued by an untrusted entity. And this cert cannot be substituted for one of choice."
Firstly, inability to install your own certificates does not stop anyone from installing a different OS which is what Fatman was concerned about. It merely means that you wont be using Secure Boot. Which is the same as with any PCs today. This is the main point as it fully answers the scenario that Fatman raises in thinking you wouldn't be able to re-sell a PC and put something else on it (you can).
Secondly, you're calling Verisign or the manufacturer such as Lenovo an "untrusted entity", at which point you've taken your security concerns way beyond what the vast majority of users do, to the extent that your making an equivalent argument to saying you don't trust antivirus software sellers because maybe you can't trust them not to approve something they shouldn't.
But that doesn't
This post has been deleted by its author
You make sense to me, but pull back the tele a little and step into the wide angle. What exactly is the problem for a multi-billion dollar corporation to have people with no alternative to their product? Paranoid, maybe a little. If someone just bought a windows 8 PC today, and today was the first day they tried ANY alternate OS (in this case Linux), they would feel frustrated and probably never try an alternative today. You have to love options, unless you just bought a Windows 8 PC. This whole thing looks like good ol' fashion business to me. Yee Haaaa Cowboy!!!!
By the way, paranoid is just a state of preparation! :-).
As easy as it is to ascribe this to malice or incompetence there are two good reasons why the company may be dragging its heels. 1) a major release has shipped so a lot of people denied holidays for a long time ate taking them now, and 2) it's US Thanksgiving so not much gets done at a lot of US companies. It's basically silly season from Thanksgiving till New Year. Don't count on max efficiency from a lot of companies who aren't in retail.
Technically the keys don't have to come from Microsoft: you are supposed to be able to install your own keys if you want to (at least on x86).
However, thanks to OEM deals the only keys that come pre-installed when the hardware is shipped are Microsoft's keys. If you want to run Linux "out of the box" without the user meddling with the BIOS settings (sorry, UEFI settings) then the only solution is to use a Microsoft (sub-)key.
"Technically the keys don't have to come from Microsoft: you are supposed to be able to install your own keys if you want to (at least on x86).
However, thanks to OEM deals the only keys that come pre-installed when the hardware is shipped are Microsoft's keys. If you want to run Linux "out of the box" without the user meddling with the BIOS settings (sorry, UEFI settings) then the only solution is to use a Microsoft (sub-)key."
Quoted for truth.
So what's to stop the various linux "manufacturers" (for want of a better word) negotiating with the OEMs to includes their keys in the UEFI firmware out of the box? IE, Why does RedHat not engage with the OEMs and provide it's key so that Red Hat variants are supported out-of-the-box on certain equipment? Seems a nice way to differentiate your product from the sea of alternatives for your customers.
To me, it looks like this:
* UEFI Secure Boot is an industry option, not a MS technology
* Microsoft want to increase security by leveraging it to prevent rootkits (which all non-MS-fanbois cry about Windows being susceptible to)
* Microsoft spend time and money engaging with the OEM partners to get their keys loaded in by the OEM, and to have Secure Boot enabled by default. This probably takes years and a lot of experimentation
* Linux people cry about this, and expect Microsoft to come up with a solution for them, for free
* ???
Am I missing something?
"Microsoft want to increase security by leveraging it to prevent rootkits (which all non-MS-fanbois cry about Windows being susceptible to)"
I'm sorry, but have you even looked into the concept of "Secure Boot"? It only signs the bootloader. It won't make your kernel magically secure, it won't make your userspace magically secure. Your Flash-Player and Acrobat Reader will still be as insecure as before. If you previously got drivers into the kernel, it will still work.
Nobody exploits the boot-process. Why? Simply because in order to even get close to it, you already have full access to the file system. You can read out or change the full system.
Again Secure Boot is a misnomer. It's not designed to provide security, it's designed to turn PCs into games consoles. If Secure Boot would be a security advantage, Microsoft would have provided a special "secure" version of Windows for the X-Box where integrators can, for a price, get their software signed and on a disk so they can use the "secure" hardware of that console.
Do what? 'Nobody exploits the boot-process.' - what a load of garbage.
The boot process is exploited by bootkits and some rootkits (TDL4 amongst others) to ensure their malicious code is ran before the Windows loader, making removal difficult because often even a format and reinstall will *not* get rid of the malware.
The initial infection happens in userspace, but after that, the malware is triggered on each boot.
Secure boot stops that.
"I'm sorry, but have you even looked into the concept of "Secure Boot"? It only signs the bootloader"
Not you again, lecturing people on not understanding things when you actually have it wrong yourself. It only signs the bootloader for GNU/Linux because no Linux distribution has fully engaged with Secure Boot, yet. They are using a signed boot loader as a work around to make Linux run on a system that has Secure Boot on it without actually taking advantage of its intended purpose. On Windows, Secure Boot is capable of checking that all sorts of things (i.e. drivers and other modules) are signed before loading.
"If you previously got drivers into the kernel, it will still work."
Only on Linux. On Windows it offers an extra layer of protection.
"Nobody exploits the boot-process"
Lots of malware exploits the boot process. There are whole families of malware that infect the boot process. You plainly have never bothered to actually read up much on this, instead just deciding to talk confidently without actual fact checking.
How about the possibility of some less than scrupulous open-source developer, fed up with the apparent obstruction from Microsoft, discovering the loophole in the system?
History shows us that cryptosystems, and there has to be a cryptosystem at the heart of this, can have flaws that are not apparent to the users, and the people attacking the system don't need to know how it works. There can be a different route from B back to A.
Having said that, it's not easy, but this is going to be seriously attacked by the virus gangs. They want to have rootkits. So might those awfully nice people at Sony. So it would be a bit foolish to get linked to breaking this security, in a head above the parapet sort of way.
"
"How about the possibility of some less than scrupulous open-source developer, fed up with the apparent obstruction from Microsoft, discovering the loophole in the system?"
Then they would be highly unethical because they would be reducing the security of millions of people.
"
No - publicly releasing it without first having spoken to the vendor and given them time to get their house in order would reduce user security. In fact looking for such flaws is going to be done - I'd rather they were looked for by white hats than black.
Things didn't start falling just because gravity had been discovered.
"Why does RedHat not engage with the OEMs and provide it's key so that Red Hat variants are supported out-of-the-box on certain equipment?"
Nothing in principle. According to RedHat's statement, they investigated doing this and found that setting up the infrastructure to do all this themselves was too costly and it was cheaper for them to simply licence MS's signing capability.
Incidentally, Secure Boot can be turned off. It's not complicated.
"Once you do, if you boot up a Live CD, say, Linux Mint 13, and try to install a dual boot, Linux does not recognize Windows 8 (nor any of the numerous partitions on the hard drive) as a valid operating system. How then to set up a dual-boot system?"
Are you saying you have had this happen to you? Because turning off Secure Boot shouldn't cause you any problems with dual booting. Windows 8 runs fine on systems without Secure Boot. I think you're very misinformed. I don't see how Linux would fail to recognize any of the partitions on the hard drive. Linux has better and wider file system support than Windows.
"So what's to stop the various linux "manufacturers" (for want of a better word) negotiating with the OEMs to includes their keys in the UEFI firmware out of the box?"
The fact that MS will tell them that they will lose their status and ther MS keys if they try it. That's been their MO for decades now, so unless someone has evidence that they've changed I'd assume that's what they're doing now too.
"Am I missing something?"
Lots. The whole point of this is to lock out competition. That's what MS has been about from the days of Windows 1. Apparently you've missed not just an episode but the whole of seasons 1-7 and consequently are unable to follow even the basics of what's going on. Perhaps some boxed sets for Xmas?
> * UEFI Secure Boot is an industry option, not a MS technology
Yes that is always what they do - they keep their monpoly not by playing fair and competition fairly, they hijack existing standards (hey might as well let some other bugger do the hard work) then use their monopoly position to prevent fair competition.
... thanks to OEM deals the only keys that come pre-installed when the hardware is shipped are Microsoft's keys ...
Is that really so? I had the impression (largely from previous articles on El Reg) that the preinstalled key (certificate) would belong to Verisign, and that this would be a root certificate. Microsoft's certificate would then be a subsidiary certificate to be verified using that built-in root certificate. This is how PKIs are meant to work.
All that any vendor (including Microsoft) would have to do to create a signed image would be to generate their own signing keyset and use that to sign the image. They'd also pay Verisign for a certificate for the public part of that keyset and ship the certificate with the image. The UEFI firmware would then the signing certificate using the built-in one, then verify the signed image using the signing certificate, then run the image. It should probably also (at least as an option) flash up a message saying "loading image 'vmlinuz-3.2-generic' signed by 'debian.org'" (or some such, as the case may be) so that the user could see that the image was genuine.
I don't really like the idea of giving Verisign (or any other commercial CA) this much power ... but it's better than allowing any single OS vendor to own the keys.
In a corporate environment I'd expect the BofH to want to be able to change the installed root certificate so that users could only boot images that had been approved and re-signed for use within the organization.
Paris, because she has no clue about any of this, either.
I had the impression (largely from previous articles on El Reg) that the preinstalled key (certificate) would belong to Verisign, and that this would be a root certificate. Microsoft's certificate would then be a subsidiary certificate to be verified using that built-in root certificate.
AC@11/22-00:20 here, to be honest that's the first time I hear about Verisign keys in this UEFI SecureBoot context even though I'm a regular ElReg reader too. Albeit what you describe seems more logical from a technical perspective, this is not how I understood it. Of course I'd prefer you to be right (for the same reason you already stated: less vendor lock-in), but then why the fu- would RedHat go with Microsoft signing services if they could use Verisign?
https://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot The resulting mechanism planned for getting the keys automatically distributed is to utilize Microsoft key signing and registry services.
I'm confused, did I miss something? Care to point me to relevant articles?
"'AC@11/22-00:20 here, to be honest that's the first time I hear about Verisign keys in this UEFI SecureBoot context even though I'm a regular ElReg reader too."
The Reg's coverage here has been high on sensationalism, but rather weak on details. Verisign do provide keys for Secure Boot (I don't know whether or not they provide them for all OEMs, or just some). But obviously the component used for signing must be kept very secure, otherwise security would be compromised. So Verisign provide the keys, but MS have one of them to sign their code with (and they will sign other people's code too for a relatively small fee). Red Hat investigated doing it themself (i.e. they could get a key from Verisign too), but decided that managing that whole process plus the cost involved, was worse for them than simply paying MS to sign their code for them. The link you posted to RedHat is actually a very good link covering their decision. From there, this is probably the most relevant part:
challenge is how to both initially ship and later update the set of trusted keys stored in the system firmware. g all users to manually perform this task would not meet the ease of use objectives. After all, with any security feature if it's too hard to enable it, few will bother to use it and leave themselves exposed.
The resulting mechanism planned for getting the keys automatically distributed is to utilize Microsoft key signing and registry services. This obviates the need for every customer to have to round up a collection of keys for multiple operating systems and device drivers. t will provide keys for Windows and Red Hat will provide keys for Red Hat Enterprise Linux and Fedora. Similarly other distributions can participate at a nominal cost of $99 USD - allowing them to register their own keys for distribution to system firmware vendors.
MS get a key from Verisign, Red Hat side-steps all the hassle of doing it themselves by paying the $99 fee and MS sign it for them.
Sounds like a large chunk of the problems circle around the fact that if you want to get a signed key from MS to run your OS on "MS approved" hardware, you have to use an MS operating system - quelle surprise - which the linux foundation seem to not want to do (references to workarounds etc).
Perhaps if they dropped the pious attitude and just asked MS what to use, spent some money on getting the relevant software and hardware and just got on and did it, they would be a few steps further down the line and closer to getting this resolved.
I mean FFS, theres being a purist and there's just being pedantic to the point of obstruction.
This, they keep saying, is bigger than just some software trickery, some japery by MS - it's an abasement of our freedoms, human rights, etc if you listen to them.
In which case it's important enough to drop the bloody attitude, swallow your pride and just do it the way MS want it done, principals be damned.
And yes, I run Linux, Mac OS, Windows, etc and have no particular allegiance to any of them - I'll call out lunacy and apparent stupidity as and where I see it. And I am, as I always am, happy to be corrected and educated if I've got this topsy turvy.
MS may be making life difficult for the Linux Foundation, but it sounds like they are doing a good enough job of shooting themselves in the foot as it stands.
Steven "Those are my principles, and if you don't like them...well I have others" Raith
"In which case it's important enough to drop the bloody attitude, swallow your pride and just do it the way MS want it done, principals be damned."
Wow! Who agrees with that in regards to anything you buy, not just software? You've been married too long :-). There is 12 steps programs for this friend (just jump to step 6 and smile).
"What about other open source software such as Truecrypt, who aren't a competing operating system, but are going to have problems with full disc encryption."
Shouldn't be a problem, I think. Anything you want to run from the encrypted disk, you will need to decrypt first, in which case the encryption is irrelevant. TrueCrypt creates its own virtual disk driver. Whether you are loading a module from that or from a USB drive or from a real disk, shouldn't matter. It's only when the module is retrieved from the storage "device" and its signature checked, that Secure Boot steps into the process.
But, considering that ms is one to bandy TCO and all the gold-plating buzz words, it stands to reason that ms should not be playing toll-taker or road blocker to helping secure the world's computers.
In the name of TCO and related, ms cannot logically or sensibly get away with this. And, what is to deter corrupt or criminal elements from using ms-ordained components from getting and tainting the keys? It may very well be that ms are taking a hellishly painful road to saintly altruism, but it does not look convincing given that so far it makes the toll much higer to be safe if one is not using ms wares nor has no desire to be funding ms' bottom line.
Am I missing soething fundamentally vital?
Maybe it is more about hemming in South Korean ms-based Internet users. Over 60,000,000 potential business and consumer systems stuck on old securit infrastructure facing a craftily-calculated thread, inducing massive hardware upgrades would produce a tidy sum for ms.
One in Five Online Shops Won't Let Customers Go
http://english.chosun.com/site/data/html_dir/2008/07/31/2008073161018.html
Korea's Internet Is Mired in a Microsoft Monoculture
http://english.chosun.com/site/data/html_dir/2009/10/27/2009102700899.html
Online Shopping Remains an Ordeal in Korea
http://english.chosun.com/site/data/html_dir/2010/01/19/2010011900379.html
Given the stakes involved, it is not difficult to see many Korean hardware resellers and ms exploiting the installed win base. Yes, the articles are dated, but still generally are in play.
"which ultimately meant there was no way for Bottomley to submit the Linux Foundation's pre-bootloader without loading up Windows 7 in a virtual machine.
Only after Bottomley had completed all of these steps was he able to find out that the code-signing process didn't seem to be working. As of Tuesday, he was still at an impasse."
" the most he's heard from Microsoft has been, "Don't use that file that is incorrectly signed. I will get back to you."
So.. they designed it around windows tech. The linux foundation did use windows 7, did what microsoft asked, and the process didnt work anyway due to a broken file supplied by microsoft who are now stonewalling them. You can get off your soap box now and process this information.
Andro - I missed that (or at least it didn't sink in quite so much) when I read it the first time round - fair point. And exactly the offer to be educated I was asking for, along with a few other posts. I've been meaning to credit you for that for a few days now, but been busy at work.
I have been trying to think of similar examples (such as, lets say I have a Netgear router and I want to run Tomato on it - and it's only officially updatable using proprietary Netgear tools - am I going to use those, find they are broken, blog about it and then try to write my own upater, or am I going to do it the other way around, spend time writing my own updater, then try the netgear one after no joy, and then find it is broken - which is a waste of more time) but the thing is that as has been pointed out, it's not like MS own the hardware and software stack.
They simply own the ecosystem - which gives them less right to lock the hardware down. I completely agree with this - and I also completely agree that it's right for the Linux Foundation to be trying to break through this, ideally using OS software.
However, I feel they would have been far better served doing it the MS way first so that they could come out, whiter than white saying 'we've done it the MS way, the MS way is crap, everyone rail on MS, we're going to try to write our own bootloader signer while they fix their tools. And we'll put a fiver on us beating them to the punch'.
Which is what I should have put in my first post, really ;)
Have I still fundamentally misunderstood something here?
Hope that clears that up, all you down-voters. I completely agree with the sentiment of the LF, I find, from a pragmatic standpoint, the implementation by the LF to be lacking, and reeking of the sort of geeky "we know better than you" arrogance that puts people off Linux to no small degree. Which I concentrated on rather more in my first post, somewhat unfairly. That's what I get for reading, and posting, late at night.
*checks time*
Oopsy....
And I say all that having used it daily, as my main desktop OS, for some seven years now!
Steven R
Do the hardware manufacturers not have a version of UEFI firmware that just doesn't look for a signed bootloader, a bit like the alternative loaders for Android handsets? You'd really hope there was an option in UEFI that would simply disable signature checking, or allow you to load your own CA so you could self-certify your own systems...
Microsoft forbids you from having those open bootloaders on ARM-devices. Thus Windows 8 capable ARM devices are essentially useless.
You haven't answered Harry Shepherd's question and in fact have actually given him a pretty misleading answer. He asked about UEFI harware manufacturers generally and only used Android to help explain his question. The actual answer is yes - you can have UEFI hardware not locked to a particular set of signatures. You simply have Secure Boot turned off. The side of the coin that Christian Berger somehow managed to omit is that MS have mandated that a user be able to turn off Secure Boot on x86 devices. This isn't the case on ARM devices which are locked, unfortunately. However, Christian Berger is incorrect to say that such devices are therefore "essentially useless". They're actually very good for running Windows on. ;)
I don't think Microsoft is in a position to forbid that ... it's just that if you choose to sell an Windows RT on an ARM device that enables Secure Boot to be disabled then Microsoft won't certify the hardware.
I'd like to think that this will lead to a large market for Surface WinRT devices clearly marked "NOT certified by Microsoft" to make it clear that you can install other OSes on them ... but that's not going to happen.
As I understand it, though, while Microsoft insist that it must not be possible to disable Secure Boot on RT devices, they haven't said that it must not be possible to change the Secure Boot keys. So they are presumably happy to certify hardware that allows the Verisign/Microsoft key to be removed and replaced with one specific to some other vendor.
What they don't want is to allow Windows booting into an insecure environment because then the user might disable DRM ... it's all about the DRM, really.
Apple: We tweaked our OS so that it will only load on the hardware we make.
Microsoft: We get the OEM to tweak their hardware so that the only OS that'll run is the one we make.
End result: You can only run Apple software on Apple hardware, and you can only run MS software on MS-approved hardware.
Between Metro, Windows Phone and the UEFI lock-in... does any one else feel that MS is desperately trying to become an Apple clone?
> End result: You can only run Apple software on Apple hardware, and you can only run MS software on MS-approved hardware.
Not quite. You can only run MS-approved software on any (non-Apple) hardware.
I find it difficult to believe that MS will get away with this.
I sense a "bios" setting for "MS-ONLY" which provide defaults to UEFI.
I have yet to see Windows for MIPS (I have three MIPS boxes). How about Windows for Raspberry Pi? (Windows RT requires a later generation of ARM CPU.) One of my other two ARM boxes could in theory run RT - but that would use all of the internal flash.
I have one Intel box left. When it dies, Microsoft have given me an excellent reason to replace it with an ARM - and I doubt the RT will be around that long.
NT 4.0 had a version for MIPS back in the 90s. Microsoft was porting to every architecture that might pick up where Intel left off back then. PowerPC, Alpha, and MIPS all had folders in the NT 4 install disc to handle a wide array of possible machines. Windows CE ran on even more architectures, like Hitachi's SH series, as seen in some ports of PC games like Tomb Raider to the Sega Dreamcast. WinCE provided the DirectX APIs to simplify the task.
But Intel surprised itself and kept ramping up more powerful chips and the status quo continued. Windows 2000 was available for Alpha and DEC had a very impressive x86 emulator that got faster as it ran a particular app but they all faded away as the market for x86 alternatives int he desktop sector never extended beyond Apple in any big way.
There was a standard called CHRP intended to make PowerPC systems into a DIY platform comparable to the PC. IBM had a port of OS/2 Warp for it and it appeared there was some hope for diversity. But one of the first things Steve Jobs did on returning to Apple was pull the plug on their participation in CHRP. This was part of killing off the licensing of Mac OS to outside computer makers. Without Apple CHRP was quickly dead.
As far as I'm aware Vista SP2 or later will install on a mac, as will many linux distros. Earlier versions of Windows will on a Mac with the help of Bootcamp.
Android is available for some iDevices. Apple won't help you install it, but it doesn't look like they go out of their way to stop you.
"Microsoft: We get the OEM to tweak their hardware so that the only OS that'll run is the one we make."
Not quite. Windows 8-RT the above statement is true, for Windows 8 it should read something along the lines of.....
Microsoft: If you want to have your hardware certified to run Windows 8, and get the little sticker to say it is certified, you must ship it with Secure-Boot enabled, but you must give the option for the user to turn it off.
", but you must give the option for the user to turn it off."
...Actually, the word is "can", not "must". So long as SecureBoot is turned on *by default* with the MS key installed, the OEM is under no obligation to provide a method to turn it off for the HW to be approved by MS.
"...Actually, the word is "can", not "must". So long as SecureBoot is turned on *by default* with the MS key installed, the OEM is under no obligation to provide a method to turn it off for the HW to be approved by MS."
I don't know where you got that from. It's incorrect. Here is a link to MS's hardware certification requirements for Windows 8 PCs. LINK
From the section on Secure Boot (around page 118):
""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:"
OEMs are absolutely under an obligation to allow users to disable Secure Boot to be turned off if they wish to comply to with MS's terms for certification. Why did you choose to "correct" someone who had it right?
Just a bit more, in case the previous seems ambiguous without context, here is the following paragraph:
18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv."
Also, apologies if the last part of my previous post came across as hostile. It just seemed very strange that you would tell somone the word was "can" instead of "must". You made it sound like you had read the specification, when actually the OP has the wording right.
Well, the original wording was 'can' not 'must'.
It was changed shortly after all the original furore, when MS originally disclosed the requirement.
Whether evidence still exists for the original wording is a moot point, no doubt it's still there if you search hard enough. I certainly saw it, along with all the thousands (millions ?) then, but I can't be bothered to search.
Provided none of the OEMs are still using an earlier version (as justification), then when W8 dies its natural death, then it'll be a problem no longer.
Err, no. The end result is that you can only run MS software on MS-Approved hardware if you can't deal with the frankly pathetically simple process of:
At boot time:
Press the button to enter the UEFI
Go to "Security"
Select "Secure boot"
Switch "Secure Boot" to "Disabled"
Save settings and exit
I just did it because I was helping one of our devs install Linux onto his laptop (Lenovo Thinkpad W530). He had been bitching about secure boot and how it was all a conspiracy, until I showed him just how easy it was to switch off. This prompted a "is that all you have to do?", followed by a "Yes, now shut up about it."
I just did it because I was helping one of our devs install Linux onto his laptop (Lenovo Thinkpad W530). He had been bitching about secure boot and how it was all a conspiracy, until I showed him just how easy it was to switch off. This prompted a "is that all you have to do?", followed by a "Yes, now shut up about it."
So you can re-flash the UEFI from Linux (or other non-MS utility) with a UEFI of your own, with your own signing key and without MS's revocation rights? You know, so that the UEFI could secure-boot a non-MS OS?
It'll be a different process for each machine/manufacturer's implementation of the UEFI, so no reference possible. Sorry.
Too bad. I was hoping for the existance proof of a single non-idiotic implemtation.
I foresee a future of malware bricked consumer devices.
.
"So you can re-flash the UEFI from Linux (or other non-MS utility) with a UEFI of your own, with your own signing key and without MS's revocation rights? You know, so that the UEFI could secure-boot a non-MS OS?"
No. There's no flashing of firmware involved or anything remotely like that. You just power on the computer and enter UEFI, just like you would enter BIOS (typically, you press F1). Then you just select the option for Secure Boot and turn it off. You can then boot any OS you choose. You wont then be using Secure Boot.
This means that you can't benefit from Secure Boot with Linux if you do this, but no Linux distro really makes use of it at this time anyway. The signed boot loaders that RedHat and Ubuntu are providing don't really provide any security. All that they do is enable you to use a Live CD to demo or install their Distro without having to go into the UEFI and turn Secure Boot off. Beyond that initial boot loader, there's not much protection to be gained by using Secure Boot with Linux. Hopefully one of the main distros will make use of it in time.
The free software community's willingness to "play nice" with Microsoft's nonsense is going to bite them in the ass. This is "day one" of this UEFI garbage and already Linux is having "problems."
Talk about a "solution" to a problem that doesn't exist. Or rather only affects Microsoft's operating systems. UEFI isn't needed by any other OS, only WinDOS. Well that and as a convenient way to deal with the "Linux problem."
They are more than welcome too, it is standard rather than a microsoft product. However if they did it would be anti-competative and rightly be blocked. All the Linux community have do to is to work with the OEMs to get their certs. added to the approved list on new hardware and there is no issue. The subject of the article is getting their code signed by Microsoft so they can use the certs that Microsoft have already worked with the OEMs to add.
It wouldn't be a problem, because the Linux community doesn't have a massive monopoly position with OEMs, and therefore wouldn't be able to twist sufficient arms to get them to install the stuff on their kit.
The problem isn't UEFI or Secure Boot in itself, it's Microsoft's abuse of its monopoly position in order to make it very difficult (if not impossible) to install any other operating system.
"The problem isn't UEFI or Secure Boot in itself, it's Microsoft's abuse of its monopoly position in order to make it very difficult (if not impossible) to install any other operating system."
If you don't have a problem with UEFI or Secure Boot, then why you do have a problem with Microsoft when their own requirements demand that it be possible for a user to turn off Secure Boot on any WIndows 8 PC? Have you thought about how useful Secure Boot would be if it were turned off by default? Obviously not.
Yeah, because there would be millions of people anxiously looking to install Windows on machines sold for running Linux.
It's pathetic, really. After twenty years, Linux is still dependent on the Windows hardware market to provide machines to install upon outside of specific markets where the OS has no identity for end users to consider, such as DVRs and other appliances. If there were really a viable market for, say, an Ubuntu tablet, it would be trivial for an OEM like Acer or Asus to make a generic model with no boot loader security active by default. But is there enough market to make it worth their trouble? It is a very different investment from a generic PC line that a fairly small company can produce and support.
Forget secure boot. What the Linux community needs to do is come up with a little sticker certification scheme of it's own - like "Certified to run professional OSes" or something like that. Something that would work as a nice side-swipe against Windows, but also tugs at that desire of both OEMs and consumers to have the "certified" label giving an extra level of faux confidence, undermining the whole "certified for Windows" schtick.
If the alternative certification can gain enough consumer mindshare... OEMs will rush to make their hardware more open. We are seeing the exact same thing with Android phones and tablets now where OEMs are seeing the benefits (in consumer mindshare) of making it easy to unlock their bootloaders.
"Why won't the virus writers simply bundle the pre-bootloader with their "products"?"
A couple of reasons. Firstly, they can't bundle the bootloader (it's not a "pre-", btw), because only a signed bootloader will be executed, so any malware has to start further up the chain. Secondly, the bootloader is for GNU/Linux so their malware actually has to target this platform rather than Windows. Well it doesn't have to, but you'd essentially be writing malware that infected Linux and then unloaded Linux and booted up Windows. Possible but very cumbersome. The install base of GNU/Linux is far smaller than Windows and most of the roots to infect the boot process would be opportunistic and thus target Windows.
I wrote above that it's not a "pre-" bootloader. I was incorrect. My argument is still the same, but they are now using the term "pre-bootloader" as well because (although this is a bootloader), they are using it to boot their normal boot loader. So I guess it is a "pre-" bootloader in a sense. Apologies for the wrong correction.
Here is what is going to happen when I buy UEFI computer.
Boot up and disable secure boot in the UEFI.
Boot up from PC-BSD or Gentoo Live CD.
Delete Windows 8.
Install something that works and is not screwing me over. Like Windows 8 is sure to do.
Or try and buy a computer without Windows 8 to start with.
"You can't disable secure boot on all systems."
Then buy a system where you can disable it. (Isn't that supposed to be a requirement for Win 8 certification or something, funnily enough?) I imagine the resulting loss of sales will encourage manufacturers to reconsider their stance, and the continued sales will encourage those who allow people the choice.
"I imagine the resulting loss of sales will encourage manufacturers to reconsider their stance"
I think, in the manufacturers' reality we are light years away from reconsideration. The manufacturers need the volumes Windows brings and even more so as the margins they get from the Win-hardware are minuscule. There just isn't any remarkable alternative/channel to offer the volumes, that an OEM could abandon Win8-label/OEM-contract for sustainable revenue. And that is the position Microsoft takes full advantage of and has nursed it well for taking it over the PC business as witnessed here.
The episode put simply; this is the end of an open PC era. There are now only Apple and Windows computers available easily. This is a take-over of PC brand as an open platform as people, especially techs, are used to think about it. And as this is a tech forum, there are and will be hugely Microsoft-fans among techs, who don't give a s* for alternatives, what should also make a point to a tech to think about.
I just think that playing with Microsoft and Apple for "their" hardware to be useful with alternatives is just worthless when thinking in scales. The options like cracking the Secure Boot or playing the games Microsoft sets just don't work in scales. Something big needs to happen and I can't see any of that big yet, but this Microsoft's move will certainly raise needs for the big to happen and that is good.
The big needs to take a feasible piece away from Microsof's OEM stranglehold ie. Microsoft needs to set up its own hardware and channels like Apple does. And that I find Microsoft's disadvantage. They really need to maintain the general attitude toward Windows as an open platform, at least more open than Apple. Now a buyer has alternative brands to choose hardware to run Windows and now that is more than enough for many. But the game isn't over.
The big could come from Google, since I find that Microsoft's position and history of actions does warrant Google for actions here. But what I can tell, it seems that Google has only toyed with something like Google-terminals for its services and Google may be pleased with and set to Android. And I, at least, am not interested in yet another game console alike.
Another approach may come, or may not as this is pure speculation about the big, from the change of the ISA platform as what goes as PC platform in future. The change may open the game better for ARM and for other specifications/chips and for game setters. Intel may not like this much and warrants its actions to maintain the open PC platform as we are used to know it.
UEFI Secure Boot and Microsoft's position over the signature key are definately a hallmark in PC business as open technical platform and as an platform to make business free from players like Microsoft.
This is just my interpretations. I may be wrong and do not warrant for any correctness and/or suitability to others mindset, get it as "as-is" as usual in software licenses.
Here is what is going to happen when I buy UEFI computer.
Or try and buy a computer without Windows 8 to start with.
Or what will work for the technically able of us:
Buy a server system which is offered for sale without an OS and stuff it full of RAM.
Disable secure boot and install Linux or *BSD of choice
Run virtual machines in it.
that's all I would like to know. I don't care anymore what operating system or logo is on my computer. Just let me not be hassled please. I don't care about the user interface either....Microsoft are a dinosaur and besides windows and midtown madness...I really don't care for their software.
I'm ready for the commodore 64 with the SID chip.
"how to disable this secure boot that's all I would like to know"
When you power up the computer, press the key to enter set up. Typically <F1>. Then mouse or cursor to the option saying: "Secure Boot: Enabled" and toggle it to "Disabled" or "Off". Exit and let the computer start up. It's much like changing the boot device in BIOS.
"And if the user can do it, any malware that gets into kernel mode can do it."
No. Because kernel mode doesn't have access to change the UEFI settings. The user does it by going into UEFI on power-up, just like they would go into BIOS and changing a setting. Just because the OS says something can be done, does not mean that the firmware will agree.
The last time I bought a complete desktop PC, it was a very early Tandy MS-DOS machine. Ever since, I have been assembling the things from parts, maybe saving a few quid on the cost, and knowing I can replace anything. My previous machine ran XP, and eventually became too old as standards changed--PATA replaced by SATA for instance. I have this uncomfortable feeling that Windows 7 is the last in the chain, still the familiar UI and handling modern features such as 64-bit software and multiple processor cores. And the networking drivers are a lot better than in XP.
How is UEFI going to affect that?
As for dealing with Microsoft, sup with a long spoon. I pretty much only have Internet Explorer on my system to connect to Microsoft's web sites. It doesn't really surprise me that the Linus Foundation is having problems, and some of it could well be down to their way of using Windows.
I can think of quite a few software outfits, from Microsoft down, and including a few Linux distros, which have the "my way, or the highway" attitude. It works if you have the sort of monopoly Apple and Microsoft have. When it's the hardware+software combined, as Apple do, the end result can be worth it. But it does have a cost, for all of us.
In the end, we're all different, and there cannot be a single universal solution. But that is what Microsoft are trying to be.
So reading the article the show stoppers are:
(1) The signing process requires uploading from a Windows machine. Perhaps galling if you want to avoid having one in your house for reasons of principle, but from a practical point of view I find it ridiculous that the people in charge of getting Linux code signed should hold this up as a difficulty. XP, Vista and Win7 machines are ten a penny. If it's for a good cause, I have one that they can have.
(2) They have had to create an account with Microsoft. This is so stupid an objection that they should be ashamed to raise it.
(3) The signing Terms and Condiitions are incompatible with GPLv3. Well so is a good portion of most Linux distributions Linus Torvalds and most of the top Linux Developers are against licensing Linux under GPLv3 and for some of the same reasons MS can't allow it under their Terms and Conditions. GPLv3 has some major blocks when it comes to patents and DRM. This as an objection is both unreasonable and it is unnecessary as most (all?) GNU/Linux distributions are actually under GPLv2.
(4) The signing process hasn't worke and they're still waiting for MS support to get back to them. We're missing some details here. Did it fail because the people uploading are unfamiliar with the process and did something wrong? Or is it buggy software? And how long have they been waiting? Did they file this three months ago or was it last week?
Of these listed objections, only the last one may or may not be valid depending on the details. One thing I am confident of, is that if it turns out Bottomly was doing something wrong, we wont see headlines on it or scores of posts here angrily blaming him or lack of a signed Linux bootloader (even though it would have turned out he was culpable rather than MS).
I completely agree.
From the article "As near as Bottomley can tell, there's a problem with the key he has been trying to use to sign the software, but the most he's heard from Microsoft has been, "Don't use that file that is incorrectly signed. I will get back to you.""
So either there is a problem with the key that he has been issued with, or that he is using it incorrectly. Either way it does not feel that this is evil at work.
I think that Microsoft are doing this because they know how bad windows 8 is, and that a lot of people aren't going to like it, so are preventing people 'jumping ship' onto linux. I know that for a lot of people, vista was the big tipping point that made them try other things, such as ubuntu, and I know many of them that haven't looked back since.
You are totally correct. Microsoft care more for their Hollywood chums than their customers. Vista was spyware and W8 will no doubt be the same.
http://www.zdnet.com/microsoft-patent-spies-on-consumers-to-enforce-drm-7000007102/
I will never use Microsoft products again.
All the user has to do is to disable secure boot in the UEFI, and they can install whatever they want. I feel that if someone gets to the point that they are happy to replace their existing OS with completely different one, asking them to change 1 setting when the machine boots is not the end of the world.
That's all very well unless you want to dual-boot - if you disable Secure Boot then Windows 8 won't start.
Plus it's confusing for non-techies who want to try Linux - all the blurb online says "Just pop the CD in your drive and reboot". Having to describe how to disable Secure Boot in any of 500 different kinds of UEFI/BIOS setup screens is going to be more tricky.
"That's all very well unless you want to dual-boot - if you disable Secure Boot then Windows 8 won't start."
Seems massively unlikely that is true. You can install Windows 8 on machines without Secure Boot, after all. Evidence please.
What gives you the confidence to assume all PC hardware manufacturers will allow you to disable secure boot ? Microsoft suggested them they can do it not that they must do it (after all they can't dictate to OEMs, can they?).
What gives you the confidence to assume all PC hardware manufacturers will allow you to disable secure boot ? Microsoft suggested them they can do it not that they must do it (after all they can't dictate to OEMs, can they?).
MS have specified that you have to be able to turn off Secure Boot if you want to advertise your PC as certified by them for Windows 8. That's a fairly powerful marketing draw. Besides which, what would OEMs have to gain by making their product less able than a competitors?
...why do I get the feeling it'll be a complete flop?
UEFI is a stupidly top-heavy spec that contains provisions for (for example) adaptor ROMs on expansion cards written in interpreted languages so that the code can run regardless of the CPU of the machine into which the card is installed. Almost nobody (outside Intel, where they worry about Itanic getting sidelined) has ever needed that in the past, and even now that ARM is becoming more significant in the desktop and server markets it will be needed by very few.
Unfortunately, though, the GUID partition table -- the format that's currently needed to enable a system bootable from a hard drive larger than 2.1TB -- is a part of UEFI, and no manufacturer has had the balls to implement support for GPT without the rest of UEFI. We need GPT, or something like it, but we arguably do not need (most of the rest of) UEFI. Secure Boot is actually one of the better bits, or could be, if it were used as intended to protect the user's interests rather than the OS vendors interests and those of media publishers.
I do agree that it's a little silly that my nice modern desktop still has to boot using a 16-bit BIOS before loading the 64-bit OS ... but while we're on the subject of aphorisms I have one of my own:
If it ain't broke, don't fix it!
In passing, you don't need a UEFI BIOS to support disks >2Gb with Linux, provided you are happy with the plural. Once a linux kernel is up and running, it'll handle a disk with a GPT without any use of the system BIOS.
So boot off an SSD for a faster system. Or load your kernel from a USB memory stick if you want it cheap. Or off a CD (try root-kitting that!). Or even put that old 80Gb drive back to use.
"In passing, you don't need a UEFI BIOS to support disks >2Gb with Linux, provided you are happy with the plural. Once a linux kernel is up and running, it'll handle a disk with a GPT without any use of the system BIOS."
That's actually the same as under Windows. It's the "up and running" part that UEFI solves. With either Linux or WIndows, you can't boot off a disk 2TB or larger (note, you wrote 2GB, this is incorrect). WIth UEFI, you can (under either).
"This UEFI thing... why do I get the feeling it'll be a complete flop?"
Possibly because you don't understand the difference between UEFI and Secure Boot and aren't aware that pretty much all modern x86 motherboards are shipping with UEFI instead of BIOS and that this has already been the case for some time. I have a motherboard here I bought about a year ago. And it has UEFI. Quite possibly you are using it now as well.
People often ask, is it Microsoft compatible. Maybe we should be asking if Microsoft is compatible with a real world that is cross-platform. Do they really make any effort to be compatible? Seems to me they MS up standards, not to improve them, simply as a barrier to compatibility. This latest debacle will problem end up in court as with so many others, the problem is court proceedings often take years and as Microsoft know well judgements come to late. If there were a legal equivalent of a red card Microsoft would have had it enough time to be looking at a lifetime ban from any kind of sport. Some will say, yes they play to win.... but they don't even play by the same set of rules as the rest! Still, their empire is crumbling.
Having read the original blog post it appears that Microsoft have given Linux Foundation a signed binary, however accidentally signed it using their own identity rather than that of the Linux Foundation - whoops!
So the Linux Foundation are currently in the position where they could release (or leak) a working bootloader, but they have chosen not to because they don't want to piss Microsoft off - information completely missing from this article.
This post has been deleted by its author
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
