Shuttleworth on Ubuntu Linux, Fedora, and the UEFI problem | Hacker News Reader

Shuttleworth on Ubuntu Linux, Fedora, and the UEFI problem

zdnet.com

39 pointstanglesome52 comments

The fact is that user control will always be a "security risk" and that there will therefore be a reasonable case to be made that use control should be restricted. A strong response to this line of argument is the Free Software perspective, where user control of a computer is a matter of liberty, not security. Freedom can be messy, it can result in a rootkit, but it's something many people value.

Reminds me of Stallman advocating that all computer users should have root access.

I don't see why this is controversial, especially if you replace "users" with "owners".

There is never a reasonable case that the owner's control should be restricted. If the internet cafe wants to lock down all their machines, then go for it. If Sony wants me to pay >$500 for a locked down machine that only they control, they can go blank themselves.

I will never buy any hardware, with any vendor specific keys inside. If Ubuntu or Redhat enter any key at hardware i will never use that distros again. My computer is mine. It does not belongs to Microsoft or to Redhat or to Canonical or to anyone else. I'am even willing to pay more money to buy hardware that i really own, if i have no other option.

I run a project at my high school where students install linux on donated laptops, and use them for a variety of purposes. I read these articles and wonder if this project will come to a screeching halt.

Since our donated laptops are usually 3-5 years old, it seems the project will be able to continue for about that long without any UEFI-related problems. It seems we will start having problems when UEFI-based laptops are old enough to start being donated to us.

Is my understanding reasonable? It is pretty discouraging to think that this project will continue to evolve, only to hit a brick wall in the next 3-5 years.

You can disable secure boot, or if you can’t you’ll be able to install Fedora/RHEL, or sign your own OS (or Ubuntu) with Microsoft key (for a fee).

In 3-5 years time it'll have been solved I'd imagine, there's a lot of devs who'll invest time in over that period.

It's bad, but not quite as bad as that. The UEFI spec doesn't explicitly disallow making Secure Boot a toggle-able option, so some OEMs (like Dell: http://www.osnews.com/story/25293/Dell_HP_Respond_to_Secure_...) are planning to ship with it on but let you turn it off in the BIOS options if you want to. So someone technically knowledgeable could switch it off in your laptops before you hand them out to students.

Still two big "ifs" there, though:

1) You can turn it off if the OEM gives you the option to, and OEMs are under no obligation to do so; and

2) All of the above is only true for x86 machines; for ARM-based systems, Microsoft is requiring that no option be provided for the user to disable Secure Boot (see http://blogs.computerworlduk.com/open-enterprise/2012/01/is-...).

So the upshot is that if your hardware comes from a cooperative OEM, and if it runs on x86, the impact on you will be minimal -- just flipping a switch. But ARM systems and systems from uncooperative OEMs will be locked, so you won't be able to assume that any laptop that comes in over the transom will be useful to you anymore. (ARM laptops are uncommon today, but after Windows RT launches they may become more common.)

EDIT: Looks like since the last time I looked at this issue MS made it mandatory for OEMs to allow users to be able to turn off Secure Boot on x86, see comments below. So having to worry about which OEMs allow it and which don't isn't an issue. ARM systems still can't let users disable it, though.

>1) You can turn it off if the OEM gives you the option to, and OEMs are under no obligation to do so; and

Wrong.

>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.

Source:

Windows Hardware Certification requirements

http://msdn.microsoft.com/en-us/library/windows/hardware/jj1...

Well that's a relief!

My recollection was based on the last burst of news coverage on the issue late last year; it sounds like Linux vendors like Red Hat worked with Microsoft on the issue between now and then (Red Hat this month: "the Linux Foundation, hardware partners, and Microsoft to collaboratively develop a UEFI secure boot mechanism that allows user/customer choice and ease of use" -- http://www.redhat.com/about/news/archive/2012/6/uefi-secure-...), so it may be that the ambiguity was present in older MS certification specs but got cleared up later on...

Does this mean you'd just toggle a BIOS setting to disable secure booting?

s/BIOS/UEFI/

Yes, that is exactly what it means.

This seems like the job for an independent non-profit organization. We need a trusted third party to rubber-stamp software signing until particular packages are flagged for malicious or incompetent behavior. It shouldn't be Microsoft or Canonical.

I was thinking about this. It appears that software development is headed to become a regulated profession but the regulators will be the hardware manufacturers and platform providers.

There might be value in having a recognized "professional body" where membership can be revoked but having a rubber stamp issued by such an org allows the developers code to bypass a lot of the BS.

So "thou shalt not write malware" as opposed to "thou shalt not harm the interests of the platform vendor".

That's likely a glimpse of our future, since it's been tried so many times in the past, but I wish we could implement something a little more automated, decentralized and less prone to human failures than a single professional ruling body with permanent expulsion for "delinquents".

Maybe Github could offer a service to sign your software, free for open source, and pay for closed. They might run some kind of automated testing on your source for deviant behavior and to ensure quality, sign it, and revoke its keys if verified complaints are submitted. If the author is found to have malicious intent, then Github could ban him/revoke all his keys, and maybe a competitor could choose to sign his software instead, possibly one specializing in high-risk customers.

mjg59 touched that on his writeup:

>That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.

http://mjg59.dreamwidth.org/12368.html

I think the real solution is the ability for users to edit keys or disable it entirely. An independent non-profit organization still doesn't solve the problem of installing my operating system on my hardware. What if I disagree with policies of the non-profit. Until then, my solution will be to not buy such hardware at all.

Secure Boot on non-ARM Windows machines will be disableable. UEFI standard has provisions for users to install their own keys too, but I haven't heard if anyone plans to implement that feature. Major problem with UEFI signing scheme is that your computer will most likely be unusable without MS keys as the firmware drivers iirc are most likely signed with MS keys.

ARM Windows machines are required to not be disableable. Non-ARM Windows machines MAY be disablable - but that's up to the manufacturer. What I'm saying is that the real solution is to require the ability for users to easily edit the configuration. It's a bit like saying the real solution isn't to defeat SOPA, but to actually pass it's opposite into law.

Windows Hardware Requirements require Secure Boot to be disableable on non-ARM platforms.

What are the actual problems Microsoft is ostensibly trying to fix with a secured bootloader? Something related to viruses/hacks or something else entirely?

Undetectable root kits. Which is a pretty serious problem, admittedly. It's an open question whether or not secured boot is a good or effective way to go about solving it.

I'm not sure that you can call pre-kernel malware a "serious problem" yet. It exists, but is rare. Stuxnet and Flame seem to have the current crowns for "best malware" and did their deeds without it, after all.

It's also important to point out that the secure code chain is also held up (albeit often incorrectly) as an important criteria for a working DRM implementation. The content providers like that story, and like to hear about efforts to prevent rogue code from running. Certainly this has a lot to do with the Intel/Microsoft rush to secure boot.

It's a serious problem when it happens, but it's not at all widespread. Though there's a good argument to be made that we shouldn't wait for problems to become widespread before fixing them, especially when they are as potentially damaging as rootkits. Imagine if we'd spent the 70s and 80s taking buffer overflow issues very seriously, for example. We'd live in a much different and arguably better world.

The point still stands on whether or not this is actually the best or most effective way to go about tackling the problem. And as you point out the "unintended" of securing the DRM chain and of increasing vendor OS lock-in are not to be ignored and probably just as much a factor behind adoption as the purported security issues.

Do you mean publicly acknowledged problems? Viruses, especially boot viruses, BIOS viruses, and rootkits.

Or do you mean mustache-twirling evil conspiracy "plausibly deniable" motives? I'm sure it's easy to ascribe malice to Microsoft's actions here.

"Secure Boot is designed to address the potential for malware to insert itself between the firmware and the operating system on your computer. It accomplishes this by enforcing that only “approved” software is able to boot in your computer by way of a key that recognises pre-approved and signed software."

That's from the linked canonical article on the issue: http://blog.canonical.com/2011/10/28/white-paper-secure-boot...

Users installing their preferred OS, clearly.

I'm fairly flummoxed as to why this hasn't received antitrust review, frankly.

The notion of "Secure Boot" only loading a verified bootloader protects against Evil Maid [1] attacks and helps you start the chain of trust from the boot sequence, rather than from your bootloader (which you can't trust necessarily). http://www.schneier.com/blog/archives/2009/10/evil_maid_atta...

I also wonder at the utility of this for end user machines. On end user machines, the valuable and secret data is owned by the user, is volatile (not protectable at the OS level with current OS's which have no idea when/how user owned data should be changing), and furthermore is accessed and modified using processes owned by the user. Confused deputy process which are owned by the user seem much more likely to me to do real damage on a home machine.

Which is not to say that this technology is useless, boot-level attacks are important to defend against even if they aren't common now. But one has to wonder whether the costs are worth the benefit, on end user machines?

Botnets often cause little to no perceptible harm to the users of the zombies machines. I've heard of cases where the viruses actually attempted to improve the computers security to keep other viruses out and gain exclusive access to it. But still most agree that fighting botnets is important.

Note that I'm not saying that Secure Boot is significant in the battle against bots, but rather that security is important even if there is not immediate benefits to the users of that particular machine.

I don't think the concern is for the user's data at all. It's to prevent the computer from becoming an uncleanable botnet zombie.

For instance today if you install Fedora and select encryption for the drives, /boot is still not encrypted (what would decrypt /?). Your data is secure from offline analysis, but anybody can walk up and replace /boot to record your password (not to mention more complicated hacks) the next time you use it.

So verifying the bootloader with EUFI is a great thing that must happen. It could be completely transparent to most users -- their system works the same, it's just more secure. The problem is that Microsoft has engineered it so in practice only their key can be on the system to unlock it. Once this scheme gets established they might even be able to maintain a 'windows tax' just to unlock the hardware even if you don't even use their OS. That's really the only negative about EUFI.

Errr, if they let anyone else generate keys, it would defeat the whole purpose in the real world of many legit and illegit organizations and anti-trust laws that would make it impossible to draw reliable boundaries between the two (e.g. you have to tune the system for false negatives (false determinations that an org is illegit); see the recent SSL certificate mess).

I don't follow that argument. Say the EUFI boot used the last key you booted with... Windows PCs would boot just the same, securely using the Microsoft key.

But when you pressed Esc or F1 or whatever for a boot menu, instead of choosing what partition to boot from you choose which key. ie the list is

1) Microsoft, Inc. Operating System

2) Red Hat, Inc. Operating System

3) ...

