This post is made in a personal capacity. While it represents the outcome of multiple discussions on the topic with a variety of people, nothing written below should be construed as Red Hat's corporate position
The FSF have
released a statement on UEFI secure boot. It explains the fundamental issue here, which isn't something as simple as "will OEMs let me install Linux". It's "Does the end user have the ability to manage their own keys".
Secure boot is a valuable feature. It does neatly deal with the growing threat of pre-OS malware. There is an incentive for it to be supported under Linux. I discussed the technical aspects of implementing support for it
here - it's not a huge deal of work, and it is being worked on. So let's not worry about that side of things. The problem is with the keys.
Secure boot is implemented in a straightforward way. Each section of a PE-COFF file is added together and a hash taken[1]. This hash is signed with the private half of a signing key and embedded into the binary. When you attempt to execute a file under UEFI, the firmware attempts to decrypt the embedded hash. This requires that the firmware have a either a copy of the public half of the signing key in its key database, or for there to be a chain of trust from the signing key to a key in its key database. Once it has the decrypted hash, it generates its own hash of the binary and compares them. If they match, the binary is executed.
What happens if it doesn't match? Per the UEFI specification, the firmware can then prompt the user and ask if they want to execute it anyway. If the user accepts then the hash of the binary is remembered[4] and can continue to be executed in future. This is similar to what you get when you visit a self-signed https site, or when you connect to an ssh server for the first time - the user must explicitly state that they trust the software that is being booted.
This is a little awkward for a couple of reasons. First, it means that any updates to the bootloader would require the user to manually accept the binary again. Second, as we've seen with https, there's the risk of uesrs just blindly accepting things. If it's acceptable to do this off internal media[5] then malware could just rely on some number of users saying "yes". And thirdly, we've been told that Microsoft's Windows logo requirements forbid this option.
The first is problematic but manageable with appropriate documentation. The second is a real risk that makes this approach far less compelling. And the third is probably a showstopper.
So signed but untrusted binaries are probably out, on technological, UI and policy grounds. What else?
We can sign binaries with a trusted key. This gets us interoperability, but comes at a cost. The first issue here is that we still don't know what the process for getting a trusted key is going to be. One option is for something like a generic Linux key that's provided by all firmware vendors. As long as the OEM doesn't remove it, then that Linux key could be used to sign other keys that are used by individual Linux vendors. The main difficulty involved in this is having the Linux key be managed by an authority that OEMs can trust to only provide keys to trustworthy organisations and maintain control of the private half of the key. Remember, if any malware is signed with any of these keys, it'll boot on any machine carrying this key. It's a lot of trust. It's not obvious that there's an organisation with sufficient trust at the moment.
The second approach is for each Linux vendor to generate their own key and get every OEM to carry it. Let's rule this out on the basis that it's an approach that doesn't scale at all. Red Hat could probably get its key into a bunch of OEM systems. Canonical too. Oracle? Probably for the vendors they care about. It's likely to be much harder for everyone else, and you still end up with the risk that you've just bought a computer that'll boot Red Hat but not Ubuntu.
The third approach is for each Linux vendor to obtain a key from someone who's already trusted. The most obvious authority here is Microsoft. Ignoring the PR unpleasantness involved with Linux vendors having to do business with Microsoft to get signed, so far Microsoft haven't given us any indication that this will be possible.
So every approach that involves us signing with a trusted key comes with associated problems. There's also a common problem with all of them - you only get to play if you have your own trusted key. Corporate Linux vendors can probably find a way to manage this. Everyone else (volunteer or hobbyist vendors, end users who want to run their own OS, anyone who wants to use a modified bootloader or kernel) is shut out.
The obvious workaround is for them to just turn off secure boot. Ignoring the arguments over whether or not OEMs will provide that option[6], it benefits nobody for Linux installation to require disabling a legitimate security feature. It's also not likely to be in a standard location on all systems and may have different naming. It's a support nightmare. Let's focus on trying to find a solution that provides the security and doesn't have obvious scaling issues.
There's a pretty simple one. If the problem centres around installing signing keys, why not have a standardised way of installing signing keys?
What we've proposed for this is an extension of the current UEFI standard for booting off removable media. There's a standardised location for putting the bootloader for USB sticks or optical media. For 32-bit PCs, it's EFI/BOOT/BOOTIA32.EFI. For 64-bit, it's EFI/BOOT/BOOTX64.EFI. Our proposal is to specify a path for key storage on the media. If the user attempts to boot off an item of removable media and finds a key file, we would like the firmware to prompt the user to install the key. Once the key is installed, the firmware will attempt to boot the bootloader on the removable media.
How does this avoid the problems associated with prompting the user to boot untrusted binaries? The first is that there's no problem with updates. Because a key has been imported, as long as future bootloader updates are signed with the same key, they'll boot without prompting the user. The second is that it can be limited to removable media. If malware infects the system and installs itself onto the hard drive, the firmware won't prompt for key installation. It'll just refuse to boot and fall back on whatever recovery procedures the OEM has implemented. The only way it could get on the system would involve the user explicitly booting off removable media, which would be a significant hurdle. If you're at that stage then you can also convince the user to disable secure boot entirely.
This proposal has been brought up with the UEFI standards working group, and with the UEFI plugfest taking place next week we're hoping it'll be discussed. It seems to satisfy the dual requirements of maintaining system security and ensuring that users have the flexibility to choose what they run on their system. But as with all technical proposals, feedback is entirely welcome.
[1] Hilariously, Microsoft's signing tool gets this wrong by also adding the contents of gaps between sections in direct contravention of their own specification. This is fine for binaries generated by Microsoft's toolchain because they don't have any gaps, but since our binaries
do contain gaps[2] and since the standard firmware implementation[3]
does implement the specification correctly, any Linux-generated binaries signed with the Microsoft tool fail validation. Go team.
[2] Something that is, as far as we can tell, permitted by the PE-COFF specification
[3] Written by Intel, not Microsoft
[4] Note that this means that only the specific binary is considered trusted. No key is imported, and any other binaries signed with the same key will also need to be manually trusted in the same way.
[5] As would be required if you ever want to be able to update your bootloader
[6] And to forestall panic, at this point we expect that most OEMs
will provide this option on most hardware, if only because customers will still want to boot Windows 7. We do know that some hardware will ship without it. It's not implausible that some OEMs will remove it in order to reduce their support burden. But for the foreseeable future, you'll be able to buy hardware that runs Linux.
comments
OpenXenManager cleared the NEW queue and is now available in the archive. What it is:
Rapha l Hertzog 
I'm indescribably happy to be able to say that I found Smudge alive and well
this morning.
I was getting ready to head out the door to work, and I opened the shutters
in the kitchen and saw that the trap that I had outside by the front door
was closed. The trap itself was wrapped in a sheet, so I couldn't
immediately see what I'd caught.
I quickly went outside, half-expecting to find a raccoon in there, and I was
pleasantly surprised to find Smudge in there!
I brought the trap inside and got Smudge out and raced her over to the food
and water, where she had a long drink of water and something to eat.
She's definitely lost some weight, but otherwise doesn't seem any worse for
wear. She's currently sitting in my lap as I write this, so I don't think
she's too traumatised by her ordeal. Lily was a bit standoffish this
morning, hissing and growling at her, but I suspect that's because she
didn't smell right. If she keeps that up, I'll put a drop of vanilla essence on
both of them so they smell the same.
Yesterday, I'd received a report of a possible sighting three streets over
(houses on one side of the street back onto the Hetch Hetchy trail, where
there were also reported sightings), so last night I placed the other trap
in the backyard of one of the houses where there'd been a sighting.
A couple of hours after that, I got another report of a possible sighting
from someone else on the same street, further down. So I was pretty keen to
substantiate all of these sightings on this particular street.
Unfortunately, after two trips up there, I didn't see any black cats, so
we'll never know if it was her or not.
The night before last, I'd upgraded the food in the traps to some sardines,
tuna and some fresh wet cat food, to try and lure her in. I have no idea if
that helped or not, or she just finally found her way home, but it was such
a relief to find her in the trap this morning.
It turns out I caught an opossum in the other trap. Those are the funniest
animals. They have a totally broken fight or flight reflex. This one would
not leave the trap when I opened it. I ended up having to upend the trap and
shake it out, and even then it just lay there playing dead - even when I
shoved a bowl of food in its mouth.
I've just done the rounds of the neighbourhood and taken down all the
posters I'd put up. It had been suggested that I might want to update the
posters and say that I'd found her, but I honestly don't want to do the
extra trip to then take them all down again after that.
A month ago I started a new job, at 
I am currently running a 
![[pic]](http://jmtd.net/log/./phm/image1.jpg)
A couple of times I have written code which basically does this:
The 
Good morning all!
It feels like forever since I last blogged . Which is extremely bad of me *slaps own wrist*. However, I m been horrendously stupidly busy. As some of you may know, I m very much an Android fan. Recently, I ve gotten myself a shiny Galaxy SII.
Given the fact that alongside my day job of being a Web Developer for an Online Retailer, I m also a 
here's my list of recent RC bug fixes, again comprising bugs which already
had a patch in the BTS:
