backtop


Print 59 comment(s) - last by alcalde.. on Jan 22 at 7:16 PM

Anti-Android crackdown would make Apple proud

Microsoft Corp.'s (MSFT) UEFI Secure Boot technology -- the long-awaited BIOS replacement -- has some people concerned due to its digital rights management features, which can be used by OEMs to prevent dual-booting to other operating systems like Linux.

Microsoft Windows President Steven Sinofsky sought to assuage disgruntled Windows users, writing:

There have been some comments about how Microsoft implemented secure boot and unfortunately these seemed to synthesize scenarios that are not the case so we are going to use this post as a chance to further describe how UEFI enables secure boot and the options available to PC manufacturers. The most important thing to understand is that we are introducing capabilities that provide a no-compromise approach to security to customers that seek this out while at the same time full and complete control over the PC continues to be available. Tony Mangefeste on our Ecosystem team authored this post. --Steven

Quick summary

UEFI allows firmware to implement a security policy

Secure boot is a UEFI protocol not a Windows 8 feature

UEFI secure boot is part of Windows 8 secured boot architecture

Windows 8 utilizes secure boot to ensure that the pre-OS environment is secure

Secure boot doesn’t “lock out” operating system loaders, but is a policy that allows firmware to validate authenticity of components

OEMs have the ability to customize their firmware to meet the needs of their customers by customizing the level of certificate and policy management on their platform

Microsoft does not mandate or control the settings on PC firmware that control or enable secured boot from any operating system other than Windows.

In other words, Microsoft isn't forcing laptop and desktop makers to ban Linux, though it's giving them the tools to do so.

That statement rebuked previously claims of a Red Hat, Inc. (RHT) Linux engineer who posted:

Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely.

A system that ships with only OEM and Microsoft keys will not boot a generic copy of Linux.

...

Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM.

Or does it?

Computer World's UK correspondent Glyn Moody dug up this interesting tidbit in Microsoft's ARM license.  Writes Microsoft in "Windows Hardware Certification Requirements" for client and server systems, a document that regulates licensing (certification) (pg. 116):

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. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure MUST NOT be possible on ARM systems.

In other words dual-booting Linux on a standard x86 desktop should be no issue.  But if you were hoping to load dual-booting Android and Windows kernels on a Windows 8 tablet (which will likely have an ARM) CPU or on certain notebooks with ARM chips, think again.  Microsoft could soften its stance and/or users could find a way to break its DRM protections -- but there's no guarantee of either outcome.

Windows with ARM
ARM on Windows 8 -- don't you dare dual boot. [© DailyTech/Jason Mick]

In this regard Microsoft is very much "following in Apple, Inc.'s (AAPL) line".  Apple has long prevented dual booting to Linux or the installation of OS X on non-Apple computers.  Apple does allow Windows installation via Boot Camp, but only via a special understanding with Microsoft who cross licenses patents with Apple.

Windows 8 was a star of the show at the 2012 Consumer Electronics Show and is expected to land in tablets and PCs this fall.

Sources: MSDN [1], [2], Red Hat, Computer World UK



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: Possibly illegal?
By alcalde on 1/17/2012 9:21:02 PM , Rating: 2
>It seems all of your rage stems from poor reading comprehension.

Sadly, no. Now you're going to proceed to inform me that not only myself but Computer World, top engineers at Red Hat, etc. are all reading it wrong. Steve Jobs would be proud. But please continue.

>This does not block vendors from signed linux builds (actually,
>what linux build doesn't support this?).

There is no such thing as a signed Linux build today, and it's a very gray area whether any such key would need to be made public per the GPL licensing requirements, rendering secure boot null and void.

From an end-user standpoint, I don't even know where you're going with this. Are you suggesting vendors are going to want to ship ARM tablets and laptops with desktop Linux pre-installed along with Windows 8? If that's not happening with x86, it's not going to happen with ARM.

>All this requires is that the secureboot feature remains intact and
>is not disabled.

Again: that's all? That trivial little thing means that the end user can't install another OS on their device. In practicality, that means that Linux users won't be able to buy/use any high-end tablet or any future ARM laptop, period.

Let me quote from Mr. William of the Software Freedom Law Center:

“The Certification Requirements define … a ‘custom’ secure boot mode, in which a physically present user can add signatures for alternative operating systems to the system’s signature database, allowing the system to boot those operating systems. But for ARM devices, Custom Mode is prohibited: ‘On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable.” [sic] Nor will users have the choice to simply disable secure boot, as they will on non-ARM systems: “Disabling Secure [Boot] MUST NOT be possible on ARM systems.’ [sic] Between these two requirements, any ARM device that ships with Windows 8 will never run another operating system, unless it is signed with a preloaded key or a security exploit is found that enables users to circumvent secure boot.”

I hope that's clear... end users will not be able to disable secure boot and they will not be able to add their own keys . This kills Linux on ARM (even though it's more advanced than Win8 for ARM at this point as it is a full desktop implementation). Microsoft is using its OEM clout to prevent end users from installing Linux on their own paid-for devices which is anti-competitive, especially as Linux has no advertising or marketing or shelf space and relies on end users being able to try it for themselves for free (and pioneered the live CD for that reason).

