Older blog entries for mjg59 (starting at number 370)

Don't like Secure Boot? Don't buy a Chromebook.

People are, unsurprisingly, upset that Microsoft have imposed UEFI Secure Boot on the x86 market. A situation in which one company gets to determine which software will boot on systems by default is obviously open to abuse. What's more surprising is that many of the people who are upset about this are completely fine with encouraging people to buy Chromebooks.

Out of the box, Chromebooks are even more locked down than Windows 8 machines. The Chromebook firmware validates the kernel, and the kernel verifies the filesystem. Want to run a version of Chrome you've built yourself? Denied. Thankfully, Google have provided a way around this - you can flip a physical switch hidden somewhere in the machine to disable the validation. Doing so deletes all your data in the process, in order to avoid the situation where a physically present attacker wants to steal your data or backdoor your system unnoticed, but after that it'll boot any OS you want. The downside is that you've lost the security that you previously had. If a remote attacker manages to replace your kernel with a backdoored one, the firmware will boot it anyway. Want the same level of security as the stock firmware? You can't. There's no way for you to install your own signing keys, and Google won't sign third party binaries. Chromebooks are either secure and running Google's software, or insecure and running your software.

Much like Chromebooks, Windows 8 certified systems are required to permit the user to disable Secure Boot. In contrast to Chromebooks, Windows 8 certified systems are required to permit the user to install their own keys. And, unlike Google, Microsoft will sign alternative operating systems. Windows 8 certified systems provide greater user freedom than Chromebooks.

Some people don't like Secure Boot because they don't trust Microsoft. If you trust Google more, then a Chromebook is a reasonable choice. But some people don't like Secure Boot because they see it as an attack on user freedom, and those people should be willing to criticise Google's stance. Unlike Microsoft, Chromebooks force the user to choose between security and freedom. Nobody should be forced to make that choice.

comment count unavailable comments

Syndicated 2013-02-04 16:58:42 from Matthew Garrett

The current state of UEFI and Linux

Executive summary: Most things work fine.

Things we know are broken:

  • Some Samsung laptops. The samsung-laptop driver is a slightly weird thing. By 2010 (when it first appeared) most vendors had moved over to using some level of firmware abstraction, either using ACPI or WMI. Samsung still seemed to be stuck around a decade earlier - they were providing a region of memory at a known address, and you'd read that address to find a bunch of offsets. Then you'd write magic values based on those offsets to magic system IO ports based on those offsets and something would happen. Those writes were triggering System Management Mode, a special x86 CPU mode where the processor executes code from memory that the OS can't see, without telling the OS that it's doing so. There's nothing especially new in this (SMM first appeared in the 386sl back in 1990), but it also means that you depend on the system vendor not changing the interface without telling you. Turns out that Samsung apparently changed their platform interface when they moved to UEFI, but didn't actually do anything to prevent old drivers from breaking things - performing exactly the same series of accesses on some modern Samsung laptops gives an uncorrectable machine check exception (in the best case) or destroys your firmware (in the worst case). Given that the driver was written to Samsung's specifications, this is pretty obviously Samsung's fault, but that's probably little consolation to anyone who ended up with a dead laptop. Although, given Samsung's track record, this may not be surprising.

    On the bright side, some of the machines that are affected by this predate Secure Boot, so at least it's not a Secure Boot bug.
  • Some Toshibas won't boot Linux. This turns out to be some staggering incompetence on the part of Toshiba (or, more likely, their third-party vendor) - they managed to leave the signing key out of the database that's used to validate binaries, and managed to leave the signature database signing key out of the database that's used to provide whitelist or blacklist updates. The good news is that this is a blatant violation of Microsoft's Windows 8 certification guidelines, and that seems to have encouraged Toshiba to actually fix their BIOS. The bad news is that any of the affected machines that are currently available are still broken, and Toshiba don't seem to be willing to actually give you the firmware update yet.
  • Some Lenovos will only boot Windows or Red Hat Enterprise Linux. I recommend drinking, because as far as I know they haven't actually got around to doing anything useful about this yet.

Not an amazingly positive list, but as far as I know that's about it - other than some Samsungs, one range of Toshibas and one range of Lenovo desktops, Linux should be fine. If you have any other UEFI system that's unable to install Fedora 18, let me know and we'll do our best to work out what's going on.

comment count unavailable comments

Syndicated 2013-02-01 05:48:37 from Matthew Garrett

ITWire still has problems with basic accuracy

