LWN: Comments on "The FSF's advice to distributors on UEFI secure boot"

'You have to divulge your private key' meme

JanC_ — Fri, 13 Jul 2012 19:34:09 +0000

You can install grub (and several other bootloaders) from inside Windows.

I suspect that doing so on a system that doesn't allow disabling UEFI SecureBoot would then result in an unbootable system though... ;)

Duplicating EFI functionality is a waste of time

raven667 — Tue, 10 Jul 2012 04:21:54 +0000

The whole thing seems like a missed opportunity then as we are going to be stuck with EFI for at least the next 20 years.

Duplicating EFI functionality is a waste of time

mjg59 — Tue, 10 Jul 2012 03:12:30 +0000

Given that even Microsoft use a full-featured EFI bootloader I have no faith whatsoever in our ability to get every vendor to adopt a common level of UI competence.

'You have to divulge your private key' meme

raven667 — Tue, 10 Jul 2012 03:12:26 +0000

They don't own the copyright for everything (or even a majority) of the software they ship so they aren't in a position to OK any lockdown with any vendors.

Duplicating EFI functionality is a waste of time

raven667 — Tue, 10 Jul 2012 03:09:11 +0000

It seems that EFI has most of the features of GRUB and 90% of what is truly needed to direct boot a Linux kernel. Changing the Linux kernel and boot process to make it better integrate with EFI and changing the reference implementation of EFI when necessary sounds like a reasonable idea. Working on some conventions with the vendors to make the UI decent also seems like it would pay off in time. Maybe this would only work if you had a close relationship with some preferred vendors to ensure an Apple level of user experience.

Duplicating EFI functionality is a waste of time

mjg59 — Sun, 08 Jul 2012 02:00:54 +0000

"Network boot is done by EFI. No need to duplicate the code in another program."

The firmware retrieves efilinux. How does efilinux download the kernel?

"Booting off FAT is a EFI requirement. Just put your boot kernel there on the boot partition and it works."

And now your /boot is FAT and you can't make symlinks in it, resulting in various existing tools now being broken.

"System lockdown is done in EFI with password, default boot option and 0 timeout or a startup.nsh script."

All well and good until you want to modify a kernel parameter and now have to wade through a configuration menu that differs between hardware vendors.

"Other operating systems are supported by EFI unless it is a BIOS only operating system then a BIOS emulation layer is required to boot first, like Apple Bootcamp does for Windows XP."

efilinux doesn't support chaining to other operating systems, so if your shim loader boots it first then you're stuck only booting Linux. Except for:

"You would not want another UI in a EFI bootloader because the EFI is supposed to have all of the UI already."

Have you actually used an EFI system? The UI is completely inconsistent between vendors, is often slow and awkward and may not let you edit command line options. Having half your technical documentation say "Refer to your system vendor documentation in order to determine if and how you can edit kernel options" is dreadful. Doing this in the bootloader means that you can guarantee consistency.

Duplicating EFI functionality is a waste of time

zlynx — Sun, 08 Jul 2012 01:51:56 +0000

Network boot is done by EFI. No need to duplicate the code in another program.

Booting off FAT is a EFI requirement. Just put your boot kernel there on the boot partition and it works.

System lockdown is done in EFI with password, default boot option and 0 timeout or a startup.nsh script.

Other operating systems are supported by EFI unless it is a BIOS only operating system then a BIOS emulation layer is required to boot first, like Apple Bootcamp does for Windows XP.

You would not want another UI in a EFI bootloader because the EFI is supposed to have all of the UI already.

Summary: We do not need to duplicate everything EFI already does in a EFI boot loader.

'You have to divulge your private key' meme

zlynx — Sun, 08 Jul 2012 01:40:08 +0000

I've read about a trick to fix the USB keyboard problem although I have never tried it myself. I wanted to, but couldn't find the right sort of device.

Anyway the trick was the find a USB device that takes a while to process so as to keep the USB initialization BIOS busy long enough to press the keyboard keys. Or a buggy device that locks it up until removed. Then you can press the BIOS entry key and remove the device to continue.

The FSF's advice to distributors on UEFI secure boot

jspaleta — Fri, 06 Jul 2012 23:57:03 +0000

so it looks like Shuttleworth has given a press interview on this matter.
http://www.theregister.co.uk/2012/07/06/shuttleworth_resp...

I would be very keen on seeing the SFLC make a public statement which goes into more public detail as to the forcible disclosure scenario. It seems the Shuttleworth quote about the private advice given from the SFLC is in conflict with the public statement from the FSF. So I'm a little confused.

I'd like to see a public whitepaper from the SFLC that goes through the reasoning.

-jef

'You have to divulge your private key' meme

davidescott — Fri, 06 Jul 2012 17:59:39 +0000

I certainly understand and agree from the perspective of what we would like. I would like a system that allows me to trust the keys of people I trust (like one mjg59) and secure my systems to only boot things he signs -- but from a practical matter:

Yes, I think it is reasonable that Canonical would want to allow its distributors to make a product based on open source software that is in fact more restricted than what one would get by purchasing an MSFT product.

If a distributor told Canonical "we will use Ubuntu only if we get to completely lock it down," I would understand that Canonical would say we discourage that, but won't stop you. I don't like those kinds of products, and I wouldn't buy such a product, and would discourage others from buying it, but I don't think Canonical should say no and don't think worse of them for saying yes. Their bug #1 is that Linux is not the most used operating system on the desktop, anything to get desktop linux (ie gnome/kde instead of android) into the hands of end users is in the interest of closing their bug #1.

In many ways this is just the Android debate all over again, but on the desktop. I'm not thrilled with Android, but I don't think its been bad for software freedom in general, as its a heck of a lot better than the iOS everything road we were down. Maybe I'll eat those words in 10 years, but at the moment that is how I feel.

'You have to divulge your private key' meme

mjg59 — Fri, 06 Jul 2012 17:49:10 +0000

efilinux has a tiny proportion of the functionality of grub, and much of that is functionality that we want. Where's efilinux's PXE support? Where's its ability to boot off anything other than a FAT partition? Support for locking down configuration for unattended systems? Its support for managing any kind of runtime configuration at all? The ability for the user to choose which kernel to boot? The ability to boot another operating system? efilinux is great at doing what it does, which right now is booting a single Linux kernel and initrd off a FAT partition with no kind of UI.

'You have to divulge your private key' meme

mjg59 — Fri, 06 Jul 2012 17:42:20 +0000

So ensuring that you haven't removed the "Disable secure boot" option from your firmware is a reasonable requirement for OEMs that want to ship Windows, but not a reasonable requirement for OEMs that want to ship Ubuntu?

'You have to divulge your private key' meme

davidescott — Fri, 06 Jul 2012 17:35:06 +0000

The whole thing seems unnecessary to me once efilinux is taken into account. I'm curious what your (Garrett's) opinion is of that. Why do we need all the machinery of grub these days? Is it just that efi doesn't/can't provide the necessary boot menu to allow us to select kernel version and boot parameters?

You've evidently decided that grub-efi is the way to go, but I missed whatever post explains what that gives us over using efi directly.

Thanks [and double thanks for fighting through this hardware nonsense all the time]

'You have to divulge your private key' meme

davidescott — Fri, 06 Jul 2012 17:28:21 +0000

Also there probably aren't any legal requirements to follow (a) unless they want to sell a Dual Boot OEM/Windows sticker-ed system. Most probably want to meet (a) and would find it easy enough to do so, but some might choose to skip that step and could have trouble meeting (d). So (a) should probably be struck from the list.

'You have to divulge your private key' meme

mjg59 — Fri, 06 Jul 2012 17:23:35 +0000

In that case Canonical's position would make plenty of sense once Windows 9 ships. It seems kind of unnecessary now.

'You have to divulge your private key' meme

davidescott — Fri, 06 Jul 2012 17:17:04 +0000

At the moment... My personal prediction is that MSFT removes the unlocked bootloader requirement on x86 for Windows 9, and goes to the full ARM lockdown model for Windows 10. The only real question in my mind is if European governments will allow that, but in a couple years they will point to their (if successful) ARM products and say "x86 is only a small part of our business, and this will unify our products across the platforms, so its irrational to not let us do this."

Certainly Canonical could change their bootloader in a few years, but what they are doing seems reasonable right now if they have a long enough planning horizon.

'You have to divulge your private key' meme

mjg59 — Fri, 06 Jul 2012 17:02:20 +0000

(d) is required for (a).

'You have to divulge your private key' meme

davidescott — Fri, 06 Jul 2012 16:34:02 +0000

My point wasn't a legal one but an economic one. Every additional legal obligation that the manufacturer/distributor faces introduces a compliance cost. Even if Canonical could never be placed in a position where it would be forced to respond and release the key, it does not benefit Canonical to make the distributors life any harder. With Grub2 a licensed Canonical partner (and to presumably be able to use the trademarks and marketing materials associated with that) has to (at least):
a) Follow all the MSFT standards
b) Test and verify the selected hardware with Ubuntu
c) Have an open source compliant installed system
d) Have an open source compliant firmware implementation (that allows users to disable secure boot)

(d) may not seem like much, but I would speculate that Canonical could indemnify the distributor for (c) by saying "use *THIS* disk image, and throw our business card in the box, and we will take all the associated legal liability for open source compliance," but if they were to indemnify (d) then Canonical probably could be forced to give away their key. Since Canonical make that offer (and retain the functionality of secure boot/not have their keys disabled by MSFT) they would have to leave that liability with the distributor, and that the added liability might be enough that some distributors would rather just ignore this smaller market.

MSFT has the advantage of being in a position of market power and can force companies to accept their terms. Linux distributors don't have that power and have to negotiate, I suspect not having GPLv3 bootloaders helps Canonical's negotiating position, and the EFF didn't consider that in their statement. That was my original point (in far fewer words).

PS Interestingly, there are now reports that the SFLC gave Canonical a letter indicating that the keys would have to be turned over in some scenarios. We will probably never know, but I'd bet it has something to do with an indemnification clause in whatever agreements Canonical signs with its distributors. The EFF is obviously technically correct that there would be no way the violations of one party could force an unaffiliated 3rd party to give away signing keys, but I doubt "unaffiliated 3rd party" accurately describes the relationship between Canonical and its distributors. So I don't think this is FUDing.

'You have to divulge your private key' meme

etienne — Thu, 05 Jul 2012 09:02:51 +0000

> there are various malign reasons why companies might disable or intentionally obscure the ability to install different keys

You mean, like changing all the time which keyboard key you have to press to enter the BIOS menu, displaying which key it is for too short a time, removing the PS2 keyboard plug, and delaying the USB initialisation so that it is very difficult to find the right time to press the key on a USB keyboard before the black-listed OS is booted and then refused and then power off the machine?
Hopefully shops will sell for a very long time those PC with windows 7 and a cheap offer to upgrade to Windows 8.

'You have to divulge your private key' meme

mjg59 — Wed, 04 Jul 2012 17:43:47 +0000

If one OS signed with the Microsoft key is compromised then they're all compromised - you'd just use the compromised OS to attack any of the others. So if Ubuntu ship a bootloader that allows arbitrary code to be executed, it's not just 10 million Ubuntu machines that are affected. You'd have to ask a lawyer to get a good idea about whether it's anticompetitive, though.

'You have to divulge your private key' meme

raven667 — Wed, 04 Jul 2012 17:13:07 +0000

I know what you mean, if I notice that the same person keeps popping up with the same discredited arguments then I know they aren't legitimately having a discussion in good faith and I put them in the LWN kill file. Life is too short to talk to people who just want to argue.

'You have to divulge your private key' meme

Richard_J_Neill — Wed, 04 Jul 2012 17:05:35 +0000

>> Who gets to decide?

> Anyone with a key in KEK, so typically Microsoft and the system vendor.

Wouldn't that be monumentally anticompetitive? If (say) Ubuntu were to get a large installed base, and then somehow their private key became compromised, then for MS to revoke the key would prevent the existing (non-updated) Ubuntu installations from booting. If Ubuntu made it clear that they didn't want the revocation to occur (i.e. that they would prefer 10 million systems to keep booting, even without the negligible protection conferred by the key), isn't that grounds for a monumental lawsuit?

'You have to divulge your private key' meme

pboddie — Wed, 04 Jul 2012 13:10:24 +0000

Despite assertions of paranoia by those who either have a short memory or deliberately want us to ignore the history of the industry, there are various malign reasons why companies might disable or intentionally obscure the ability to install different keys, all to give the impression that things were done "by mistake" and to let everyone point the finger at everyone else, leaving the customer without redress as usual.

If only there were the equivalent of the ITC patent "witchfinder" courts that Apple and friends hold so dear, whose purpose rather than acting to uphold monopolies on behalf of multinationals would be to act in the public interest and ban products from companies who treat their legal obligations with contempt.

'You have to divulge your private key' meme

dgm — Wed, 04 Jul 2012 09:53:05 +0000

OK, maybe I have been a bit harsh. I apologize for that.

But it all sounds much like the modus operandi of certain patent expert guy that used to post here. Insisting over and over on the same baseless arguments, even after multiple rebuttals.

'You have to divulge your private key' meme

mjg59 — Wed, 04 Jul 2012 03:34:25 +0000

> Who gets to decide?

Anyone with a key in KEK, so typically Microsoft and the system vendor.

> most of the effort is going into following the letter but not the spirit of the process.

That's not what we're doing in Fedora. If we're going to implement this then we might as well make it useful.

'You have to divulge your private key' meme

Richard_J_Neill — Wed, 04 Jul 2012 02:21:10 +0000

> Keys can be revoked by OS updates at runtime.

Who gets to decide? I.e. if I were to "accidentally" leak my own private key, which authority has the right to revoke my signed binaries across other computers?

Key revocation normally works because the key owner decides to revoke it.
Otherwise, all sorts of problems could arise (for example, some nasty malware could try to revoke the MS key).

> What makes you think the planned Fedora approach compromises the designed
> security?

Well, I see how Fedora can try to make use of signed boot as a rather trivial featurelet - but I thought that in most cases, the Linux community would like secure boot to just go away, and therefore most of the effort is going into following the letter but not the spirit of the process.

'You have to divulge your private key' meme

mjg59 — Wed, 04 Jul 2012 00:59:52 +0000

Keys can be revoked by OS updates at runtime. You can obviously prevent those from taking place on your own machine, but presumably you still want to remain installable elsewhere.

What makes you think the planned Fedora approach compromises the designed security?

'You have to divulge your private key' meme

Richard_J_Neill — Tue, 03 Jul 2012 22:36:00 +0000

Why would that matter anyway?

If we take the position that secure boot is a totally pointless antifeature, and given that there doesn't seem to be any way to revoke keys (BIOSes don't have internet access), why shouldn't Canonical publish their private key?

Yes, it would blow a complete hole in the entire thing...but then so does Fedora (as does does Ubuntu's workaround of having a BSD-licensed, signed, and very minimal shim whose job is to keep the BIOS security happy, then chainload Grub and boot whatever the user asks it to).

'You have to divulge your private key' meme

jspaleta — Tue, 03 Jul 2012 21:33:03 +0000

With that Apple/Foxconn analogy you seem to be implying that Canonical is paying equipment vendors to install and load Ubuntu at their behest. Apple pays Foxconn and Apple keeps final say and control over configuration details.

I'm not sure there is any evidence of that actually happening in the case of Canonical. If anything, it seems the other way around. OEMs pay Canonical for engineering support to integrate Ubuntu..but ultimately OEMs have final say and control over what actually ships. Though if you have any evidence of Canonical paying OEMs to get Ubuntu into devices, I'd love to see it. I've heard rumors in the past but I could never pin down a credible statement on or off the record.

Devils in the details of the contractual agreement that we will never actually be able to read. So anything with regard to how the partnership agreement deals with licensing liability or provides for indemnification or hold harmless clauses with respect to one for-profit entity or the other. The partnership agreement can say pretty much anything to try to shield one entity from liability inherent in the actions of the other. There's no point in speculating about what one entity is contractually obligated to do for the other. Whatever the concern is, it would be best for everyone if the concern was discussed between the FSF the parties who have knowledge of the agreement.

Though I will say, if Canonical entered into a contractual agreement with another entity that allowed the other entity to hold Canonical up as a liability shield..that would be a real head scratcher. I've read over the Harmony contributor agreements in full and so far it seems Canonical goes to great lengths to make sure they don't open themselves up to any implicit liability from contributors who are contributing to GPL licensed Canonical projects. I would be _shocked_ if they allowed themselves to be scapegoated by business partners looking to duck out of legal liability when it comes to GPL licensing in other contexts. So really I think this whole line of discussion is quite absurd.

-jef

Vendors can be evil if they want to be evil.

hummassa — Tue, 03 Jul 2012 19:38:01 +0000

... only if you are evil-er and buy from them.
:-D

'You have to divulge your private key' meme

mjg59 — Tue, 03 Jul 2012 16:53:00 +0000

Could a hardware vendor produce a device that only boots operating systems the hardware vendor approves of? Clearly, yes. Vendors can be evil if they want to be evil.

'You have to divulge your private key' meme

robdinn — Tue, 03 Jul 2012 16:34:23 +0000

Hardware vendors of budget laptops have already shown that they are willing to go to the effort of adding anti-features to their products to, say, disable hardware virtualization. I am second guessing why, but one reason might be that they want you to purchase a higher spec model with a higher purchase price if you want to use such features. (Shenanigans like this are nothing to do with Microsoft).

Could the hardware vendors to the same thing with locked keys. They (the hardware vendor) makes a choice that they are only going to support a restricted set of Microsoft Operating Systems on some of their products. They might believe that this would reduce their support costs because they don't have to deal with returned machines where the user has wiped the microsoft keys, bricking the device. It would also provide them with an opportunity to sell the customer a different model where the keys are not locked down, at a price premium of course.

You say that Microsoft's current rules would forbid such activity. That's welcome but Microsoft could change the rules in the future.

The vendor is choosing not to ship any free software so free software licences are moot.

I am trying to think of ways for the hardware vendor to do evil things.

'You have to divulge your private key' meme

mjg59 — Tue, 03 Jul 2012 15:21:44 +0000

They'd be starting from the reference implementation, which also includes support for modifying the key database, so they'd need to actively spend time removing the functionality. That seems like a strange way to save money, especially since they'd then be unable to sell into the Windows 8 market.

'You have to divulge your private key' meme

rich0 — Tue, 03 Jul 2012 14:02:00 +0000

I think the key words in your post are "their partners."

If somebody loads Ubuntu on a system and ships it without Canonical's knowledge/participation, then Ubuntu can't be sued over this. They're not a party - they distributed GPLv3 software under the GPLv3, and it is the duty of anybody doing redistribution to comply with the license. In the same way you can't sue some contributor to Grub over something Canonical does with it.

However, if Canonical enters into some kind of agreement with the system vendor then I'd think that would change things legally. Now Canonical is complicit in the distribution in some way, especially if money starts changing hands.

If you violate the GPL that is none of my concern, but if I pay you to violate the GPL then legally I'm more entangled. Apple can't claim they don't distribute iOS because Foxconn does the image loading, and so on.

'You have to divulge your private key' meme

nye — Tue, 03 Jul 2012 12:29:33 +0000

>And what happens if a there comes a new vendor tomorrow who doesn't implement support for this in order to save $0.02 per unit?

Then they would *potentially* have a GPL3 problem, and they wouldn't be able to get Windows certification.

In that case, saving $0.02 per unit doesn't seem like such a great trade-off, since the resulting machine would have a target audience closely resembling (if not actually equal to) the empty set.

'You have to divulge your private key' meme

NAR — Tue, 03 Jul 2012 09:15:21 +0000

Every firmware vendor has implemented support for modifying the key database.

And what happens if a there comes a new vendor tomorrow who doesn't implement support for this in order to save $0.02 per unit?

'You have to divulge your private key' meme

jspaleta — Tue, 03 Jul 2012 05:14:00 +0000

I think.. at this point.. its would be best for all of us if Canonical would take the time to schedule a meeting with the FSF to further clarify any remaining liability concerns that is not addressed in the FSF statement to their satifaction.

I think the FSF has done all that can be reasonably expected to clear up any misconceptions in the public statements from Canonical so far. Now the ball is pretty much in Canonical's court. If they or their partners still have lingering concerns they really need to reach out and engage the FSF in a dialogue, even at this late date in their decision making process. And then the FSF can follow-up on that discussion with an addendum to their advice statement to further clarify their public advice statement.

Anything else the rest of us want to talk about is basically just navel gazing for no real benefit. The FSF has addressed the publicly stated concern from Canonical in full. If Canonical or their partners have yet more concerns they have not made public, then they need to either have a private conversation with the FSF about them, or make the concerns public so the FSF can address them for the benefit for other distributors as well. Benefit of the doubt only gets you so far. At some point you actually need to sit down with the other party and have a discussion. The FSF has opened the door, Canonical just needs to task someone to walk through it.

-jef

'You have to divulge your private key' meme

raven667 — Tue, 03 Jul 2012 02:26:37 +0000

That is harsh. I'd give him the benefit of the doubt unless there was a clear reputation for unreasoning behavior.

'You have to divulge your private key' meme

mjg59 — Tue, 03 Jul 2012 00:22:23 +0000

Every firmware vendor has implemented support for modifying the key database. A hardware vendor would need to explicitly disable this in order to lose the feature, and if they did then they could produce another firmware build that had it enabled again. I can't see any real way that a vendor could accidentally sell a machine that had no way of complying with GPLv3 other than Canonical providing private keys.

'You have to divulge your private key' meme

dgm — Mon, 02 Jul 2012 23:39:00 +0000

You're not misreading.

FUDing.

That's what you are doing, for some reason that scapes me. You insit on attaching to Canonical, Ubuntu and their partners some sort of legal liability that does not exist, even after that being explained in at least six different ways.

I come to the conclusion that you're just pretending to be dense.