So even if somebody hacked Red Hat and stole their key and signed something malicious, the user would still have to select that key on boot in order for it to run. Maybe the boot menu would only list keys that verified an actual installed OS.

In any case, just because you have a bunch of keys in the BIOS doesn't mean you have to automatically boot anything they sign.

I think there is a big presumption here that Microsoft will continue to dominate the tablet/mobile/ARM world like they historically have the desktop/laptop world. I don't see any reason to believe they will. They are grasping at straws here.

Frankly I can't wait for the rise of great UEFI Android tablets that lock out Windows OSes as "insecure". (Most Windows users won't know how to turn off secure boot. I hope Android doesn't actually permanently lock anything down.) Then watch Redmond accuse Google of anti-competitive behavior, going against the users wishes, and general mean-spirited-ness.

I can't see how Microsoft thinks that this can survive an antitrust case in Europe.

The situation with Secure Boot is bit like requiring admin rights to install Firefox. Neither is likely to trigger antitrust cases anywhere.

the only problem here is that in case of ARM devices, truly admin is only one - Microsoft. IMHO perfect antitrust case.

MS does not have significant enough marketshare in ARM devices to trigger antitrust case.

I wonder if someone isn't going to crack it after a few days and it will be the end of the story?

That's sufficiently unlikely that we shouldn't be relying on it: http://mjg59.dreamwidth.org/12897.html

The hypothetical crack would probably be less trivial for end users to use than it would be for them to go and disable Secure boot from firmware configuration.

If MicroSoft can implement a Secure Boot. Linux will implement it much better :)

The ease of implementing secure boot is proportional to the seriousness and closeness between motherboard manufacturers, OEMs and operating system companies. That is something MS has in abundance but linux organizations very much less so.

"Implementing" Secure Boot afaik basically means appending a signature to your bootloader. Not exactly rocket science, nor much room for improvement.

People can continue the sport of throwing Microsoft under the bus. But twenty years on, there isn't enough commercial demand for Linux laptops to create market meaningful enough that UEFI implementation will affect a laptop manufacturer's sales.

It's great that Linux is out there. I use Ubuntu for the virtual machine I use exclusively for Facebook. I use another copy for the virtual machine I use exclusively for Linkedin, and Xbuntu for the one by which I access Gmail.

The very fact I use Linux at all places me in a tiny slice of the computer culture - the fact that I am running Linux in a virtual machine is without a doubt not a particularly distinguishing feature.

I've been reading Hackers and Painters. And the problem with Linux is that it's proponents lack empathy (in Paul Graham's sense). Nobody is going to give their mother a Linux box - PG even talks about his mother's Mac needing an upgrade.

There aren't any Linux laptops at your local BestBuy today because regular people don't want them...and BestBuy's GeekSquad damn sure doesn't want to support them. It's not Microsoft. It's the market.

I am going to give my mother a laptop with Xubuntu installed on her birthday next week.

I gave my mom an Ubuntu running laptop, 5 years ago. And administered it remotely only all that time. Eventually there was a hardware failure so we'll just replace it and she'll be good to go as well.

Interestingly, this was her first real computer experience. While I could get to fix it, my cousin let her use a Windows 7 laptop. There were plenty of complaints from her about how unfriendly, unpredictable and annoying the interface was. It was kind of funny to hear that since usually you hear the reverse (ex-Windows users complain about Ubuntu GUI).

Most people like what they are used to; or at least, they associate learning a new method with discomfort. Hackers are neophiles, strange outliers who are willing to learn new things in order to get the control that they want.

You are correct in pointing out that absence of support and preinstalled Linux laptop and desktop is an impediment to Linux adoption.

However, after installing ubuntu on my Mom's computer last year, my support calls got cut in half. Now she doesn't have to fight with malware, viruses all the time. I think Linux as a desktop has matured enough that most people can use it for their everyday computing.

People could choose Linux for their everyday computing. But they don't for the same reasons they don't use Pine for their email and EMACS for business correspondence.

On the other hand, if they are forced to use it by their sys-admin, then of course they will.

Reply on news.ycombinator.com