ITWire ran a story on the 12th of January entitled "Fedora still has problems with secure boot". It ends up discussing two issues with the author's experience with the Fedora installer - that he can't reclaim any free space on existing drives, and that the installer didn't automatically add entries for Windows to the grub menu. These are certainly legitimate issues, and I don't want to suggest that it's reasonable for people to have to manually alter their configuration in order to support dual boot. But they're not issues with Fedora's support for secure boot, despite the enthusiasm with which certain people have jumped on the story. We've received one credible report of a secure boot related problem with Fedora on a couple of Toshiba laptops, which appears (and I want to stress that we're still working on diagnosing it) to be a firmware bug rather than any kind of problem with Fedora.

Mistakes happen in journalism, and sometimes there are differences of opinion. But this story is simply wrong. When asked about it in the comments, the author failed to support his position. When contacted, the editor in chief was willing to add a note saying that I disputed the arguments but was unwilling to remove the incorrect claims. As a result, the internet remains full of links and reposts of an article that unashamedly tells users that the current Linux distribution with the best UEFI hardware support has issues with something it has no issues with.

For reasons that are unclear to me, ITWire seems to have some sort of well regarded status in the Australian technical industry. It seems entirely undeserved.

comment count unavailable comments

Syndicated 2013-01-22 21:29:24 from Matthew Garrett

Upcoming conferences

Unfortunately I'm not going to make it to LCA this year, but there's still plenty of UEFI coverage - Dong Wei, Vice President of the UEFI forum, will be giving an introduction to UEFI, and James Bottomley, who's been working on the Linux Foundation's UEFI bootloader solution, will be talking about Secure Boot.

For those of you on this side of the Pacific (or who just can't get enough of listening to my melodious voice), I'll be keynoting the South California Linux Expo next month. This will be a discussion of the more social aspects of our work on Secure Boot over the past year and a half - an epic tail of astonishment, terror, politics, confusion and hard won victories, and the remaining issues that are yet unsolved. Clearly not to be missed. If California's too far for you, then come March I'll be at the North East Linux Fest. I'll be talking about how to make sure that your Linux distribution works with Secure Boot, and, assuming I've got the code finished by then, a little about how to break it.

comment count unavailable comments

Syndicated 2013-01-20 04:02:24 from Matthew Garrett

Experiences with depression

I've been lucky in life. I've known several people who've killed themselves, but I've been friendly with them rather than friends with them. Their deaths have saddened me, but haven't left giant gaping holes that I have trouble imagining filling. I've also been lucky in that I'm not especially predisposed towards depression, and even luckier that the one serious episode I had ended well. That luck means I'm not qualified to speak authoritatively on the topic, but this seems like a good time to share.

Most of 2002 wasn't great for me. Many of my friends had graduated and moved away. My PhD, which was what I'd spent the past few years of my life working towards, was going horribly wrong. The girl I liked didn't like me. Lots of individual small things that didn't fundamentally matter, but which build up into overall feelings of isolation and failure at life. I was spending an increasing number of days not leaving bed and not talking to people. It wasn't that I couldn't have fun - socialising was still pleasurable, and I didn't actively avoid people, but it was always tempered with the knowledge that this was temporary and I'd be returning to the unhappiness afterwards. I couldn't see any sequence of events that would turn my life around and restore my happiness. This was how life was, and this was how life was going to be. I'd irrevocably fucked up, and this was my future.

Looking back, what strikes me is how reasonable this seemed. I could point at specific things that were making me unhappy, and nobody could argue that it was unreasonable to be unhappy about them. There wasn't any point in speaking to people about it, because what would they be able to do except agree that I was justifiably unhappy? I thought about suicide. Not seriously, because overall life still seemed worthwhile, but I could conceive of a level of further unhappiness that would make it seem like the best choice. I don't think it would ever have occured to me to speak to someone about it first. It seemed like it would be the same argument - I'm justifiably unhappy, I already feel like I'm letting my friends down, what could they do other than tell me that my feelings are wrong or make me feel even more guilty? So, when I saw exhortions for people to speak to someone if they felt suicidal, it seemed like they were talking to people who hadn't thought this through as well as me. It felt like I'd thought this all through carefully and rationally and come to a completely logical decision. If changes in circumstances and further consideration made it seem like suicide was the better choice, that would be because it was the better choice. Maybe other people weren't thinking about this as logically as I was. Maybe they'd have their minds changed by speaking to a friend or a professional. I wouldn't. Of course, with hindsight I was rationalising the way I already felt rather than making entirely rational decisions. I could have rationalised myself to death even though there were (in my case) straightforward ways to make my life better.

In any case, I've no idea how close I ever got to that point. Things were at their worst in August - by September I had a new job and new house, and things just got better from there. In the end, the friends I was convinced could do nothing for me ended up giving me the opportunity to find gainful employment and made sure I had somewhere to live. Without them, things might have been different. As it was, I spent less than nine months depressed and it was still the most hellish experience of my life. The thought of returning to that state is terrifying. I was lucky. I might not be again.

There's no terribly good moral here. If I'd known more about depression beforehand, I might have been able to identify what was happening to me and seek professional help. Other than that, I didn't learn anything about how to avoid or deal with depression. The experience didn't make me a better person. I've no advice for people in the same situation. The only thing I gained from it all was the realisation that if I'd felt any worse and knew that this was what I faced for the rest of my life, death might not have been the worst choice I had.

Depression is a huge social problem and we deal with it badly. We refuse to talk about it, and when we do talk about it we mostly limit ourselves to platitudes about how things will get better or placing the blame on depressed people for not wanting to talk to those around them. Sometimes it doesn't get better. Sometimes talking to those around you will make things worse. People need to be aware of what the effects of depression are and get better at identifying it in others, rather than assuming that they'll be able to ask for help themselves. Society as a whole needs to be better at ensuring that professional support is there for people who need it. And, unless we can make massive improvements in our understanding of the causes of depression and effective mechanisms for countering it, we need to accept that it will cost us friends. Let's redirect the anger we feel at their choice to avoid a lifetime of misery into anger at the society that still hasn't done everything it can to help them.

comment count unavailable comments

Syndicated 2013-01-17 15:45:50 from Matthew Garrett

No, Linux won't be easy to run on a Microsoft Surface

The Microsoft Surface is a fairly attractive bit of tablet hardware, and as a result people have shown interest in running Linux on it. The immediate problem is that (like many ARM devices) it has a locked-down firmware that will only run signed binaries - unlike many other ARM devices, this is implemented using an existing standard (UEFI Secure Boot). Microsoft provide a signing service for UEFI binaries, so it's tempting to think that getting around this restriction would be as simple as taking an existing Linux bootloader, signing it and then booting. Unfortunately Microsoft's signing service signs binaries using a different key (the "Microsoft Windows UEFI Driver Publisher" key) to the one used to sign Windows, and the Surface doesn't carry that key. Booting Linux on these devices would involve finding a flaw in the firmware and using that to run arbitrary code.

Could this also be a problem on x86? In theory - Microsoft don't require that vendors carry the driver publisher key, and so a system could be Windows 8 certified and still not carry it. It's unlikely to occur in practice, though, since any third party expansion hardware will then fail on that device. As a result, anything with PCIe or Expresscard slots is effectively certain to have this key. If anyone finds any counterexamples, please let me know.

comment count unavailable comments

Syndicated 2012-12-29 18:39:43 from Matthew Garrett

Booting signed versions of Linux on Windows 8 machines

Some people have complained that they can't install Linux on new machines because their firmware won't let them choose a boot device. This is part of Windows 8's fast boot support - the keyboard may not be initialised until after the OS has started. To deal with this, insert the install media and reboot your computer. Wait for Windows 8 to start. While holding down shift, click on the power icon and click on restart. When the menu appears, click "Use a device" and then click your install media. If it's listed more than once, choose the one that says "UEFI" in front of it. Your system will now restart and boot off the install media.

comment count unavailable comments

Syndicated 2012-12-28 00:54:35 from Matthew Garrett

Secure Boot distribution support

It's after Christmas, and some number of people doubtless ended up with Windows 8 PCs and may want to install Linux on them. If you'd like to do that without fiddling with firmware settings, here are your options.

  • Ubuntu 12.10
    The 64-bit version of Ubuntu 12.10 ships with an older version of Shim that's been signed by Microsoft. It should boot out of the box on most systems, but it doesn't have some of the most recent EFI patches that improve compatibility on some machines. Grab it here.
  • Fedora 18
    Fedora 18 isn't quite released yet, but the latest 64-bit test builds include a Microsoft signed copy of the current version of Shim, including the MOK functionality described here. Fedora 18 has some additional EFI support patches that have just been merged into mainline, which should improve compatibility on some machines - especially ones with Radeon graphics. It also has improved support for booting on Macs. You can get it here, but do bear in mind that it's a test release.
  • Sabayon
    According to the wiki, Sabayon now supports UEFI Secure Boot out of the box. I don't know if the current CD images do, though. My understanding is that it's based on the Microsoft signed Shim I discussed here, and you'll have to manually install the key once you've booted the install media. Straightforward enough.
  • Other distributions
    Suse will be using a version of Shim signed by Microsoft, but I don't think it's in any pre-release versions yet. Debian have just merged UEFI support into their installer, but don't have any UEFI Secure Boot support at the moment. I'm not sure what other distributions are planning on doing, but let me know and I'll update the list.
  • The Linux Foundation loader
    The Linux Foundation have still to obtain a signed copy of their bootloader. There's no especially compelling reason to use it - the use case it supports is where you have users who can follow instructions sufficiently to press "y" but not to choose to enrol a key. The most interesting feature it has is the ability to use the MOK database via the usual UEFI LoadImage and StartImage calls, which means bootloaders like gummiboot work. Unfortunately it implements this by hooking into low-level functionality that's not actually required to be present, so relying on this may be somewhat dubious.


comment count unavailable comments

Syndicated 2012-12-28 00:52:48 from Matthew Garrett

Secure Boot bootloader for distributions available now

I'm pleased to say that a usable version of shim is now available for download. As I discussed here, this is intended for distributions that want to support secure boot but don't want to deal with Microsoft. To use it, rename shim.efi to bootx64.efi and put it in /EFI/BOOT on your UEFI install media. Drop MokManager.efi in there as well. Finally, make sure your bootloader binary is called grubx64.efi and put it in the same directory.

Now generate a certificate and put the public half as a binary DER file somewhere on your install media. On boot, the end-user will be prompted with a 10-second countdown and a menu. Choose "Enroll key from disk" and then browse the filesystem to select the key and follow the enrolment prompts. Any bootloader signed with that key will then be trusted by shim, so you probably want to make sure that your grubx64.efi image is signed with it.

If you want, you're then free to impose any level of additional signing restrictions - it's entirely possible to use this signing as the basis of a complete chain of trust, including kernel lockdowns and signed module loading. However, since the end-user has explicitly indicated that they trust your code, you're under no obligation to do so. You should make it clear to your users what level of trust they'll be able to place in their system after installing your key, if only to allow them to make an informed decision about whether they want to or not.

This binary does not contain any built-in distribution certificates. It does contain a certificate that was generated at build time and used to sign MokManager - you'll need to accept my assurance that the private key was deleted immediately after the build was completed. Other than that, it will only trust any keys that are either present in the system db or installed by the end user.

A couple of final notes: As of 17:00 EST today, I am officially (rather than merely effectively) no longer employed by Red Hat, and this binary is being provided by me rather than them, so don't ask them questions about it. Special thanks to everyone at Suse who came up with the MOK concept and did most of the implementation work - without them, this would have been impossible. Thanks also to Peter Jones for his work on debugging and writing a signing tool, and everyone else at Red Hat who contributed valuable review feedback.

comment count unavailable comments

Syndicated 2012-12-01 01:43:10 from Matthew Garrett

More in the series of bizarre UEFI bugs

A (well, now former) coworker let me know about a problem he was having with a Lenovo Thinkcentre M92p. It booted Fedora UEFI install media fine, but after an apparently successful installation refused to boot. UEFI installs on Windows worked perfectly. Secure Boot was quickly ruled out, but this could still have been a number of things. The most interesting observation was that the Fedora boot option didn't appear in the firmware boot menu at all, but Windows did. We spent a little while comparing the variable contents, gradually ruling out potential issues - Linux was writing an entry that had an extra 6 bytes in a structure, for instance[1], and a sufficiently paranoid firmware implementation may have been tripping up on that. Fixing that didn't help, though. Finally we tried just taking the Windows entry and changing the descriptive string. And it broke.

Every UEFI boot entry has a descriptive string. This is used by the firmware when it's presenting a menu to users - instead of "Hard drive 0" and "USB drive 3", the firmware can list "Windows Boot Manager" and "Fedora Linux". There's no reason at all for the firmware to be parsing these strings. But the evidence seemed pretty strong - given two identical boot entries, one saying "Windows Boot Manager" and one not, only the first would work. At this point I downloaded a copy of the firmware and started poking at it. Turns out that yes, actually, there is a function that compares the descriptive string against "Windows Boot Manager" and appears to return an error if it doesn't match. What's stranger is that it also checks for "Red Hat Enterprise Linux" and lets that one work as well.

This is, obviously, bizarre. A vendor appears to have actually written additional code to check whether an OS claims to be Windows before it'll let it boot. Someone then presumably tested booting RHEL on it and discovered that it didn't work. Rather than take out that check, they then addded another check to let RHEL boot as well. We haven't yet verified whether this is an absolute string match or whether a prefix of "Red Hat Enterprise Linux" is sufficient, and further examination of the code may reveal further workarounds. For now, if you want to run Fedora[2] on these systems you're probably best off changing the firmware to perform a legacy boot.

[1] src/include/efi.h: uint8_t padding[6]; /* Emperically needed */, says the efibootmgr source code. Unhelpful.
[2] Or Ubuntu, or Suse, or…

comment count unavailable comments

Syndicated 2012-11-15 05:12:22 from Matthew Garrett

361 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!