Shuttleworth: Why Windows 8 made us ditch GPL Linux loader Ubuntu daddy Mark Shuttleworth has defended Canonical’s decision to play ball with Microsoft's Windows 8 security policy that could stop “unauthorised” Linux builds from booting on new PCs and tablets. Manufacturers must enable a feature called Secure Boot in their products' UEFI firmware in order to be officially labelled …
I bet they have had this in the planning stages for a couple of years; waiting for the DOJ "watch period" to expire.
Now, as you have succinctly put it, "Back To The Dirty Tricks Again".
Most people have not realized what this may do the the eventual secondary resale market for used computers. Consider this possibility - a specific machine can not boot ANYTHING but the originally installed O/S, not even an upgrade to a newer version of Windows.
PC, and tablets become LIMITED LIFESPAN THROWAWAY DEVICES - JUST LIKE CELL PHONES.
After contemplating that one, see who benefits most??
M$ dear hardware partners.
You just bought a brick, just like the throwaway bricks called cell phones.
BOHICA: (Bend Over Here It Comes Again!!)
FAIL - because there is no other appropriate choice.
Oh my fucking Cliche`, Cliche`, Clichet'.
I will be happy when another land mine Microsoft lays, gets the customer waltz.
I don't support ungay activites such as hacking and all that - nor malware because that is very very ungay.
But I do support the idea of legitimate users hacking Microsofts bullshit to get their lives lived with the minimum of idiotic impediments.
$10 to the first person who can disable or break MS's boot loader blocking.
I rather doubt the SFLC told him any such thing but we'll probably never know for sure as the SFLC are not about to admit that one of their 'clients' lied about the advice he was given. It being privileged information etc.
What it looks like is another example of the "Not-Invented-Here" mentality which seems to have infected Canonical over the past couple of years. The alleged 'concern' over their signing key is simply a convenient excuse. One he's grabbed with both hands.
Unity instead of Gnome/KDE, Upstart instead of Sysvinit/Systemd and now the Intel bootloader instead of Grub2. What's next I wonder?
Hopefully this nonsense won't affect us too much as we build all our own systems and only use a customised Xubuntu build for desktop machines.
If it does then we're buggered because we don't buy enough hardware to be able to exert any influence over our suppliers.
Follow the logic with me here. If Ubuntu signed a GRUB2 loader and it got distributed, then, under the terms of the GRUB2 license, the signing key would also have to be distributed.
So. Microsoft is signing a GRUB2 loader and Fedora is going to distribute it. So, under the terms of the GRUB2 license...
Microsoft's signing key would have to be distributed? Or have I missed something here?
Paris, because she misses most things.
That is certainly what Mark Shuttleworth would have you believe but it simply isn't true.
The very fact that Microsoft have agreed to provide a signing service for Fedora should go a long way to convincing you that he's lying.
We all know how obssessive Microsoft are when it comes to protecting themselves. There is no way in hell they would risk having to release their signing keys. Or anything else for that matter :)
Canonical are required to provide the source code for their signed object module. If a someone else distributes it in a device context that requires the signed code to be verified, the someone else, not Canonical, is required to provide both the source code and the installation information needed to install a possibly modified version of the compiled object. The someone else could satisfy their GPL v3 obligation by providing to the user the capability to sign and install code compiled from source. The only circumstance in which Canonical's private key would be required is if the Canonical public key in the target device could not be replaced by the user. In that case, the "someone else" would be out of compliance with the GPL and might be compelled to stop distributing the product. Canonical would not have a GPL problem, any more than Fedora will have a problem with the object modules they sign using the key they obtained from Verisign. Microsoft's signing key is not at issue in this context because they do not knowingly provide source code for their programs.
Ye gods, how many thousands of pages of irrelevant conspiracy theorist tosh and gallons of freetard spittle have been wasted on this topic? There will only be about 3 people in the world who will even want to load a new os on a winRT tablet..... If it matters to you that much buy a frikkin android tablet
"The rules are relaxed for Intel x86-powered systems and user-generated signing keys are allowed on this platform. On ARM systems, however, customised keys are forbidden and only a limited set of keys are recognised. It’s part of an emerging Redmond policy to lock-down Windows 8 ARM tablets to head off crashes, bugs and hacks."
My mistake, I thought both would include the same exemptions or not. I can understand ARM being locked down. It's their tablet. I've no wishes for more walled gardens on desktops though.
ARM is not "their" (i. e., Microsoft's) tablet. The first W8 tablet was announced a few weeks ago by either Acer or Asus (I don't remember which).
And the W8 certification requirement for ARM-based equipment is that secure boot may not be disabled. I am not clear whether it allows installation of alternative product keys on W8 certified hardware, but guess probably not. For x86, the corresponding requirement is that disabling secure boot must be allowed, but there is no requirement I am aware of that it be possible to install keys to enable secure boot of other operating systems.
Secure boot is not an intrinsically bad thing, but Microsoft's W8 certification requirement appear to have a substantial anticompetition component in addition to possibly questionable security benefits.
None. I'm going to keep saying this until everyone in the world reads it, if necessary: the Windows 8 x86 certification requirements specifically require that the user be able to disable Secure Boot.
"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."
http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256
One month then M$'s keys will be in the public domain. I think the hackers of all flavours will find it just too tempting.
Have they thought of what will happen when their keys are broken and the hardware is rendered useless.
Bill's boys will need deep pockets.
Why not put a switch / jumper on the hardware that enables / disables.
"... switch/jumper on the hardware ..."
An excellent idea. Requires physical access to the hardware and a person who knows what they are doing. i.e. the sort of people who would want to install various flavours of another OS.
However: why would manufacturers do this if they can take the easy way out and do what Microsoft tell them to do?
What Microsoft tells them to do is that they must include a firmware configuration option to disable Secure Boot.
"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."
http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256
Maybe they've sorted out a key revocation and renewal system? They're not stupid. The problem with DVDs/BluRay, etc etc. is that the keys are physically installed on the disks and can't be changed. There is nothing to stop computers keys being updated and stored in static ram.
"There is nothing to stop computers keys being updated and stored in static ram."
Except for physical installation media. But that's probably why Microsoft is pushing people to download Windows 8 from their online store instead of purchasing it in a brick and mortar shop.
Furthermore, updating from a leaked key to a fresh key would require installing the new public key from a potentially compromised system, which might allow anyone to install a "trusted" public key even for malware, unless Microsoft plans on forcing users to boot into the UEFI config to add the new key manually.
How do you get the new key on there? How do you revoke the old ones?
What happens when the 'master' key used to do the above is leaked or discovered?
If you accept that you need a revocation mechanism because individual keys might get exposed and thus need revoking, you must also accept that all keys could suffer that same fate.
The 'master' key is clearly the biggest prize...
That could be easily accomplished by the use of a 3 contact Berg stick and a DIP jumper in line with the write enable lead to the flash chip.
If you get a MB mfgr that is SO CHEAP that those few tenths of a cent of additional cost "hurt the bottom line"; then simply design the circuit with a "cut away trace", or a "bridge point" to allow the write enable line to be toggled.
IOW - no fucking "big deal" for a MB mfgr that gives a shit about their customers, and isn't licking Ballmer's boots, currying favor.
"Today [2009], as announced by Google open-source programs office manager Chris DiBona, the number of open-source projects licensed under GPLv3 is at least 56,000." My beard is not long enough yet to make this a proper hyperlink http://news.cnet.com/8301-13505_3-10294452-16.html
Why all the gnashing of teeth about Microsoft preventing WinRT tablets from running alternative systems? As far as I understand it, it's only a requirement to have this lockdown in order to get the Win logo on the device. They can sell the same device without the Win logo and without this lockdown to anyone who might want to stick another OS on it? If someone wants to put Linux on it, surely they're not going to be dissuaded from doing that because the device is missing a Windows logo??????
If we're worried about restrictive practices in the tablet business, why aren't we focusing on the market leader, Apple, which has taken legal and technical measures to stop you running either iOS (or OSX) on non-Apple hardware?
What I would like the FTC to do it to require a distinct label on any consumer device that restricts the consumer's ability to re-place the manufacturer supplied software with software of the user's own choosing.
I suggest that for devices that are LOCKED DOWN, the logo include high stone (looking walls) and an iron gate (aka "jail bars"). Colloquially known as a WALLED GARDEN. (get sinister with this http: //scorechicago.files.wordpress.com/2008/08/walled-garden.jpg)
For devices that allow the user to replace installed software, the logo should include a 'meadow view' that includes the clear sky. (try starting here http: //www.eddiebyrne.com/wordpress/site/images/SteamboatSprings_HotSprings_HighMeadow.jpg)
Oh, and BTW, the logo for the locked down device must be 3 times the width, and 3 times the height of the minimum size specified for the 'open device', and have a bright red border around it.
"If someone wants to put Linux on it, surely they're not going to be dissuaded from doing that because the device is missing a Windows logo??????"
You've got that the wrong way round. If someone wants to run the Windows it came with, they might well want to see the logo. Particularly if there is a competing device sitting next to it in the shop that has the logo. Therefore, at least as far as the manufacturer is concerned, the device needs to have the logo.
Perhaps the FSF (or Google, if they are feeling non-evil today, or merely antagonistic to Microsoft) should start a "logo program" and make *insecure* boot a requirement. That would mean that hand-held devices could not have both logos.
"You've got that the wrong way round. If someone wants to run the Windows it came with, they might well want to see the logo."
That's only a secondary reason. The real power of the certification requirements is that you have to meet them in order to buy OEM Windows licenses from Microsoft at a substantial discount. If you don't meet the requirements Microsoft won't sell you bulk OEM licenses for your hardware; the only way you can pre-load Windows would be to buy a bunch of licenses at retail, which obviously costs way more. So in practice, as an OEM you have to comply with the requirements if you want to pre-load Windows, or else your costs will go through the roof compared with your competitors.
Part-way through the installation process, a marching band comes high-stepping down the corridor into your cubicle playing "Don't click that malware button!" at 130dB accompanied by fireworks and strobe lights, and you click "yes I want to be anally raped by baboons on WebTV pay-per-view" anyway because that's what you do, clicky the linky.
Ninety-nine times out of a hundred Joe Soap will clicky the linky no matter how much warning you give them. I may be underestimating the ratio a bit, though.
I assume Mr. Shuttleworth refers to conditions in GPL 3, para. 6 ("Conveying Non-Source Forms") which requires, in part, that "installation information" be conveyed with covered object code in cases where the object code is part of a "user product." In such cases, source code and installation information must be provided, and for secure boot that could be read so as to possibly require including the private signing key corresponding to the public key installed in the product.
I believe this interpretation is incorrect with the remotely possible exception of such user products as Canonical might develop and offer. I have not heard of such products, either present or planned, and the Ubuntu GNU/Linux distribution itself does not appear to be a user product as defined in the paragraph. Otherwise, it is incumbent on the manufacturer of the product (not Canonical) to provide the required source code and installation information. Nothing requires the manufacturer to install Canonical's public key in the product, but if they do, they probably can comply with the GPL (V3) only by providing the source with information about how to create, install, and use user-generated keys. It is hard to imagine that they could compel Canonical to help them out of *their* GPL v3 violation. (This is the example Mr. Shuttleworth's gave in answer to my question.)
Alternatively, a manufacturer could generate and use their own keys to sign the software. If they do so, they can comply with the GPL by providing their signing key (not likely) or (again) by providing the purchaser a means to generate and install keys and sign software. The user then could install Canonical's public key to enable update of Canonical's distributed software. Canonical's private key would be unnecessary.
It might be good to have laws that exempt all private keys from disclosure, but I don't see the security and police establishments buying into that.
tl;dr summary: Please be accurate about the Microsoft Secure Boot requirements. For Windows 8 on x86 hardware, Microsoft *explicitly requires* that the user be able to disable Secure Boot, and enrol their own signing keys in the firmware. For Windows RT on ARM hardware, Microsoft explicitly requires that the user *not* be able to disable Secure Boot or enrol their own keys. Please, for the sake of accurate debate, understand the requirements and keep them in mind.
All of this has been stated umpteen times, but apparently dozens of people still don't understand, so let's say it again. I've also written this almost identically in several direct replies. Sorry, Reg, but it's eminently clear that lots of people just aren't getting the message, so the only way to do it is to go around bashing it into their skulls forcibly.
Secure Boot is a neutral part of the UEFI specification. It says nothing about specific implementations. Let's just get that out of the way as the starting point - Secure Boot _per se_ is just a standardized mechanism to allow code executed from the system firmware to be signed and verified against a list of keys stored in the firmware.
Microsoft runs hardware certification schemes for OEMs. To say your system is certified for Windows and to get good terms from Microsoft to pre-load Windows on your system, you have to comply with the certification requirements. (Otherwise you'd just have to buy all your copies at retail, which in practice, no-one wants to do). So we can simplify and say that pretty much any system sold at retail with Windows pre-loaded must comply with Microsoft's certification requirements. This is Microsoft's lever in this case: the Windows certification requirements. They are public: you can read the entire thing in yawn-inducing detail here - http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256
Here are the relevant Secure Boot requirements, verbatim (order reversed because one is much shorter and simpler than the other):
"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. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.
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:
1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
3. 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."
In other words, exactly as stated in the tl;dr summary, for Windows 8 on x86, the system *must* allow the user to disable Secure Boot. A manufacturer *cannot* ship a system where you can't disable Secure Boot and comply with the Microsoft requirements.
For Windows RT on ARM things are much more restrictive; such systems truly will be locked down and it will be more difficult to load alternative OSes. Of course, this is much the same as almost all existing ARM cellphones and tablets. It's also worth noting that Microsoft is in no kind of dominant/monopoly position in the ARM device market; there will be far more *non*-Windows RT devices than Windows RT devices.
The twerps overwrote my PCs MBR with their defective initial 10.0 release. Major fail. I've still not forgiven them.
Every time you boot it, there's 2700 updates available. Need to be an IT weenie to sort through the meaningless names to figure out what should be updated.
Amateur hour.
PS: No, I'm not interested in solutions. I'm just grumbling. ;-)
FWIW, having dealt with all manner of bootloader issues in validation for several Fedora releases, I am firmly of the opinion that it is literally impossible for an operating system installer / updater to correctly handle all possible BIOS/MBR bootloader configurations.
The whole BIOS / MBR system for handling boot is a horrible design, fundamentally wrong in so many ways. Funnily enough, one of the few really good things about UEFI is that it has a much saner system for handling multiple boot configuration.
So please have sympathy for OS developers in trying to handle BIOS-based boot. It's an impossibly difficult job...
Sorry about the MBR problem, never seen it on my various XP dual booting laptops over the past couple of years.
You are not just grumbling you are also spreading FUD in regards to updates. Give me a system that keeps my OS AND software up to date over the Windows model any day.
Your 'amateurs' remark would be quite funny if it were not for the fact that Windows is developed by people paid to it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
