User: Password:
|
|
Subscribe / Log in / New account

Why not just chainload grub?

Why not just chainload grub?

Posted Jun 22, 2012 20:32 UTC (Fri) by Richard_J_Neill (subscriber, #23093)
Parent article: Details on Ubuntu's UEFI secure boot plan

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
to everyone as a binary blob.

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?


(Log in to post comments)

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 (subscriber, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds