| |||||||||||||
'You have to divulge your private key' meme'You have to divulge your private key' memePosted Jul 6, 2012 16:34 UTC (Fri) by davidescott (guest, #58580)In reply to: 'You have to divulge your private key' meme by dgm Parent article: The FSF's advice to distributors on UEFI secure boot
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.
(Log in to post comments)
'You have to divulge your private key' meme Posted Jul 6, 2012 17:02 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
(d) is required for (a).
'You have to divulge your private key' meme Posted Jul 6, 2012 17:17 UTC (Fri) by davidescott (guest, #58580) [Link]
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 Posted Jul 6, 2012 17:23 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
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 Posted Jul 6, 2012 17:35 UTC (Fri) by davidescott (guest, #58580) [Link]
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 Posted Jul 6, 2012 17:49 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
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.
Duplicating EFI functionality is a waste of time Posted Jul 8, 2012 1:51 UTC (Sun) by zlynx (subscriber, #2285) [Link]
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.
Duplicating EFI functionality is a waste of time Posted Jul 8, 2012 2:00 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
"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 Posted Jul 10, 2012 3:09 UTC (Tue) by raven667 (subscriber, #5198) [Link]
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 Posted Jul 10, 2012 3:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
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.
Duplicating EFI functionality is a waste of time Posted Jul 10, 2012 4:21 UTC (Tue) by raven667 (subscriber, #5198) [Link]
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.
'You have to divulge your private key' meme Posted Jul 6, 2012 17:28 UTC (Fri) by davidescott (guest, #58580) [Link]
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 Posted Jul 6, 2012 17:42 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
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 Posted Jul 6, 2012 17:59 UTC (Fri) by davidescott (guest, #58580) [Link]
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 Posted Jul 10, 2012 3:12 UTC (Tue) by raven667 (subscriber, #5198) [Link]
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.
|
|||||||||||||