>They even have a clause in there saying that they do not maintain
>responsibility if the vendor wishes to sign different means of
>firmware control.

The vendor also loses Windows 8 certification, which is suicide for them and is never going to happen.

>And I did not say that it was alright for this to happen due to
>precedent.

Then I wish posters would spend even 1/8 the time addressing the badness of this action and raising a fuss about it that they spend attacking those who are upset about it or changing the subject to other companies and products.

>What I meant was that secure booting has been used for quite some
>time, yet this one particular instance where secure booting is
>enforced seems to be getting the blame for setting precedence.

Again, there's a difference between secure boot (which no one has any problem with) and implementing it in such a way that the user can't choose to boot the operating system of their choice.

MS is exceeding precedence as they are an OS vendor. They are not a manufacturer locking down their own item. Their policy will require other OEMs to lock their products (who might not have otherwise done so) and will affect perhaps dozens of products over the next several years. Google, HP (webOS), the Linux community, Samsung & Intel (Bada and Tizen) have not required anyone using their OS to lock their boot loaders, so yes, this is precedent. Apple doesn't sell or license its OS to third parties.

> I don't know why google isn't getting blame for allowing vendors
> to bootlock, and also bootlocking their very own nexus.

Given that Android is open source, Google doesn't have a lot of say in the matter. All it can do is deny access to its proprietary apps and app store. As we saw with Amazon, that didn't keep Amazon from forking it and creating their own App Store (and Amazon would probably welcome any other product vendors who wanted to tie their device to Amazon's app store in the future). Honestly, Google has already lost control of Android. I don't know enough about the Nexus to know whose decision that was, but one phone is not close to being an entire new class of products.

>basically, microsoft did not create this feature, microsoft did not
>promote this feature, microsoft did not set precedence and
>microsoft is not forcing people to only use windows. this is just
>digging for dirt that doesn't exist.

1. "This feature" is not the issue. It's MS' decision to require OEMs to not allow the custom mode that exists in the feature set specifically to allow users to change their OS that's the issue. If I beat someone over the head with a toaster, the manufacturer of the toaster is not morally blameworthy. I love secure bootloading. I've got full-disk encryption and a BIOS with flashing disabled now and would like to get a TPM (trusted platform module) to do secure boot in the future. It's not being able to change the OS that's the issue and that's not a problem with the standard.

2. MS is demanding OEMs prevent custom mode. That isn't promoting it, no; it's demanding it .

3. As already covered, MS did set precedence unless you tell me which OS vendor mandated OEMs to disallow other OSes on devices it's installed on (without going back to the original IBM PC).

4. Microsoft is forcing users who get Windows to stick with Windows. Also, if the ARM laptop market emerges like the x86 laptop market (Windows pre-installed on anything) then they will will indeed be forcing those who want ARM laptops to use Windows.

5. Dirt that doesn't exist? When I can pick up the first ARM laptop that comes out and install my desktop OS of choice, OpenSUSE Linux, on it, then the dirt won't exist. Until then, you lose all credibility with that claim. It's getting positively Orwellian when MS has specifically stated that Linux won't be able to run on these devices and MS defenders tell Linux users with a big smirk on their face, "No it doesn't. I don't know what you're talking about. You're just making stuff up."


RE: Possibly illegal?
By someguy123 on 1/18/2012 12:19:32 AM , Rating: 2
Like I said, poor reading comprehension. Secureboot is what is being used here. Secureboot is what stops the enduser from signing their own builds. You do not lose windows 8 licensing for signing various other builds. Secureboot is also not required for w8 x86, only ARM, likely due to the inconsistency of ARM designs on the market, which increases likelihood of bricking a device via booting an unsigned OS. GPL/GNU/MIT openness does not stop linux builds from being signed as secure.

The only thing being asked is for secureboot to remain enabled. The end user is being stifled, but your beef is with the industry at large for supporting secureboot.


RE: Possibly illegal?
By alcalde on 1/18/2012 2:32:52 AM , Rating: 2
>Like I said, poor reading comprehension.

No, poor reading comprehension is refusing to address the refutation of your arguments which include many items that simply aren't true or are directly misleading to the less informed (all the stuff about signed Linux when MS is disallowing users to add their own keys, etc.) You've shown yourself to be a fanboy on a mission and no one's going to buy your spin.

>Secureboot is what is being used here. Secureboot is what stops the
>enduser from signing their own builds.

For the 100th time, oh master of reading comprehension, ARM vendors are specifically prohibited by Microsoft from allowing users to enter their own keys. Secure boot works just fine and preserves user choice when users can enter their own keys. Why don't you e-mail the engineer Matthew Garrett at Red Hat (Red Hat being part of the company that created the UEFI spec including secure boot) and tell him that he's wrong about the spec his company helped create and that it's his "poor reading comprehension" and that of his co-workers that made the document they put out explaining how to preserve the safety of secure boot while still allowing users to install their own OS is wrong. Then you can address their claim that Microsoft is using the spec in a way it wasn't intended to be used and explain to them that it's their poor reading comprehension there too.

>You do not lose windows 8 licensing for signing various other
>builds.

I don't know what argument you're making, but you're completely off track. Who the $#%# is talking about what the vendor can sign? What we're talking about is that devices shipped with Win8 ARM will not allow users to enter their own keys or disable secure boot so they cannot load any other OS onto the product. You seem to think this isn't a problem because in theory a vendor could ship an ARM device with what, all thousand or so Linux distros and Android keys built-in? Seriously? In what universe would that happen?

>Secureboot is also not required for w8 x86, only ARM,

You'll discuss everything except why an ARM device owner with Win8 can't install their own operating system, won't you?

> likely due to the inconsistency of ARM designs on the market,
>which increases likelihood of bricking a device via booting an
>unsigned OS.

Ok, so your new theory is that this is being done out of love by Microsoft to save Linux and Android users from themselves? Wow... just wow. It's not even the OEMs themselves who are concerned about this... just the OS vendor who will already have their money. Yes, I can see Steve Ballmer lying awake at night worrying about Android users who've bricked their Win8 devices.

>GPL/GNU/MIT openness does not stop linux builds from being signed
>as secure.

Next you'll be listing the capital of Kansas and the average lifespan of the water buffalo... are you one of those lawyers who attempt to deliberately confuse a jury to get a mistrial? Please stop talking about signing, you're making a fool of yourself. All the signing in the world doesn't matter if the key can't be entered into the device, and no vendor is going to pre-load the device with the key of any operating system that anyone might want to install someday.

>The only thing being asked is for secureboot to remain enabled. The
>end user is being stifled, but your beef is with the industry at
>large for supporting secureboot.

Secure boot is wonderful. I love secure boot. I want secure boot on my PC. The problem isn't with secure boot. It's with not being able to enter keys or disable it when needed. It's like your my neighbor blasting rock music at 3AM and keep telling me over and over that I must hate rock music and I should take up my issues with the maker of the electric guitar. I don't have a problem with rock music; I have a problem that it's 3AM. See the difference?

As Mr. William of the Software Freedom Law Center said (and I don't expect you to address) “Before this week, this policy might have concerned only Windows Phone customers. But just yesterday, Qualcomm announced plans to produce Windows 8 tablets and ultrabook-style laptops built around its ARM-based Snapdragon processors. Unless Microsoft changes its policy, these may be the first PCs ever produced that can never run anything but Windows, no matter how Qualcomm feels about limiting its customers’ choices. SFLC predicted in our comments to the Copyright Office that misuse of UEFI secure boot would bring such restrictions, already common on smartphones, to PCs. Between Microsoft’s new ARM secure boot policy and Qualcomm’s announcement, this worst-case scenario is beginning to look inevitable.”

Note the word "misuse". Secure boot was intended to prevent malicious code from running at boot, not other operating systems. Both Red Hat (again, who helped CREATE UEFI) and the Linux Foundation put out papers addressing how to use secure boot CORRECTLY - in a way that still let users install the OS of their choice. Microsoft ignored their papers for three months and then produced this policy anyway. Until you address this fact and stop going off on tangents about signing Linux, I'm done with you and I'm sure any reader who's followed your non-responses is too.


"Mac OS X is like living in a farmhouse in the country with no locks, and Windows is living in a house with bars on the windows in the bad part of town." -- Charlie Miller














botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki