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: Not that big a loss.
By pixelslave on 1/16/2012 1:56:06 PM , Rating: 2
I never expect the ARM version of Win 8 tablets would have an unlock bootloader. Just look around, how many unlocked SoC devices are out there?

I am putting my eyes on the x86 Win 8 tablets, however. The chances a x86 PC makers would lock their machines are next to zero. Given that Google made clear the x86 version of Android will be released this year and will be developed in parallel with the ARM version from now on, this is where we can find our heaven to install a stock Android OS onto.


RE: Not that big a loss.
By Labotomizer on 1/16/2012 2:30:57 PM , Rating: 2
Not only next to 0, but absolutely 0. The licensing terms for Windows 8 dictate that the option must be available to disable secure boot in an x86/64 in the BIOS/UEFI settings.


RE: Not that big a loss.
By AntiM on 1/16/12, Rating: 0
RE: Not that big a loss.
By Mitch101 on 1/16/12, Rating: 0
RE: Not that big a loss.
By Cheesew1z69 on 1/16/2012 4:47:19 PM , Rating: 2
/me rolls eyes


RE: Not that big a loss.
By Spuke on 1/16/2012 11:42:29 PM , Rating: 2
quote:
This is ok because it probably takes 256 cpu cores for Android to run smoothly without stuttering but wont prevent the Android OS from crashing and freezing.
Sounds like a short between the touch screen and the floor to me. Android runs as smooth as my sister-in-laws ass on my phone.


RE: Not that big a loss.
By Helbore on 1/17/2012 5:07:11 AM , Rating: 3
Why would you have your sister-in-law's ass on your phone?


RE: Not that big a loss.
By bupkus on 1/17/2012 9:56:30 AM , Rating: 4
Pics, please?


RE: Not that big a loss.
By TakinYourPoints on 1/17/2012 1:43:39 AM , Rating: 2
I don't know why you got downvoted, I agree, the more security options for enterprise the better. Android tablets aren't being deployed partly due to security issues. iOS has this nailed down and it's a major reason why it is being deployed, on top of guaranteed hardware/OS support from Apple and the superior developer ecosystem. Lord knows that security is a top priority for Microsoft in all of their products.

Allowing the ability to lock down the boot environment is one more big plus to getting wide deployment of Windows 8 tablets in enterprise.


RE: Not that big a loss.
By alcalde on 1/17/2012 4:58:51 PM , Rating: 2
>I don't know why you got downvoted,

Because he's being incredibly selfish to only care about himself and incredibly foolish to believe MS' claims.

>I agree, the more security options for enterprise the better.

This isn't a security "option". It's a mandate. Months prior to this policy, two groups presented MS with ways to achieve the security without interfering with the rest of us. They completely ignored both of them, put out smirking replies playing semantic games (including refusing to address linux by name), and now this drops, which they probably hoped no one would notice.

There's no security reason to not allow users to choose to either add their own keys or disable the secure boot option. When an OS vendor makes it a requirement that products that use its OS not be allowed to use any other OS, that's being anti-competitive. This is different from a hardware vendor locking their own device, which is anti-consumer but not impeding their competition.

>Android tablets aren't being deployed partly due to security
>issues.

This has nothing to do with Android deployments in the enterprise. This has to do with users being able to choose what software runs on their hardware. And if the solution to Android security issues is "let's run Windows", there's a clear lack of understanding of the # of threats available on each platform.

>Allowing the ability to lock down the boot environment is one more
>big plus to getting wide deployment of Windows 8 tablets in
>enterprise.

What you're talking about doesn't exist. There isn't "the ability to lock down the boot environment". There is a locked down boot environment and the inability to unlock it.

You never explained how not giving users the ability to install their own OS makes a device more secure (other than more secure for MS, because users can't decide they hate Win8 and install Android or WebOS, or better yet a full desktop Linux distro, instead).


RE: Not that big a loss.
By gilboa on 1/17/2012 5:07:40 AM , Rating: 2
... Secure boot has nothing to do with rootkits.
If someone gains access to your machine he doesn't really need to alter your boot environment in-order to infect it with a rootkit.
Secureboot may or may not reduce the chance of installing a hypervisor like rootkit on secured machines - but even this has yet to proven.

Lets be honest, secureboot is a lock-in tactic; nothing more, nothing less.

- Gilboa


"Well, there may be a reason why they call them 'Mac' trucks! Windows machines will not be trucks." -- Microsoft CEO Steve Ballmer














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