LWN: Comments on "SFLC: Microsoft confirms UEFI fears, locks down ARM devices"

Oh yeah, the secret so deep, the secret so hidden, the secret so unbelievable… that everyone knows about it.

khim — Fri, 10 Feb 2012 13:21:02 +0000

You forgot about eglibc, dietlibc, etc. And for xlib there is xcb and xcb-xlib as well.

Which does not change anything. EGLIBC strives to be source and binary compatible with GLIBC and dietlibc is rarely used as glibc replacement. Microsoft, too, offered numerous version of MSVCRT: Windows 7 includes three or four "out of the box".

The important thing is not to decide when to add something but when to remove something. And the typical answer: years after the replacement is available. FCB was introduced in MS DOS 1.0 (in 1981) and deprecated in MS DOS 2.0 (in 1983). It was supported till "grand unification" of Windows (in 2001). And still some people complained because Windows XP broke their beloved WordStar.

Now, some interfaces are abandoned much faster (think DirectMusic) and then Microsoft is [rightfully] hated - but these are rare exceptions, not rules. In Linux world... yes, we have kernel, yes, we have glibc and xlib... and that's about it. Well, GTK+ comes close. Everything above is subject to sudden breakage. And while compatibility is possible (as someone pointed out you just need to pull bunch of old libraries from older versions of the distribution) it's not automatic: user must manually find and install these libraries, etc.

At some point it just becomes too tiresome and people switch to Windows or MacOS. Where things work "out of the box" and you desktop looks like a desktop not as Tamagotchi.

Oh yeah, the secret so deep, the secret so hidden, the secret so unbelievable… that everyone knows about it.

mfedyk — Fri, 10 Feb 2012 11:47:27 +0000

You forgot about eglibc, dietlibc, etc. And for xlib there is xcb and xcb-xlib as well.

On another note, when are we going to get x protocol extensions that integrate the nx protocol and a module that does compositing into xorg? These would solve nearly all of the issues that make people want to work on wayland.

Long live X!

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

PLee — Sun, 29 Jan 2012 13:20:48 +0000

It isn't just general lockout that ms wants. They will be be loss leading to gain market share and they wont want to subsidise android aftermarket installs or lose bing revenue.

They'll be ok with phones and tablets but I'd expect the regulators won't like it if we see pc interface ultraportables with lockouts.. I would hope google points out the anti-competitive behaviour to the regulators anyway - "look! see what the monopolist does! Android phones can be modified by owners (cyanogen), but ms, look where they are going!"

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

jospoortvliet — Wed, 25 Jan 2012 14:54:18 +0000

It's not about phones but laptop- and tablet devices. I for one are looking forward to an affordable, reasonably powerful ARM based laptop on which I can run openSUSE. But it's highly likely that those won't come to exist as the ones which get mass-produced are Windows only... In the PC world you can simply wipe windows and have your nice device, the only downsides being the Microsoft tax and possibly hardware support issues. In the ARM world - you're out of luck.

Sorry, but this is not true

khim — Fri, 20 Jan 2012 06:27:44 +0000

The code verification chains for the three popular consoles have been cracked repeatedly.

Sorry, but no. Only Wii (which apparently had security bolted on after the initial design) can be broken using only software without any specialized hardware.

XBox360 does not have any software exploits: all the existing break-ins require hardware modifications.

PS3 was only broken once, that happened half-year after removal of OtherOS and was quickly and efficiently remotely patched: if you ever upgrade your PS3 to firmware version 3.56 you'll lose the ability to break the code verification chain. The time where you had the ability to use PSN on cracked console was short indeed.

One of the obstacles to disassembling and finding weaknesses in the code verification chain seems to have been that the relevant code has been embedded within ASICs and/or encrypted.

Right - this is natural next step. This will happen eventually. Actually this is already true for ARM devices (they usually are built as a single SOC with many different chips tied together) - perhaps this is why Microsoft is more concerned about them? It knows x86 will be crackable for a few more years anyway...

Viruses?

BenHutchings — Fri, 20 Jan 2012 06:08:03 +0000

The code verification chains for the three popular consoles have been cracked repeatedly. The PS3 seems to have been left alone for a long time because OtherOS let people run their own software legitimately, but was cracked fairly quickly after Sony removed that feature in a firmware update.

One of the obstacles to disassembling and finding weaknesses in the code verification chain seems to have been that the relevant code has been embedded within ASICs and/or encrypted. But neither of those are being proposed or are likely to be practical in a general-purpose PC.

Oh yeah, the secret so deep, the secret so hidden, the secret so unbelievable… that everyone knows about it.

elanthis — Fri, 20 Jan 2012 04:33:36 +0000

> Well, he's right: developers make or break your platform. And developers want stability. Not UI stability, but ABI stability. They want to create binaries once and sell them for a long, long, time. What they absolutely don't want to do is to keep few versions of them, recompile them for all existing distributions, etc.

So very, very true. I'd argue this extends beyond the library ABIs as well, of course, to things like the software installers. It's still very frustrating that a developer has to build like 50 packages of the same application for major distros on the Linux desktop.

FOSS is nice and all, but regular people want to just be able to click and go without needing to dick around with building source, and regular developers don't want to have to spend their time working around a broken distribution platform and breaking ABIs.

Oh yeah, the secret so deep, the secret so hidden, the secret so unbelievable… that everyone knows about it.

sorpigal — Fri, 20 Jan 2012 01:39:47 +0000

+1 million, the truth.

IMO API stability would be enough to begin with, but nobody does that either.

I like to say it like this: Microsoft succeeds by thinking about the platform first. In Linux there is no platform above libc (except maybe xlib).

Viruses?

raven667 — Fri, 20 Jan 2012 00:46:04 +0000

I don't think you understand the security implications of how this verification works, it's not a cakewalk to get around. This has been proven in practice on game systems for example, it took a looooong time to break and didn't stay broken for long. It's good enough for the intended purpose. You have to compromise the first step in the process or nothing else matters, you can't exploit a vulnerability until you can run code under your control. Things only get murky when the full os loads and starts loading user supplied code. The more that can run before user supplied code is run the less murky it gets

Viruses?

BenHutchings — Thu, 19 Jan 2012 23:59:11 +0000

Precisely. The firmware, which is written by only the most talented software developers and consequently bug-free, will only start a signed bootloader (Windows Boot Manager, which is bug-free) which will only load the signed Windows kernel (also bug-free), which will only load signed drivers (all of which are definitely bug-free). There is no way at all for a virus to hook into this process. ;-)

Viruses?

raven667 — Thu, 19 Jan 2012 18:40:14 +0000

I think the point of this is that you can boot to the point where you can run antivirus before it is possible for a virus to (re)infect the system and the virus can't break the boot process without breaking the signature checking, bricking the OS.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

cortana — Thu, 19 Jan 2012 16:41:16 +0000

I think it's a reference to 1984.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

mpr22 — Thu, 19 Jan 2012 13:26:36 +0000

MS defeated netbook Linux by virtue of the netbook Linuxes being potent vessels of fertilizer. (Seriously, the Linux that shipped with my Eee 900A was awful.)

Viruses?

NRArnot — Thu, 19 Jan 2012 11:24:40 +0000

I wonder if Microsoft has given any thought to malware, viruses, etc?

Certainly secure boot will make sure that the kernel and anything that can access the hardware has not been rewritten in an unauthorized way. However, I expect that there will still be plenty of mischief that can be initiated at higher levels, including exploits of bugs in the O/S to make it impossible for the active system to detect that it has itself been interfered with.

The best anti-virus scan is offline. Boot a scanner off a read-only medium, scan using an operating system thereon which is immune to whatever is on the hard disk being scanned because it executes nothing from this source. An approach which Microsoft has decided to render impossible on ARM devices. Hmmm. Good news for no-one, except possibly Intel!

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

wookey — Wed, 18 Jan 2012 15:31:47 +0000

<blockquote>being able to change the keys is mandatory for Windows x86 computers. That's a big relief. </blockquote>

We do ourselves a huge disservice by allowing a distinction of acceptable lockdown between computers by architecture. ARM computers are computers just like x86 computers and run Linux and Windows just the same. We are just on the cusp of the time when ARM stops being an arch used only in phones and tablets and you get ARM servers, laptops, desktops, home-server, NAS, PVRs.

If you don't feel this is acceptable on x86 then you shouldn't feel it's acceptable on ARM either. I feel this is outrageous. It's true that locked-down bootloaders is not new, but this is going to be _standard_ locked-down bootloaders, enforced by an outfit with a great deal of power to get manufacturers to do what it wants. MS may have negligible penetration of Windows on ARM, but the windows network effects are achitecture-independent, in that if you need MS project for line-management at work, it makes no difference at all whether the machine is x86 or ARM. Except that if you tried to save energy by using ARM machines, you can't switch to Linux any more.

Most of the engineers here use Linux desktops, with a windows VM for the few things you need one for (filing expenses, project management stuff). We are keen to move desktops to ARM as soon as it's practical. EUFI lockdown could seriously hamper that process unless non-locked-down hardware is widely available. Purchasing aren't going to like having to buy different lenovo boxes depending on which OS they will put on it - they don't have to currently.

Maybe it'll be OK, and it _could_ backfire in that it'll keep Windows out of some areas (like server sales) but I'm not terribly optimisitic. MS did a good job of defeating the netbook linux option without this little advantage. I suspect they can do it again in laptops and desktops. Servers, probably not.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

Trelane — Tue, 17 Jan 2012 03:12:53 +0000

And their PC OEM agreements. It's "odd" how the usual suspects shipping Windows boxen en masse end up on the latest MSFT boat.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

Trelane — Tue, 17 Jan 2012 03:07:58 +0000

I wonder how/if this intersects with their android patent licensing.

Netbooks and price points

man_ls — Tue, 17 Jan 2012 01:08:16 +0000

I agree with most of your post, except for one detail.

Microsoft didn't 'manage to shift' anything.

In fact they did: they lowered the price of Windows XP to a point where it was no longer a big % of the machines' prices. It is true that offered a choice of Linux and (similarly priced) Windows people went with the latter. It is no less true that when the Windows machine was $100 more expensive, people went with Linux. This is not blaming Microsoft or anything; they did the smart thing and lowered their prices to match the demand.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

fluxion — Mon, 16 Jan 2012 20:32:55 +0000

I think you're focusing to much on my usage of the word "shift". My concerns are entirely grounded in our mutual agreement that neither linux or Android is in a position to take the desktop market from Microsoft. If it was, we could rely on having a fair share of non-secureboot ARM workstations at our disposal.

My point is that this time around, we won't have a chance to even try before Microsoft completely locks desktop linux out of ARM with secureboot, and Android finds itself the only contender to push back into that space, a space that I worry it will never be targeted toward. This leaves the future of linux being overwrites on toy gadgets designed to running Android, which would be a sad state of affairs.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

juliank — Mon, 16 Jan 2012 19:57:27 +0000

Microsoft Windows percentage in the ARM market is 0%. Microsoft has no dominating position and thus cannot be prevented from doing stuff like this. It's just a small outsider group.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

juliank — Mon, 16 Jan 2012 19:53:43 +0000

It is more likely that the chip's bootloader starts UEFI which then starts the system's bootloader.

Boot loader (chip) => UEFI => Bootloader (System) => Kernel

Oh yeah, the secret so deep, the secret so hidden, the secret so unbelievable… that everyone knows about it.

khim — Mon, 16 Jan 2012 17:59:21 +0000

A very careful examination why Android has succeeded while the traditional "Linux distribution" approach to making a smart phone OS failed utterly is in order, also.

Very careful examination? Didn't you mean "5 second glance"? You do remember this video, right? Where crazy Microsoft CEO dances on scene?

Well, he's right: developers make or break your platform. And developers want stability. Not UI stability, but ABI stability. They want to create binaries once and sell them for a long, long, time. What they absolutely don't want to do is to keep few versions of them, recompile them for all existing distributions, etc.

Linux (the kernel) actually is pretty good here: while it has "no stable API" policy this policy only cover kernel. User-space ABI is sacred and Linux developers take regressions very seriously. Thus, surprise, surprise, Linux (kernel) is used on billions of computers around the world - but only on tiny percentage of desktops.

Why? Well, desktop people (and ever in-kernel desktop-related people) are breaking everything regularly. It's not a new phenomenon (I've already discussed it few years ago) but it's still valid. When you read maemo 4.0.x is not API compatible with earlier releases you know that someone decided to shoot his foot again.

And if you shoot his foot again and again and again… then limping is kind of expected, right?

Note: stable ABI is strict requirement, but of course it's not enough to drive your platform to success. You need to do other things, too. But if you don't offer stable ABI then it does not matter what else you'll do.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

drag — Mon, 16 Jan 2012 12:36:21 +0000

Non-MS netbooks were inferior. Almost all of them had shit or otherwise hacked up Linux systems that could not install any software or do much of anything. The only people that put out decent systems were Dell and Acer.

When netbooks were first released the Linux ones were the best sellers. That boat quickly sailed. Linux had it's chance and it was roundly rejected by the people that purchased them. There are a few here and there that liked them, but there was virtually no repeat customers.

Microsoft didn't 'manage to shift' anything. Blaming Microsoft for Linux Desktop's failure is just means that you completely ignore any possible lesson that can be learned here.

A very careful examination why Android has succeeded while the traditional "Linux distribution" approach to making a smart phone OS failed utterly is in order, also.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

fluxion — Mon, 16 Jan 2012 00:47:12 +0000

My concern is that while MS has missed the boat in the mobile space, Android is late to the party, or not even looking at, the ARM-based workstation space. I can't replace my work computer with an Android-based laptop, it's just a whole different space, content consuming rather than production.

MS on the other hand is doing their dual UI thing in Windows 8 with a traditional UI paired with Metro. They're late to the mobile space, but they'll be the only ones at the table in the ARM-based workstation space (I mean, there's plain linux, but that's still not a household name), and they can use that position to bully their way back into the mobile space by locking linux/Android users out from higher-end ARM machines. Not a whole lot of people want linux on their phone now, but when they start getting acquainted with this notion that their workstation OS has been designed to run just as effectively on their phones/tablet, that might change.

We've seen it before with when linux got the jump on MS with netbooks...eventually Microsoft manages to shift users into thinking non-MS machines are inferior, hits all the right pricepoints, and next thing you know nobody is shipping linux netbooks anymore. I can see that happening again with linux and Android on ARM laptops, except this time around we'll be screwed. We'll end up being relegated to running linux on ARM machines that were designed for Android, and the higher-end stuff will be off-limits. And the machines designed for Android will become scarcer if Microsoft succeeds in making the in-roads they're trying to making with Windows 8 and Metro.

It may be a bit gloom and doom, but it seems just as realistic to me as Android taking over the mobile space seemed did when I bought my G1. So I find it pretty scary...

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

boog — Sun, 15 Jan 2012 23:30:47 +0000

What will matter in the end is whether we have a large enough choice of devices where the user can install keys. I don't doubt that MS's intentions are bad, but luckily they may never reach any kind of critical mass on ARM. They have so far completely missed the boat on phones and tablets. And they still have the problem of moving their software over to ARM. Moreover, as prices go down, the cost of windows is going to be an ever bigger burden.

Still, it is certainly worth making a fuss about, as this is a defining issue about who controls your device. We don't want too many people following MS's example.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

fluxion — Sun, 15 Jan 2012 22:06:03 +0000

that's great and all, but it still means we'll no longer be able to install linux on our laptops when the PC market starts shifting to low-power ARM notebooks/tablets that are quickly closing the performance gap with Intel/AMD and doing so without requiring a charge every 4 hours or so.

Microsoft is preparing for the very possible end of the x86 era, and us linux users are gonna be completely stonewalled when it happens. Backing off on x86 is nothing more than clever marketing. Microsoft is not at risk on x86, they don't care if you can install linux/Android on PCs, but it's a different story on ARM. All they've shown by backing off on x86 is that they're aware of how secureboot can be exploited to curb competition, and that they're very much willing to utilize it for markets where it's worthwhile for them to do so.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

Wol — Sun, 15 Jan 2012 20:35:32 +0000

As I understand it, UEFI calls the bootloader, so no, that's not technically possible ...

Cheers,
Wol

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

Rudd-O — Sun, 15 Jan 2012 12:31:29 +0000

Microsoft?

LYING?

Oh, wow, couldn't have seen it coming...

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

JanC_ — Sat, 14 Jan 2012 22:43:12 +0000

So, what if ARM bootloaders provided an option to bypass loading the available UEFI payload, would that comply with this requirement? :P

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

mjg59 — Sat, 14 Jan 2012 10:51:05 +0000

It does. Windows 8 on arm requires UEFI and ACPI.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

andypep — Sat, 14 Jan 2012 10:13:07 +0000

This looks like enforcing market division to disallow ARM to compete with Intel on the enterprise desktop. The rules allow for companies to replace any pre-installed Windows with one of their own standard customised setups. But they are prevented from doing that to any ARM-based tablets, etc. that they may wish to purchase.

ARM or other OEMs that supply tablets may have an anti-competitive case against MS for this move.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

imgx64 — Sat, 14 Jan 2012 07:06:30 +0000

> And the future is a boot stamping over and over on a human face.

Pun not intended?

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

Fowl — Sat, 14 Jan 2012 05:13:47 +0000

That headline could very easily be confused for one that says that UEFI has something to do with ARM.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

jmorris42 — Fri, 13 Jan 2012 23:41:40 +0000

> If it's even legal.

That doesn't matter now does it? How many times did the DoJ go after them? They even 'won' a few against them. None of it mattered. To this day they still charge the per PC license fees and pretty much every practice they pinkie swore to stop doing. And the Europeans haven't had any better luck.

This IS the Xboxing of the PC. Sure they allow the x86 to continue as is for now. Because they see it as a dead end. Besides, if they changed the way the desktop PC works it might anger enough people to get a legal response. Better to just make sure streaming video only plays if you haven't 'rooted' your PC, just like on tablets and phones now with Android. Then the Microsoft App Store won't work on 'rooted' PCs come Windows 9. And ever so slowly the chains slide on. And the future is a boot stamping over and over on a human face.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

drag — Fri, 13 Jan 2012 23:30:45 +0000

> What's a real shame is that the average smartphone consumer will be hurt most if this goes through, but that they're unaware of the issue and the implications. The irony is that they have the power to vote with their wallets, but won't know that they need to.

I kinda doubt that. If the average consumer was interested in using something other then a Windows OS they wouldn't be purchasing Windows phones, would they?

I know I am suppose to be all upset and bothered buy this, but I can't for the life figure out why shipping a locked down Windows is any worse then shipping a locked down Android phone, Kindle, or a iPhone or a iPod.

The whole thing strikes me a kinda silly. I read the article and their analysis and I was thinking to myself 'Sooo.. exactly why this is so tragic?'. I mean it's generally bad that these devices are locked down, but I fail to see what Microsoft is doing is any worse then what anybody else is doing.

At least they are only interested in locked down their already closed source software. It's not like Apple or many Android vendors that lock down open source using software written by other groups.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

mpr22 — Fri, 13 Jan 2012 22:21:24 +0000

The division responsible for Excel certainly had a reputation for being sharper than most of Microsoft.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

elanthis — Fri, 13 Jan 2012 21:38:40 +0000

The Xbox keys never got hacked or stolen. Unlike with SecureBoot, the xbox signing keys need to be applied to thousands of binaries from third parties; the SecureBoot keys need only be exposed to a handful of Windows 8 bootloader builds. Microsoft knows how to manage the bank-vault security of their signing keys and processes (well, the Xbox division does, at least; Microsoft is a very, very big company, so it's quite feasible for one division to be highly competent while another is hopelessly idiotic, I suppose).

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

bricef — Fri, 13 Jan 2012 18:26:21 +0000

I wasn't thinking of a digital attack actually. I expect that those kind of keys are behind an airgap, and that microsoft will have learnt a lesson form stuxnet and the virus hitting the us drone control centers. I was thinking of a disgruntled employee or actual physpen.

Regardless, I just think it's really silly to paint such a big target on your own back. Besides the fact that what they're doing hurts everyone, it's conspicuous and, frankly, given the spotlight already directed at UEFI, moronic. (If it's even legal.) and will attract the exact kind of attention that you really don't want.

What's a real shame is that the average smartphone consumer will be hurt most if this goes through, but that they're unaware of the issue and the implications. The irony is that they have the power to vote with their wallets, but won't know that they need to.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

raven667 — Fri, 13 Jan 2012 17:21:01 +0000

Protecting the keys in a situation like this is stupidly easy because your need to interface with the private keys is so limited. IIUC all they need to do is be able to sign the signature of the kernel when the kernel is updated, that can be done entirely offline by manual data entry from printouts. It'll be a bit of an inconvenience but should have a reasonable turnaround time for updates and be protected from attack up to and including a stuxnet type worm.

SFLC: Microsoft confirms UEFI fears, locks down ARM devices

aliguori — Fri, 13 Jan 2012 16:48:07 +0000

> My educated guess is that it's part of lowering costs for themselves and reducing the need for hardware vendors to access their source code.

More likely, they're paying a subsidy to companies that build these devices in order to get them to use Windows 8, perhaps to the extent that they're taking a loss. The end consumer product might be cheaper than the hardware cost.

Sometime tells me, the specs for Windows 8 device are going to need to be higher than for Android. If they want to be cost competitive, they'll have to subsidize.