Weekly Edition
Return to the Security pageRecent Features
| |||||||||||||||||||
Details on Ubuntu's UEFI secure boot plan
Canonical provided an update earlier today on our plans for implementing compatibility with UEFI's new "Secure Boot" mechanism in Ubuntu: http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-... I'd like to provide a brief update on the technical details of this implementation so that people have some idea of what's happening. Boot loader selection ===================== UEFI Secure Boot allows users to install their own keys and sign boot loaders themselves, and in that case the boot loader can do whatever the user is comfortable with. However, Ubuntu needs to boot out of the box on factory systems if at all possible, and that means playing by the rules of whoever owns the keys installed on those systems. Typically, that means that the boot loader must not execute any unsigned code in a firmware context, that is, before ExitBootServices is called just before jumping into the kernel. So, the bad news first: at this point, we are not planning to use GRUB 2 by default on systems with secure boot enabled. As a search through its ChangeLog will show, we've put a considerable amount of upstream development effort into GRUB 2 and we hope to carry on doing so, so this wasn't an easy decision. Matthew Garrett has outlined Fedora's plans in some detail elsewhere, and they do involve GRUB 2. The reason we've arrived at a different plan is that Ubuntu has a rather extensive base of preinstalled systems. Microsoft's Windows 8 logo requirements do say that there must be a way for users to disable secure boot or to install their own keys, and we strongly support this in our own firmware guidelines; but in the event that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn't then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would end up worse off. (Plus, Fedora is going to have to lock down GRUB 2 a certain amount itself to make sure that it can't execute unsigned code before ExitBootServices, which seems likely to come at some cost to its flexibility.) So, at this point, despite the fact that we clearly don't want to be part of delivering locked-down PCs to users, it looks as though we need to use a boot loader with a more liberal licence in order to protect ourselves from accidents. GRUB Legacy with Red Hat's EFI patch stack would probably do, but we really don't have much interest in resurrecting that code if there's any possible alternative at all. The kernel has an EFI boot stub nowadays, but we'd like a bit more pre-boot flexibility: at least a menu. Our current plan is to use Intel's efilinux loader with some modifications to add a relatively simple menu interface. Kernel signing ============== We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code, before the ExitBootServices UEFI service is invoked. Currently, this call is performed by the boot loader, before the kernel is executed. Therefore, we will only be requiring authentication of boot loader binaries. Ubuntu will not require signed kernel images or kernel modules. Key management ============== As announced earlier today, we've generated an Ubuntu signing key for use with UEFI. The private half of this key will be stored securely on our Launchpad infrastructure, which will be responsible for signing boot loader images and distributing them in the Ubuntu archive. Booting our CDs will rely on a loader image signed by Microsoft's WinQual key, for much the same reasons as Fedora: it's a key that, realistically, more or less every off-the-shelf system is going to have, as it also signs things like option ROMs, and the UEFI specification only allows an image to be signed by a single key. This will then chain to efilinux signed by our own key (so we don't have to go through the WinQual signing process every time we want to make a minor change there). We hope that we'll also be able to make the first stage loader detect whether Secure Boot is enabled and otherwise chain to GRUB 2, to ensure that we don't regress behaviour for those with UEFI systems that do not implement Secure Boot or that have it disabled. Ubuntu preinstalled machines ============================ For machines where Canonical has been engaged to preinstall Ubuntu, the situation does not differ significantly from the configuration a user would find if they bought a machine off the shelf and then installed Ubuntu. The only functional difference from such a post-sale Ubuntu install will be the addition of an Ubuntu key in firmware. Machines that ship as "Ubuntu certified" will be required to have an Ubuntu key configured in their UEFI signature databases. The intention here is to allow these systems to receive updates for the revoked signature database, in order to be protected against known-compromised UEFI binaries. We are not planning to provide an alternative to Microsoft's signing infrastructure, only an additional key; so we have no current plans to implement a signing service using the Ubuntu key. When implemented, this functionality will not be restricted to preinstalled Ubuntu systems. Provided that their UEFI firmware allows key reconfiguration, all users will be able to add the Ubuntu key manually, and receive the same updates. We will be requiring that the standard Microsoft key be present in the Ubuntu certification process. This means that an Ubuntu certified machine will be no more locked down than other machines on the market, and will be compatible with any UEFI binaries that can be used on a Windows machine. -- Steve Langasek, Colin Watson, and Jeremy Kerr (Log in to post comments)
No signed kernel, just a signed boot loader Posted Jun 22, 2012 18:47 UTC (Fri) by mjw (subscriber, #16740) [Link] We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code, before the ExitBootServices UEFI service is invoked. Currently, this call is performed by the boot loader, before the kernel is executed. Therefore, we will only be requiring authentication of boot loader binaries. Ubuntu will not require signed kernel images or kernel modules.So that is a lot more flexible than the Fedora approach. What is the reason Fedora will lock down the kernel and modules that access hardware directly? Is there a catch? Otherwise it seems it would be enough to just have one boot loader signed and with that people are free to install any kernel they want.
No signed kernel, just a signed boot loader Posted Jun 22, 2012 18:54 UTC (Fri) by cjb (guest, #40354) [Link]
mjg59's blog posts suggested that Ubuntu's approach would result in a key revocation, since the signed bootloader can be used to boot a kernel that installs Windows malware, defeating the security of the system.
No signed kernel, just a signed boot loader Posted Jun 22, 2012 19:54 UTC (Fri) by dashesy (subscriber, #74652) [Link]
I am no expert in this, but can the boot loader hide/protect the entire Windows partition so that kernel cannot access it, nor detect it's presence?
No signed kernel, just a signed boot loader Posted Jun 22, 2012 20:04 UTC (Fri) by cjb (guest, #40354) [Link]
> I am no expert in this, but can the boot loader hide/protect the entire Windows partition so that kernel cannot access it, nor detect it's presence?
No, not with current technology. Linux can simply undo whatever the bootloader does.
With eMMC devices, there's a "power-on read-only" lock that makes the device read-only until the next time the MMC controller loses power. If that technology were included in hard disks, something like you describe might be possible.
The eMMC power-on read-only technique was used on the T-Mobile G2 cell phone, stopping rooting of the device by making the kernel and rootfs read only inside the bootloader, before booting the kernel. It didn't hold out against sustained effort -- someone found a GPIO that the eMMC reset line was hooked up to, wrote a kernel module that pulses the line and reinits the MMC host in read/write mode before the VFS notices that anything changed, and disables the lock. Security is hard.
No signed kernel, just a signed boot loader Posted Jun 22, 2012 20:53 UTC (Fri) by marcH (subscriber, #57642) [Link]
http://www.schneier.com/blog/archives/2007/12/how_to_secu...
Computer security is hard. Software, computer and network security are all ongoing battles between attacker and defender. And in many cases the attacker has an inherent advantage: He only has to find one network flaw, while the defender has to find and fix every flaw.
Cryptography is an exception,...
No signed kernel, just a signed boot loader Posted Jun 25, 2012 7:56 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] Cryptography is an exception,...
That reminded me of this great chart Valerie Aurora once posted. Granted, that covers cryptographic hashes specifically, but I'd go so far as to suggest even cryptography is an arms race to some extent. Of course, practically, it's usually many orders of magnitude easier to attack the system around the cryptography than the cipher itself. (When it's not, it's because some genius decided to roll their own cipher, or someone installed a back door.) A 256-bit AES key is theoretically secure beyond the heat-death of the universe, provided nobody finds a mathematical weakness in AES. But, if you can find a flaw in the key generation, an attack against the AES implementation, or some other flaw in the hardware, software or communication stack it's employed in, then you transform the problem back into a software/computer/network security problem and your point stands. So don't mind me... I'm just being a little glib. Happens when I'm working overnight again. ;-)
No signed kernel, just a signed boot loader Posted Jun 23, 2012 14:37 UTC (Sat) by salimma (subscriber, #34460) [Link]
Seems to me that that wouldn't be fine-grained enough to make one partition read only while other partitions remain read/write.
No signed kernel, just a signed boot loader Posted Jun 23, 2012 15:06 UTC (Sat) by joey (subscriber, #328) [Link]
Signing a kernel does not prevent exploiting future security holes in the kernel. So in time there will be many signed kernels that can be used to install Windows malware.
No signed kernel, just a signed boot loader Posted Jun 24, 2012 16:54 UTC (Sun) by droundy (subscriber, #4559) [Link]
Besides that, couldn't a malware author simply run their windows-corrupting programs as root?
No signed kernel, just a signed boot loader Posted Jun 24, 2012 17:33 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
No. If they directly alter the Windows bootloader or kernel then booting Windows will fail. If they alter Windows userspace then the malware checking code that's started before any other userspace will notice.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:00 UTC (Mon) by dashesy (subscriber, #74652) [Link] If they alter Windows userspace then the malware checking code that's started before any other userspace will notice.Sure it should not be hard to fool malware checking code to believe that nothing is tinkered with, otherwise we already could have perfect anti-malware but we do not. If Windows user space program can be changed, Windows registry hives would be the target. Registry among other things controls many aspects of the NT kernel and some drivers, and maybe the secureboot itself BTW, I am not sure if Microsoft can afford denying its superusers from changing registry because in the practical world one most likely will need it
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:12 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Sure, anti-malware isn't perfect but if the system is thoroughly owned before the anti-malware starts and lies to it then you don't even have a chance. At least you have a small base system that's likely to be intact you can defend from before malware has a chance to subvert the system.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 22:47 UTC (Mon) by dashesy (subscriber, #74652) [Link]
True, but if secure boot relies on some sort of access controls or file protection (applied by NT kernel) any root access to the file-system can be used to circumvent the integrity of the entire system. OS kernel alone is not interesting. Malware can for example add its root certificate and set a startup service to install a driver on the next boot, there are probably some more creative ways to achieve the same thing.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
No it can't. Device drivers (and other critical system code) have to be signed.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:22 UTC (Mon) by dashesy (subscriber, #74652) [Link] I am assuming Malware is running under a legitimate Linux kernel (with no bugs) messing with Windows partition with full access right. So something like DISABLE_INTEGRITY_CHECKS in boot.ini no longer works on Windows 8? Also root can no longer use CertMgr to add custom certificate for custom signed drivers?My point is that, with the complexity of NT, by having root access to those bits and bytes the attack surface is so tremendous there is probably no need to have an unsigned Linux kernel
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:27 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>I am assuming Malware is running under a legitimate Linux kernel (with no bugs) messing with Windows partition with full access right. So something like DISABLE_INTEGRITY_CHECKS in boot.ini no longer works on Windows 8? Also root can no longer use CertMgr to add custom certificate for custom signed drivers?
Nope. Neither DDISABLE_INTEGRITY_CHECKS nor installing your own certificates will work if secure boot is enabled.
Drivers have to be signed by MS's certificate to be installable.
>My point is that, with the complexity of NT, by having root access to those bits and bytes the attack surface is so tremendous there is probably no need to have an unsigned Linux kernel
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:27 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
DISABLE_INTEGRITY_CHECKS no longer works unless you disable secure boot. Ditto any custom certificates.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 6:45 UTC (Tue) by slashdot (guest, #22014) [Link]
How about just installing a Windows service or putting something in the Startup folder or CurrentVersion\Run or /etc/init or .config/autostart in Linux, etc.?
Will anything prevent that software from starting and then going full screen and imitating the normal Windows GUI while behaving arbitrarily at the discretion of the malware writer?
If they block any autostart of non-Microsoft-signed programs, they'll break a ton of existing setups, while otherwise secure boot will provide no security whatsoever.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 13:29 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Windows starts the malware checking code before it launches any other userspace.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 23:12 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Yes, so it's a good thing that secure boot doesn't rely on that. Really, commenting on this without at least skimming the spec does not further the discussion.
No signed kernel, just a signed boot loader Posted Jun 24, 2012 17:33 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
And those will have their signatures revoked.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 3:46 UTC (Mon) by hummassa (subscriber, #307) [Link]
I would like to understand why and how. Why would an exploit over a Linux kernel punching thru an exploit over a Windows kernel would cause revocation of the signature of that kernel. I would also like to know HOW will they keep revocation databases for each and every hundreds of thousands exploitable Linux and Windows kernels -- and more, HOW they will catalog each of these exploitable kernels, if many of the exploits are as of this date still unknown by the white hats. And don't even get me started in two things:
1. cryptographic flaws can be exploited in the signing algorithms (like Flame virus) and cause the wrong (but unknown) kernel or bootloader to load; 2. a single flaw in the infrastructure used to revoke signatures can dismantle the whole card castle and cause a MASSIVE DoS... like "brick every windows8-capable computer ever".
Someone else in this thread mentioned that security is harder for the defender than for the attacker because the defender has to plug every hole, but the attacker need only to find one hole. I would add: the defender has to plug every hole AND still be able inside the system. Yes, if you add 10-feet-thick concrete walls around your house without doors or windows, no burglar will ever enter it... neither will you.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 4:10 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The idea of secure boot is to ensure that it's as difficult as possible to run untrusted code before you've set up your desired trust chain. If you can launch untrusted code within the Linux kernel then it's a simple matter to use that as an attack vector for Windows - rather than writing your malware from scratch, you drop a copy of the exploitable kernel in the EFI system partition, provide a trivial initramfs that gets you into the kernel, pass in the NT kernel and appropriate drivers, set up the loader parameter block, set up some new page tables and jump into the Windows kernel. Of course, rather than just booting it you've taken the opportunity to compromise it in some subtle way. Windows boots slightly more slowly than usual, but there's no reason for most users to notice - and worse, the malware checking code that would normally be able to rely on the kernel not having to be compromised is now unable to do anything useful.
So that's the why - breaking the trust barrier results in revocation. The how is a little more difficult. There's two ways you can revoke binaries. The first is to add an update of the specific SHA256. That makes sense in many cases, but probably isn't the best choice here - any older kernels are presumably also compromisable. So instead you just revoke the individual signing key and sign your kernels with a new one. How will that scale? Great question. We'll find out.
And yes obviously there's the risk of implementation flaws. The cryptographic model in use is believed to be sound, and we assume that Microsoft have learned from their mistakes with the Terminal Server key. Is that a guarantee? No. But then SSL isn't guaranteed to be safe either, and people still rely on that. Proving security is hard.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 12:28 UTC (Mon) by hummassa (subscriber, #307) [Link]
There are a lot of problems in this.
> The idea of secure boot is to ensure that it's as difficult as possible to run untrusted code before you've set up your desired trust chain. If you can launch untrusted code within the Linux kernel then it's a simple matter to use that as an attack vector for Windows - rather than writing your malware from scratch, you drop a copy of the exploitable kernel in the EFI system partition, provide a trivial initramfs that gets you into the kernel, pass in the NT kernel and appropriate drivers, set up the loader parameter block, set up some new page tables and jump into the Windows kernel. Of course, rather than just booting it you've taken the opportunity to compromise it in some subtle way. Windows boots slightly more slowly than usual, but there's no reason for most users to notice - and worse, the malware checking code that would normally be able to rely on the kernel not having to be compromised is now unable to do anything useful.
> So that's the why - breaking the trust barrier results in revocation.
That is the first problem with secure boot: KNOWINGLY breaking the trust barrier results in revocation. Worse yet: breaking the trust barrier knowingly and from the point of view of anyone in the trust chain results in revokation. This is preposterous, because it causes revocation against the will of the computer owner. So, I have to agree with jiu and eduperez and say that "secure boot was devised to distract the energy of people building linux to hinder their progress" and "Secure boot was created to lock users out of their own computers".
Those two problems amount to: if someone in a high position in the "trust chain" can lock you out of your own computer because "fsck you, that's why", they can. More: they cannot lock malware out of your computer because (1) it is difficult/impossible to know what is malware after all and (2) lots of malware will stay hidden and the vulnerabilities that lead to infection and pnwing will not generate key revocations because people in the trust chain do not know about them. Again, stuxnet and flame are good example of "hidden for about two years", which is plenty of time for doing plenty of sabotage and espionage.
And then the problems in the how:
> The how is a little more difficult. There's two ways you can revoke binaries. The first is to add an update of the specific SHA256. That makes sense in many cases, but probably isn't the best choice here - any older kernels are presumably also compromisable. So instead you just revoke the individual signing key and sign your kernels with a new one. How will that scale? Great question. We'll find out.
It does not scale at all.
I have stated above that the why is a flawed premise. But the how is a nightmare. For someone to revoke a key what you have to do is to write that key or that sha256 or whatever to a database that will be read in the UEFI level. THAT, per se, is a huge vulnerability. Who writes that database? How is that database read (and checked for veracity) by the UEFI level? When? At boot time via the network (spoofable)? Read from disk (corruptible)? Signed? With the same key you are revoking? With an escrow key that can be used to revoke any key? You load a new key how? If all keys are revoked, what happens?
Basically, in security terms, you are revoking access to the computer for someone based on an externally-entered (coming from the network, no less!) string. This is as tainted as it gets.
But it only gets worse: the platforms (Linux/Windows8) and their kernels are not security proven and are not even security-oriented. They present lots of opportunities for attacks and they will continue doing so for a long time. It is virtually impossible to plug every single hole in them and it's impossible to revoke the key that signs them at every single vulnerability because if you do that (1) your revoked keys database will be huge and (2) you will force updates down the throats of the users, effectively locking them out of their computers, not forgetting (3) opening up new opportunities to attacks coming from the infrastructure outside the trust chain.
> And yes obviously there's the risk of implementation flaws. The cryptographic model in use is believed to be sound, and we assume that Microsoft have learned from their mistakes with the Terminal Server key. Is that a guarantee? No. But then SSL isn't guaranteed to be safe either, and people still rely on that. Proving security is hard.
The problem is, I am not even factoring implementation flaws, above. Just normal vulnerabilities (buffer overflows, integer overflows, finite state unexpected transitions, etc) and normal attacks OUTSIDE the "chain of trust" implementations (key distribution for reloading and revoking, etc).
And we still have to factor in cryptographic security failures that are sometimes exploitable (hash/signature collisions were used in Flame IIRC)...
No signed kernel, just a signed boot loader Posted Jun 25, 2012 13:43 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
If only the revocation mechanisms were documented in some kind of specification, or something. Wouldn't that be wonderful?
No signed kernel, just a signed boot loader Posted Jun 25, 2012 13:48 UTC (Mon) by hummassa (subscriber, #307) [Link]
linky linky?
No signed kernel, just a signed boot loader Posted Jun 25, 2012 13:51 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
No signed kernel, just a signed boot loader Posted Jun 26, 2012 1:49 UTC (Tue) by hummassa (subscriber, #307) [Link]
I had got it just before I saw your link; thanks. I will read it carefully in the next day or so (if $DAYJOB and $HOMECARE give me some space) and will get back to you. But I will tell you beforehand that if the mechanisms are not crowded with possible attack vectors I will be VERY pleasantly surprised.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 15:49 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> This is preposterous, because it causes revocation against the will of the computer owner. So, I have to agree with jiu and eduperez and say that "secure boot was devised to distract the energy of people building linux to hinder their progress" and "Secure boot was created to lock users out of their own computers".
This is BS because the owner can create their own keys, disable secure boot, etc. so they can't be shut out of their machine against their will, that is not a real thing. Now if you start talking about boot locked machines that might be a different story but we definitely are not talking about that, even MS wants to make sure x86 hosts aren't boot locked (only their ARM tablets, like many Android devices).
In any event this is a feature that can be used for the good of the system by the system owner and that is what Linux will use it for.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 18:10 UTC (Tue) by rahvin (subscriber, #16953) [Link]
The only reason MS changed (yes changed) the spec to allow disabling secure boot was because of public outcry. As others have pointed out this was one of the bullet points in the halloween memo (leveraging hardware alliances to lock out linux). It would be foolish to dismiss this potential motivation as MS sees Android as a significant threat.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 11:55 UTC (Mon) by micka (subscriber, #38720) [Link]
I'd be surprised if those who then broke my computer (ie those who revoked the key that allows it to boot) were not liable for that.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 15:12 UTC (Mon) by pboddie (subscriber, #50784) [Link]
I wonder how this marvellously "clever" scheme interacts with consumer rights legislation when people find that their laptops don't work any more because someone has pushed the remote off-switch.
Obviously, the whole thing is yet another competition-busting scheme with just enough spin to confuse the regulators and make neutral observers give it the benefit of the doubt (that it is "probably good for security" or the laughable claim that "Microsoft isn't running this show"), but these things usually meet their demise when people end up being sold "faulty" products.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 16:49 UTC (Mon) by micka (subscriber, #38720) [Link]
I just checked. In my country, causing someone else's computer to not function anymore seems to be able to send someone to prison (up to 5 years).
Of course, what applies to common people may not apply to Microsoft or Canonical.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 17:01 UTC (Mon) by gioele (subscriber, #61675) [Link]
> I just checked. In my country, causing someone else's computer to not function anymore seems to be able to send someone to prison (up to 5 years).
I suppose that there are a lot of other things that must happen at the same time before you jail someone. Otherwise every borked update to Debian sid or Rawhide would send quite a bit of people in prison.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 18:26 UTC (Mon) by pboddie (subscriber, #50784) [Link]
I think there's a difference between a "best effort" update - one that the users may actually have instigated themselves - and someone bricking those users' computers because they're running something that the people with the control don't like. Moreover, if a Debian or Fedora update went wrong, you could probably do a re-install - the hardware would still function in most cases - whereas "secure boot" seems to be all about making the hardware useless unless you agree to run precisely what other people want you to run. And even then, at least for the average user, maybe it also involves the penalty of having to return the hardware for servicing.
But as I noted, such schemes are mostly used to erode the rights of users in the name of something else so that people don't question such schemes until after they have been introduced, and thus any argument about how a dominant vendor has managed to obliterate the competition can be waved away many years after the fact with excuses like "it's what the market expected" and "nobody demanded anything else".
No signed kernel, just a signed boot loader Posted Jun 25, 2012 18:39 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> "secure boot" seems to be all about making the hardware useless unless you agree to run precisely what other people want you to run
That is hyperbole and is not what secure boot on x86 does. It'd be great if we could stick to a discussion based on the facts.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:28 UTC (Mon) by pboddie (subscriber, #50784) [Link]
Oh sure, you can sign your own payloads and install your own keys, but in practical terms this means that people who buy computers will not only have to put up with what the vendor pre-installed - just like the majority of people won't ever "install Linux over Windows", even though lots of people think that this is a good enough workaround - but they will have yet another barrier if they do ever discover that they could run something else.
And I'm sure it's not beyond the skills of the vendors to make installing one's own keys a near impossibility and then claiming it was an accident for as long as it takes before they can then claim that the product is no longer supported.
So in practical terms, it is all about control. We can discuss technical workarounds as much as we like and deny that the technology imposes any particular restrictions, but the combination of one company's continuous strategy of pushing the regulatory envelope and that technology results in a shoring up of that company's position.
Why else are the distributions jumping through hoops? Because they like a challenge? The practical effect of the misuse of such a technology is as much a fact as any aspect of the "it's OK - I can still boot my kernel" technical discussion.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:40 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> you can sign your own payloads and install your own keys
So we agree on the substance of the matter. I can't comment on the rest of your post because I can't find any facts or point, just a lot of rhetorical flailing about.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 11:03 UTC (Tue) by pboddie (subscriber, #50784) [Link]
Oh well, let this be another place on the Internet I have to go back to at some point in the future and write "I told you so" for all the good that actually does. Nothing to see here, I guess: keep staring at the bits and bytes.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 18:10 UTC (Tue) by marcH (subscriber, #57642) [Link]
> > you can sign your own payloads and install your own keys
> So we agree on the substance of the matter. I can't comment on the rest of your post because I can't find any facts or point, just a lot of rhetorical flailing about.
Too bad things are not that obvious to Fedora and Canonical. They should have hired you and saved a lot of effort.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 19:14 UTC (Tue) by raven667 (subscriber, #5198) [Link]
Oh har har har, Mr Sarcastic guy. In any event I am merely relating the understanding and rationale that Fedora and Canonical have publicly written. The fact that the OP doesn't seem to want to read or understand that is the issue I'm trying to correct.
Foolish on my part I suppose. http://xkcd.com/386/
No signed kernel, just a signed boot loader Posted Jun 25, 2012 18:56 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
The core issue here is the on-by-default requirement for consumer hardware coupled with the specs limitations which prevents a mult-vendor trust chain.
Secureboot as a concept is not a bad thing. The policy surrounding how to enable secureboot for consumer devices needs some iteration however. There is absolutely nothing wrong with an off-by-default secureboot even with the current specification and limitations. On-by-default, has some definite challenges, and MS's certification process requirements brings these challenged directly into the forefront of the discussion.
Even with an on-by-default scheme, if users can disable secureboot to regain access to a system that has been impacted by a key revocation I really don't see a fundamental problem. As long as users are not locked out of the firmware config screens to disable secureboot on the hardware they purchased, a 3rd party revocation process is best described as a very stringent notification about a potential system compromise. If users can disable secureboot they do not lose access to their systems even after a key that their current configuration requires has been revoked.
In fact I'd wager that once the security benefit is digested more widely large institutions like the US Department of Defense and the State Department and even municipal power companies will be making heavy use of secureboot with their own signing keys on a lot of critical infrastructure and even desktops and laptops...so they don't even have to implicitly trust any Vendor (including Microsoft). They'll use the firmware reconfiguration to the fullest to load their own keys on their hardware and then self-sign binaries and to control the revocation process from end-to-end.
-jef
No signed kernel, just a signed boot loader Posted Jun 25, 2012 19:13 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> specs limitations which prevents a mult-vendor trust chain
I'm not sure that's true, you can have many vendor and user keys loaded into the firmware but to get your key pre-loaded would require some relationship with the vendor so your hardware coverage is likely to be less than 100%, whereas all the vendors want to be able to run MS so that key is virtually guaranteed to be loaded by default.
Actual binaries can be signed by only one key though so to boot and reduce the number of boot media spins required forces you to choose which key you are going to use to sign your initial boot loader and the MS key wins on convenience there.
> Even with an on-by-default scheme, if users can disable secureboot to regain access to a system that has been impacted by a key revocation I really don't see a fundamental problem
Which is exactly the case now for x86. Win8 ARM hosts are boot locked but that's its own separate issue at this time, I don't think any Linux vendor is going to fool around with them. Just don't buy them an expect to run anything else on them (not much different that the rest of the ARM market anyway).
> companies will be making heavy use of secureboot with their own signing keys
Thats probably something they will want to do but it depends on how to sign or re-sign boot binaries. Is it possible to re-sign the Windows 8 boot loader for example and have the system not broken? Certainly this will be do-able, maybe even common, with Linux systems.
No signed kernel, just a signed boot loader Posted Jun 26, 2012 7:27 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]
You seem to have a lot of faith in municipal power companies commitment to security...
Unfortunately, regardless of the "should", there are plenty of examples to the contrary.
Whatever the original intent, in reality, UEFI's largest impact so far has been to impose a significant cost on open-source software, with the to-be-determined security benefits still vaporware..
No signed kernel, just a signed boot loader Posted Jun 25, 2012 21:33 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
so why aren't the sony execs in prison for their PS/3 update that made it impossible to run linux or other OSs?
No signed kernel, just a signed boot loader Posted Jun 26, 2012 7:41 UTC (Tue) by micka (subscriber, #38720) [Link]
Citing myself :
> Of course, what applies to common people may not apply to Microsoft or Canonical.
or Sony. The "Microsoft or Canonical" was not meant to be exhaustive.
Of course I'm exagerating. Even the individual cracker that bricks _one_ computer would not go to jail... t1he first time, unless they go against a police or big corporate computer.
The second time would be very different, though.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 17:09 UTC (Mon) by JEFFREY (subscriber, #79095) [Link]
Precisely, my concern regards a sort of mass DOS attack where someone evil has obtained the keys and remotely disables 90% of the computers out there. Oops.
No signed kernel, just a signed boot loader Posted Jun 25, 2012 17:15 UTC (Mon) by raven667 (subscriber, #5198) [Link]
My guess is that the risk is about the same someone breaking into the major vendors and pushing out an update that wipes everyones hard drives, ie. not very likely at all.
Details on Ubuntu's UEFI secure boot plan Posted Jun 22, 2012 19:15 UTC (Fri) by KGranade (guest, #56052) [Link]
Highlights:
Using the permissively-licensed* efilinux bootloader from Intel when UEFI is present. Not signing Kernel or Kernel modules. Ubuntu installed from disk will use a MS-issued key just like Fedora. Pre-installed systems are signed with an Ubuntu-specific key, and the firmware will have the MS key.
What is not at all clear from this is what happens on a user-installed system post-install. There is AFAICT no Ubuntu key in the firmware at this point, so I'm not sure how the system can boot unless they use a key that is chained off the MS master key.
There is also some mention of the user having to add the Ubuntu key manually in order to perform updates, though it's not clear if this is required for all updates or just for updates to the bootloader.
Conclusions:
*AFAICT it's an uber-permissive custom license unique to efilinux.
Details on Ubuntu's UEFI secure boot plan Posted Jun 22, 2012 19:32 UTC (Fri) by dbruce (subscriber, #57948) [Link]
"but in the event
that a manufacturer makes a mistake and delivers a locked-down system with a GRUB 2 image signed by the Ubuntu key, we have not been able to find legal guidance that we wouldn't then be required by the terms of the GPLv3 to disclose our private key in order that users can install a modified boot loader. At that point our certificates would of course be revoked and everyone would end up worse off."
IANAL, but I don't think that can happen. It seems to me that in the above scenario, the manufacturer would be in violation of the GPLv3. Assuming a relevant copyright holder stepped forward to enforce the terms, the manufacturer would have to cease distribution and could be forced to pay some sort of damages. But I doubt a court would be inclined or able to force Ubuntu to do anything, if Ubuntu wasn't the violator.
It sounds like a spin on the old "if I accidentally link my code to GPL code and distribute it, then the GPL will spread to my code", which of course is not the case.
Details on Ubuntu's UEFI secure boot plan Posted Jun 22, 2012 20:16 UTC (Fri) by cjb (guest, #40354) [Link]
> IANAL, but I don't think that can happen. It seems to me that in the above scenario, the manufacturer would be in violation of the GPLv3.
You're assuming that the source request is addressed to the manufacturer. What if the source request is addressed to Ubuntu? They did choose to make a GPL code release, and they do have the key that's a necessary part of the installation instructions for that release. IANAL either, but I think they would be in violation if they chose not to answer.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 21:22 UTC (Sat) by rich0 (guest, #55509) [Link]
The GPL does not require anybody to provide the sources of anything to anybody they didn't distribute GPL code to.
If Ubuntu doesn't distribute GPL code to end users then they don't have to provide source, keys, etc to them. Whoever does distributed GPL code to end users does have to do this, and anybody with a copyright to the code can sue them if they fail to do so.
Now, if one of the hardware vendors were to ask Ubuntu for their signing key, then they'd have to provide it to them. So, this isn't going to be of much help...
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 22:23 UTC (Sat) by anselm (subscriber, #2796) [Link] The GPL does not require anybody to provide the sources of anything to anybody they didn't distribute GPL code to. That's if they give the recipient the sources (keys, etc.) along with the executables. If instead they offer to provide the sources upon request, they have to do that for »any third party«. At least that's what the GPLv2 says, which is the version the Linux kernel uses.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 23:17 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
GPLv3 makes a distinction between source and "Installation Information" (keys and so on). You only have to distribute the latter if you distributed a User Product. If Canonical don't sell hardware themselves then that shouldn't trigger.
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 17:56 UTC (Mon) by hamjudo (subscriber, #363) [Link] Certain classes of configuration errors would cause the GPLv3 clause to trigger on companies selling hardware preloaded with the GPL software.Canonical is trying to write software that hardware selling companies will be willing to use. Even if Canonical itself isn't liable, they won't be able to get their customers, the hardware vendors, to ship the software if it is perceived to be a legal minefield. Hardware vendors with significant per unit profit margins can absorb the cost, if a fraction of systems need to be RMA'd. The business model does not work for hardware vendors with small margins if there is a significant chance of RMA expenses.
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 18:43 UTC (Mon) by raven667 (subscriber, #5198) [Link]
You probably know more than I do about it but I don't think the GPLv3 demands the release of private key material, it is only concerned with the owners practical ability to load their own modified software on the device, which is far more easily serviced by providing a mechanism to manage keys local or to disable signature checking on boot. In any case I'm sure someone could crate a contrived example where the only way to comply with the GPLv3 is to disclose signing keys but I don't think that is how it works in practice.
Details on Ubuntu's UEFI secure boot plan Posted Jun 22, 2012 20:43 UTC (Fri) by raven667 (subscriber, #5198) [Link]
This bit sounded like mistaken reasoning to me. The GPLv3 never requires distribution of private keys, that is just a bad meme that keeps going around. If the manufacturer pre-loads a machine then they are the ones distributing the software, just like other software where the manufacturer gets a license to distribute from the OS vendor. If, by some mistake, they don't provide a way to load user-customized software, by breaking key installs or preventing secure boot from being disabled, then they are in violation of their distribution license.
In this hypothetical case I think it would make sense for the manufacturer to RMA or refund the bad equipment. I think the talk about disclosing private keys is ludicrous.
Details on Ubuntu's UEFI secure boot plan Posted Jun 22, 2012 21:21 UTC (Fri) by bronson (subscriber, #4806) [Link]
The GPLv3 requires the ability to load user software. If the only way to do that requires disclosing the signing keys, then so be it, that's what must happen.
Remember that it's Microsoft who set this whole UEFI mess up, not Ubuntu.
Why does this sound so far fetched to you? Seems like a perfectly reasonable reading to me.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 21:25 UTC (Sat) by rich0 (guest, #55509) [Link]
Yes, but that duty only falls on whoever is distributing the code to the user in question. If a computer requires a signed GPL image to boot, then whoever distributed the computer with the GPL software on it has to provide the key. Nobody else is a party to this. If a vendor distributes GPL code and requires it to be signed by a key they don't have, then they've exposed themselves to legal liability with no remedy short of issuing new hardware.
How is Ubuntu a party to what some hardware vendor does with their software, unless they paid them to do it?
Details on Ubuntu's UEFI secure boot plan Posted Jun 27, 2012 1:28 UTC (Wed) by bronson (subscriber, #4806) [Link]
Ubuntu distributed the soft are to the vendor. You don't think the vendor will kick lawsuits their way if at all possible?
> How is Ubuntu a party to what some hardware vendor does with their software, unless they paid them to do it?
Ubuntu can enter into a valid contract with a hardware vendor with no money changing hands. And they can even get paid to do it! In fact, one would expect that this is their intent.
Details on Ubuntu's UEFI secure boot plan Posted Jun 27, 2012 8:13 UTC (Wed) by dgm (subscriber, #49227) [Link]
> Ubuntu distributed the soft are to the vendor.
But, as long as Ubuntu is not the one holding the keys, they will be in the clear regarding GPL compliance.
> You don't think the vendor will kick lawsuits their way if at all possible?
They can sue anybody they want, but that's frivolous litigation, and they may be fined for that.
Details on Ubuntu's UEFI secure boot plan Posted Jun 27, 2012 18:38 UTC (Wed) by bronson (subscriber, #4806) [Link]
> But, as long as Ubuntu is not the one holding the keys, they will be in the clear regarding GPL compliance.
Exactly. And Ubuntu is the only one holding their key. Did you think somebody else would have it?
> that's frivolous litigation
It's not frivolous if it's the only way for the white box distributor to to comply with GPLv3.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 10:29 UTC (Thu) by jschrod (subscriber, #1646) [Link]
OK, so if the hardware vendor is obliged to deliver the key, and Canonical plans to convince hardware vendors to use their key -- where does the vendor get the key from, if not from Canonical?
It's not of practical relevance that "user demand => Canonical commitment" does not happen. The thing that might happen is "user demand => vendor commitment => vendor demand => Canonical commitment", and that's what the fuzz is about, AFAIU.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 13:54 UTC (Thu) by dgm (subscriber, #49227) [Link]
I think you're assuming that:
- providing some key is the only way to allow modified software to run. - that key can only be Canonical's.
Instead, the hardware vendor can:
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:14 UTC (Thu) by jschrod (subscriber, #1646) [Link]
> I think you're assuming that:
> - providing some key is the only way to allow modified software to run. > - that key can only be Canonical's.
That's what this sub-thread is about. Read bronson's post (http://lwn.net/Articles/503072/) where it started. There it's argued that even under the assumptions cited by you above, this is OK. Then rich0 came in and told bronson that this won't matter for Canonical. And my contribution was to point out the fallacy in his thinking.
> Instead, the hardware vendor can:
These are other scenarios. It's about an hypothetical scenario where the end user can demand the keys. My contribution to the discussion is that then, in this case, a hardware vendor will not shield Canonical from that demand.
Please also note that the FSF seems to agree that the situation, that keys must be supplied, is plausibel, as Nate notes in the Security feature article. I wouldn't discard their opinion on the GPLv3's meaning as fast as many here are ready to do. And if I would be responsible for due diligence in a company and would receive such warning from the FSF, I would make sure that my company pays attention to it.
Btw, FTR: We use neither Ubuntu nor Fedora and will probably turn off secure boot on our systems, when it arrives. So I consider myself impartial concerning the different factions in this discussion.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 17:11 UTC (Thu) by dgm (subscriber, #49227) [Link]
Let's put some context, then:
raven667: In this hypothetical case I think it would make sense for the manufacturer to RMA or refund the bad equipment. I think the talk about disclosing private keys is ludicrous.
> My contribution to the discussion is that then, in this case, a hardware vendor will not shield Canonical from that demand.
In my opinion (IANAL), you're wrong. Those are the facts:
* The customer has received a device from a device vendor, with some software covered by the GPL v3.
So, to sum it up, the vendor would be distributing a pirated copy of Ubuntu. It's their fault, and they are the ones that have to pay for it.
To prevent this from happening, device vendors should provide means to load alternative keys or disable secure boot.
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 0:00 UTC (Mon) by dgm (subscriber, #49227) [Link]
> If the only way to do that requires disclosing the signing keys
Sure there are a few options before they get at that. Released a "fixed" version of the UEFI firmware being much easier for everyone.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 15:07 UTC (Sat) by blitzkrieg3 (subscriber, #57873) [Link]
> IANAL, but I don't think that can happen. It seems to me that in the above scenario, the manufacturer would be in violation of the GPLv3.
IANAL either. You're forgetting that the manufacturer and Ubuntu have a relationship. If Dell for example accidentally ships a locked down firmware and is in violation, and to be compliant they would need the signing key, they would put pretty significant pressure on Canonical to release the key.
Details on Ubuntu's UEFI secure boot plan Posted Jun 24, 2012 1:52 UTC (Sun) by Fowl (subscriber, #65667) [Link] Surely they could just release an update that would fix their bug.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 10:35 UTC (Thu) by jschrod (subscriber, #1646) [Link]
> It seems to me that in the above scenario, the manufacturer would be in
> violation of the GPLv3.
Yes, and the manufacturer will have a contract relationship with Canonical (why else would they use Canonical's key?), so the manufacturer's onus will be passed on to Canonical.
> IANAL, but I don't think that can happen. [...] It sounds like a spin on
Well, according to Nate's feature article on this weeks Security page:
> The company consulted with the FSF about that topic, and were warned
So you should be careful with that allegation of a spin: The source is said to be the FSF. Do you accuse them of spinning this tale?
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:35 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Why would Canonical sign a contract that left them open to that liability?
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:53 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Because otherwise -- without indemnification -- a hardware vendor would not put Ubuntu on the systems? The OEMs I know would demand such a contract. After all, the market for pre-installed Ubuntu systems ain't large; it's Canonical seeking out the hardware vendors, not the other way round.
And since, as Nate reports, the FSF seems to have warned Canonical that their interpretation of the GPLv3 is plausible, I wouldn't discard that warning so easily.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:58 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
I have no idea why Canonical would indemnify a vendor against mistakes the vendor has made. That's not usually how indemnification works.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 15:18 UTC (Thu) by jschrod (subscriber, #1646) [Link]
I interpret Canonical's posts and Nates article as follows:
Canonical wants hardware vendors to sell systems with pre-installed Ubuntu. They want to use their own key (i.e., the Canonical key, not a vendor key) on these systems. If they would use Grub2, they are afraid that the GPLv3 would backfire in the case that an end user demands keys for the system, owing to the GPLv3's anti-Tivo clause, to be able to change the running system. The FSF was asked and they answered that validity of such a demand seems to be plausible.
The vendor won't be able to pass on the Canonical key, as they don't have it. The ability to change the key and to resign all system stuff, is the obvious solution, and the one that you have chosen for Fedora. Canonical seems to have the opinion that implementation of a good key exchange facility is too much hassle for the vendor, and (my interpretation) diminishes their chances to get into a good relationship with the hardware vendor. They don't want the vendor pass on a key-release demand to them that they can't fulfill, either. So they took the easy way out, and use a non-GPLv3 boot loader -- problem surely gone, for them. And that after they made quite some investment, with upstream contributions, into Grub2, so it's surely not an straight-forward decision for them.
> That's not usually how indemnification works.
I regularly have to sign contracts, where I promise I delivered everything an end customer might ask for under the GPL, and where I take on the onus of delivering more stuff if an end customer comes up with a valid demand that is not covered by my deliverables. So, from my POV, such demands are common.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 15:26 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
It's fine providing the end-user is able to enrol their own keys - the original signing keys are then not required to replace grub, so there's no need to give them to anyone. Microsoft require that all Winodows-certified systems provide that functionality, so any off the shelf firmware is going to implement it - vendors would have to actively remove the functionality in order to have a problem. The contract with Canonical should simply state that it's the vendor's responsibility to provide this feature in order to comply with the software licenses.
If vendors *want* to ship systems without supporting re-enrolment of keys then yes, there's an obvious problem. But given Mark Shuttleworth's voiced concerns about user freedoms with secure boot, I'd be surprised if Canonical wanted to support that.
Details on Ubuntu's UEFI secure boot plan Posted Jul 1, 2012 13:39 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
FSF seems to disagree with Canonical's interpretation in this case however.
http://www.itwire.com/business-it-news/open-source/55484-...
"Sullivan said this was unfounded and based on a misunderstanding of GPLv3. "We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine."
Why not just chainload grub? Posted Jun 22, 2012 20:32 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link]
Can someone explain why the following won't work (it seems too obvious):
1. Write a minimal UEFI bootloader, signed by the keys, and available
2. That bootloader's job is to chainload Grub. (possibly verifying Grub's image).
3. Grub then does whatever it wants to.
It seems that this would work, provided that key revocation can only be authorised by the author of the bootloader. If I say my bootloader is working as I designed it (even though that design is intended to chainload Grub and bypass the security misfeature), can a 3rd party revoke my key?
Why not just chainload grub? Posted Jun 22, 2012 20:47 UTC (Fri) by cjb (guest, #40354) [Link]
I think the problem with your scheme isn't to do with revocation, but with GPLv3 source requests.
Canonical would be responsible for answering a grub2 GPLv3 source request with *any keys* necessary to permit modifications of grub2, even if those keys are technically involved with a piece of software (the EFI bootloader shim you describe) that's farther down the stack.
If they have to let you install a modified grub2 (by giving you the bootloader key), then they have to let you install whatever you want, at which point you've used their signed bootloader to boot your Windows malware payload and the security is broken.
Why not just chainload grub? Posted Jun 22, 2012 21:54 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> GPLv3 source request with *any keys*
I don't believe this is true, GPLv3 only requires that the user has the ability to replace installed binaries with their own modified versions, it's not specific as to how this is accomplished. The simplest and most effective way would be to provide for key management or disabling by the end user.
If anyone ever asked me, I'd suggest that one way for manufacturers to accomplish GPLv3 compliance in this regard would be to tie the boot loader verification to some tamper evident seal inside the unit. If you break the seal then you can load your own keys or disable the boot lock and it's clear that the device software is now your responsibility and not the manufacturers, also this might disable any DRM encumbered software on the box, like media players. That seems to be a win-win, manufacturers can safely ship GPLv3 software and users have full control over their devices.
Why not just chainload grub? Posted Jun 28, 2012 10:38 UTC (Thu) by jschrod (subscriber, #1646) [Link]
> > GPLv3 source request with *any keys*
> I don't believe this is true.
According to this week's Security page feature article, the FSF says that it's probably true. Thus, I can understand that Canonical is careful.
Why not just chainload grub? Posted Jun 29, 2012 7:02 UTC (Fri) by raven667 (subscriber, #5198) [Link]
That is a horrible FAQ entry and could really use some further elaboration. The way the FAQ explains it undercuts the GPLv3 and inadvertently provides FUD for detractors to throw around.
http://www.gnu.org/licenses/gpl-faq.html#GiveUpKeys
Their secure boot specific FAQ doesn't say anything like that and specifically references Matt Garrett's documents on the matter. Fedora obviously doesn't think there is anything wrong with signing a GPLv3 GRUB2 and the FSF links to it as their explanation.
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/
There is another thread along the same lines here https://lwn.net/Articles/504015/. A vendor shipping a signed, boot locked, GPLv3 GRUB2 would be a pirate, distributing without a valid copyright license. There are many way ways to resolve that, recalling/refund/RMA of hardware, a firmware update, etc where disclosing the private signing keys is the least likely method to achieve compliance, although it is a valid one.
Why not just chainload grub? Posted Jun 22, 2012 20:48 UTC (Fri) by KGranade (guest, #56052) [Link]
The concern mjg59 expressed about a configuration like this was that it's possible to use it to bootstrap a compromised Windows instance that thinks it is running on secured hardware. Deployment of a system like this would lead to revocation of the signing key used by the system.
What's not clear is why Cannonical thinks their solution doesn't run afoul of this, since you should be able to chainload either another bootloader or a Linux system that can accomplish the same goal from efilinux. They say something about it being ok as long as their bootloader enters a certain state before executing untrusted code, but there are few details about that here.
Why not just chainload grub? Posted Jun 22, 2012 20:50 UTC (Fri) by cjb (guest, #40354) [Link]
> Deployment of a system like this would lead to revocation of the signing key used by the system.
That's true for Fedora's setup, but Canonical is describing shipping with their own key preinstalled on the system. Only they can revoke their own preinstalled key.
(Actually, Microsoft could retaliate by revoking the key that allows the Ubuntu CDs to boot, but that's not a direct effect.)
Why not just chainload grub? Posted Jun 22, 2012 21:06 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
Canonical will only be using their own key on OEM hardware specifically intended to run Ubuntu. They'll be using a Microsoft-signed bootloader everywhere else.
Secure boot if user selects Windows? Posted Jun 24, 2012 7:17 UTC (Sun) by gmatht (guest, #58961) [Link]
It seems to me that the signed bootloader could offer two options:
1) Microsoft Windows (signed) 2) Ubuntu (unsigned).
If the user selects (2) then the unsigned Ubuntu could load a malware infested Windows, but it would be less suspicious to just load a malware infected Ubuntu. Whenever the user attempts to load Windows, they are protected by secure boot as before.
If the goal is instead to protect DRM from the user, then the bootloader should do whatever a "correct" BIOS does when given a self-signed key. That way, if the DRM is broken it can't be blamed on Ubuntu.
Details on Ubuntu's UEFI secure boot plan Posted Jun 22, 2012 20:45 UTC (Fri) by raven667 (subscriber, #5198) [Link]
I'm not getting a good sense, from the words that they have written, that Ubuntu has as good a handle on the issues around Secure Boot as mjg59 and Fedora do. Some of their reasoning, esp. the part about GPLv3 compliance issues for GRUB 2, seems bogus to me and I'm not sure they are solving any real problems the way they are going about this.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 0:16 UTC (Sat) by jspaleta (subscriber, #50639) [Link]
the gpl3 license interpretation aside......
I simply do not understand the rationale for not requiring signed kernels and kernel drivers. This seems to defeat the whole point of secureboot. As soon as a signed bootloader allows you to load an unsigned blob..game over.
This is sort of the whole point of the revocation process isn't it? Once a signed bootloader is compromised to allow it to run verified blobs..you revoke the key and prevent the signed bootloader from operating on that system.
You might as well just disable secureboot and be done with it if you are going to use a Microsoft signed bootloader that allows anything to be loaded.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 0:19 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
the issue is the fear that trying to tell users how to disable this will make it too hard for them to install linux.
the linux distros aren't doing this because they are trying to lock the system down and make it safer, they are just trying to make it not noticably harder to install their distro on a new machine than it is today.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 0:43 UTC (Sat) by jspaleta (subscriber, #50639) [Link]
I do not thing you can lump all distros and distro vendors together as to whether or not they see value in secureboot as a feature. There are recognized limitations of the specification that make it more painful than it should be, but some do see value in the secureboot goal. And I bet vendors who understand how to run a profitable software business will find customers who understand the security value and will produce a solution that exposes the value. Other vendors, who continue to do the least amount of effort possible, will continue to fail to attract paying customers and will continue to bleed money. To those vendors, this is just an engineer resources drain.. not an opportunity to upsell a security feature.
But more specifically....If Canonical is going to be using a MS signed bootloader... it seems to me what MS considers what secureboot enabled implies is going to matter a lot. So Canonical does this... MS revokes their key...and we are back to square one with Ubuntu users having to disable secureboot to work with Ubuntu. Except now its users with already installed dual-boot Ubuntu/Windows who find they can't load their Ubuntu bootloader because of a key revocation from MS.
Here's to hoping MS doesn't see Canonical cavalier attitude towards signed kernels as a security threat to windows installs. I really really hope that MS considers any dual boot situation as a non-starter for enforcement and ignores anything involving an alternative bootloader unless a request comes in from the entity who controls the bootloader's signature to revoke a key. Hope for the best... plan for the worst.
-jef
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 0:54 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
the two vendors who have spoken up so far (canonical and Fedora) both seem primarily worried about the difficulty in installing the distro on new hardware.
so I think it's fair to use those statements to say what the main concern seems to be.
There may be other distros in the future that try to use this for security, but that's not the situation right now.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 4:39 UTC (Sat) by bgilbert (subscriber, #4738) [Link] Dual-boot systems are not the problem. A worm targeting Windows-only systems could install the Ubuntu bootloader and use that to chainload itself at boot.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 4:47 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Or use the Ubuntu bootloader to target non-Ubuntu Linuxes.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 2:21 UTC (Sat) by dmaxwell (guest, #14010) [Link]
I use Linux based netboot solutions to install images and I often do this remotely. In particular, I'm currently using FOG to install XP and Win7 images and I've triggered this remotely more than once. As an added wrinkle, I also use Linux to remotely image both OS X and Windows to Intel Macs.
I absolutely have to have machines able to boot in Linux, install the OS images required, then boot into the non-Linux OS that the end user is going to use. Vendor centric Secureboot could really mess me up.
At a minimum, I need to be able to add keys to the BIOS on these machines that allow both my imaging infrastructure and Windows to boot. We are phasing the Macs out by attrition for other reasons.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 23:13 UTC (Sat) by debacle (subscriber, #7114) [Link]
> I simply do not understand the rationale for not requiring signed kernels and kernel drivers.
As long as I can easily and without any financial cost use kernel and drivers signed by myself, this would be OK. All this "open source" and "free software" stuff is about being able to change the software. If I understood Fedora's plan correctly, their solution implies that I cannot change the kernel or drivers without sacrificing secure boot, contrary Ubuntu's approach, right? PCMIIW.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 23:19 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Just add new keys to the firmware database. Any machine with a Windows logo will let you do that.
Details on Ubuntu's UEFI secure boot plan Posted Jun 23, 2012 23:22 UTC (Sat) by AndreE (subscriber, #60148) [Link]
No. You can add your own key to the UEFI and sign your kernels with that
Details on Ubuntu's UEFI secure boot plan Posted Jun 24, 2012 14:50 UTC (Sun) by slashdot (guest, #22014) [Link]
Why is not executing unsigned code before ExitBootServices so important, while it's fine to do afterwards?
Anyway, if that's the goal it seems that it's simple to do: just patch GRUB2 to call ExitBootServices immediately, and then proceed to boot using the legacy BIOS interfaces, or just direct hardware access.
Details on Ubuntu's UEFI secure boot plan Posted Jun 24, 2012 15:04 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
I don't think there's any meaningful distinction between executing arbitrary code before and after ExitBootServices() - the only real difference is that the flash is guaranteed to be locked down afterwards. UEFI doesn't give you access to any legacy BIOS interfaces (the legacy video ROM has tended to be there for various reasons, but that'll be vanishing now), and direct hardware access would mean porting a large number of drivers to grub.
Details on Ubuntu's UEFI secure boot plan Posted Jun 24, 2012 14:57 UTC (Sun) by slashdot (guest, #22014) [Link]
Regarding the "manufacturer mistake" GPLv3 violation scenario, that's bullshit, since the manufacturer is obviously the one violating the GPLv3 when redistributing GRUB2, not Ubuntu.
And copyright law doesn't force past mistakes to be fixed (especially when action from a 3rd party would be required): that manufacturer would simply have to pay the FSF monetary damages, should the FSF sue.
Of course this assumes that the manufacturer is selling the system using Ubuntu; if Canonical itself is selling it using manufacturer-supplied hardware, they would be liable, but of course they can just check that the system is not locked, and avoid selling it if is.
Canonical needs to fire their lawyers if they can't tell them this...
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 0:05 UTC (Mon) by dgm (subscriber, #49227) [Link]
I smell something fishy here too. It all sounds like a bunch of excuses to justify a political decision (going with the Intel solution).
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 3:45 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
I am willing to give the the benefit of the doubt as to motivation on this point. I don't think they have the correct interpretation...but I'm also not the one with a large liability hanging over my head either if I'm wrong...so I'm not going to pull my eye pointing stick out on this particular point and jab them with it.
And if I'm willing to give them the benefit of the doubt, then certainly everyone else here should be able to as well... just this once.
And besides... their early support of grub2 upstream is a bright spot in their upstream contribution story. It's difficult to envision a new political/strategic consideration (other than the stated discomfort with the licensing associated with crypto keys) which would make dropping grub2 look like a good strategic move now and not 6 months ago...well at least to me.
There is probably enough uncertainly in how to proceed with signed grub2 binaries that a clean public statement from the copyright holder on grub2 (the FSF) about how a signed grub2 scheme should be implemented as a best practices approach to compliance would be welcome by pretty much everyone compiling grub2 binaries for distribution.
-jef
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 14:00 UTC (Mon) by misc (subscriber, #73730) [Link]
Maybe Canonical plan to directly sell hardware in the futur ?
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 15:53 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> Maybe Canonical plan to directly sell hardware in the futur ?
Maybe, they certainly have hardware partners though that sell pre-loaded systems, like System76.
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 5:28 UTC (Mon) by jiu (subscriber, #57673) [Link]
I disagree with this interpretation:
"We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code" My interpretation is that secure boot was devised to distract the energy of people building linux to hinder their progress.
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 6:11 UTC (Mon) by eduperez (guest, #11232) [Link]
> I disagree with this interpretation:
> "We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code" > My interpretation is that secure boot was devised to distract the energy of people building linux to hinder their progress.
Secure boot was created to lock users out of their own computers; period.
Details on Ubuntu's UEFI secure boot plan Posted Jun 25, 2012 11:40 UTC (Mon) by slashdot (guest, #22014) [Link]
Well, the problem is all technologies who give strong assurance to the user that their computer is behaving as expected, are pretty much exactly the same ones needed to give the same assurance to a third party (also known as "digital rights management").
For example, to prevent a physical attacker replacing your motherboard with one without secure boot you'd need to require an USB smartcard that is kept by the user and authenticates the system, but that exact same mechanism can be used by a remote server to authenticate your system as one respecting DRM rights on the content it sends.
In addition, those technologies are perfect to create monopolies by allowing the vendor's software to be considered the only legitimate one.
IMHO the only effective solution is legislation to make DRM and tying hardware to software illegal (btw, this is easy: just say that anyone doing so loses all their IP rights), so that users can trust that security mechanisms will not be used against them; otherwise, I expect all legitimate security systems to fail due to strong anti-DRM pushback.
I guess it's unlikely that such a law will be passed, so we'll have to live with imperfectly secure systems for the time being.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 12:45 UTC (Thu) by gerv (subscriber, #3376) [Link]
"and the UEFI specification only allows an image to be signed by a single key"
That seems to be the flaw at the heart of it all. Is there any possibility of that ever being fixed?
Gerv
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:33 UTC (Thu) by dashesy (subscriber, #74652) [Link]
I was wondering exactly the same; that why no body asked for this. Then I (as a normal desktop) could just avoid buying hardware that does not have Linux keys I care (Fedora Certified, Ubuntu Certified, ...).
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:37 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Yes. It turns out that the specification actually permits it, but doesn't describe what the semantics of having multiple keys should be. Further, the only implementation ignores any key after the first.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:50 UTC (Thu) by gerv (subscriber, #3376) [Link]
Surely the semantics of multiple signatures is "attempt to validate them all, in order, and proceed if any of them validate"? What are the other options? "Proceed if all of them validate"?
Can we fix the existing implementation? (Who wrote it?) And encourage BIOS authors (is that right? I'm sure there's more than one of them) who are still implementing to get this right?
Gerv
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 14:56 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
And blacklisting? There are Obviously Correct interpretations, but since they're not written down it's well within the realms of possibility that people would screw this up. There's ongoing work to rectify this, but it's not going to happen in time for the first wave of machines.
Details on Ubuntu's UEFI secure boot plan Posted Jun 28, 2012 15:11 UTC (Thu) by gerv (subscriber, #3376) [Link]
Good point about blacklisting. I'm really glad to hear there's ongoing work to fix this; it gives me hope that in 5 years time, the situation may not be as bad as it looks now.
Gerv
|
|||||||||||||||||||