|
|
|
| Authored by: Anonymous on Tuesday, July 03 2012 @ 01:01 PM EDT |
Furthermore, addressing the threat of Restricted Boot by weakening
the license of the bootloader is backwards. With a weaker license, companies
will now have a form of advance permission to obstruct the user's ability to run
modified software.
I take it to mean that having a non-GPLv3
bootloader means that another company could produce their own version of the
bootloader which restricted what OS and other software that you can
run.
While possible, I'm not sure how likely. It means that the company has
to get their key registered as well. And if the company is going to replace
Ubuntu's bootloader with their own, more restrictive one, they could do that no
matter what bootloader Canonical chooses. If Canonical went with Grub 2, it
doesn't mean that companies replacing Canonical's bootloader need to base their
more restrictive one on Grub 2.
Rather than work to make sure this
situation does not happen -- for example by enforcing the proper Secure Boot
implementation they say they "strongly support in [their] own firmware
guidelines" -- Ubuntu has chosen a path which explicitly allows Restricted
Boot.
It certainly would be good if we could convince
manufacturers to not implement Restricted Boot. But I can't really fault
Canonical for having a backup plan.[ Reply to This | Parent | # ]
|
| |
| Authored by: PolR on Tuesday, July 03 2012 @ 02:39 PM EDT |
My understanding of Restricted Boot is this refers to a configuration of UEFI
implemented by the hardware vendor which rejects all user supplied keys and does
not give the user any option to change or disable this behavior. Nothing will
boot unless it is signed by a key which is accepted by the vendor's supplied
UEFI configuration no matter how hard the user tries to get around this.
This is tivoization. Canonical is foregoing the protections of GPL V3 by
choosing a bootloader with a license that allows tivoization.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, July 03 2012 @ 03:00 PM EDT |
I have a different take:
Canonical's stated worry is about a hardware vendor enabling Restricted Boot by
accident and thus the vendor or Canonical being put in the position to have to
mitigate (do a BIOS update, recall, or, in their view, provide a signing key)
due to the GPLv3 GRUB2.
Canonical's reason for not using the GPLv3 GRUB2 is to avoid any potential
mitigation due to that kind of mistake.
The FSF's concern is now that Canonical isn't using the GPLv3 GRUB2 that there's
one less legal tool to prevent a hardware vendor enabling Restricted Boot on
purpose, even as far as taking Canonical's removal of GRUB2 as implicit support
for enabling Restricted Boot despite the wording of the Ubuntu Certification
requirements.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, July 03 2012 @ 07:09 PM EDT |
The FSF is basically saying they would rather that Canonical find some way to
persuade Intel and the other UEFI vendors to create a more general solution to
the Secure Boot problem. Instead, Canonical have come up with a work-around that
only addresses their more immediate problems while leaving the problem in place
for non-Ubuntu-certified hardware. Shuttleworth did say that they tried working
with the UEFI trade group, but got nowhere. Canonical doesn't really have much
influence with Intel on this issue.
Canonical need a solution right
now however for the "secure boot" hardware and firmware that are already in the
pipeline. They clearly don't think much of "secure boot" itself however, because
their solution essentially just bypasses it with a loader that will load
anything (on Ubuntu-certified hardware).
This isn't the end of the
"secure boot" story. It's just the beginning. What Canonical have at the moment
is just a short term fix. We have to remember here that the problem originated
with Intel, as they wrote UEFI.
The UEFI that most PC OEMs
will be shipping was written by Intel and is open source under a BSD type
license. The PC OEMs then add drivers and customisation to make it work with
their hardware. Most PC OEMs really don't care if their PCs run Linux. Once the
older versions of MS Windows have fallen out of support, there will be no reason
for them to ensure that any feature to turn off "secure boot" will be present or
functional in their hardware. What happens if you go to the firmware menu and
select "disable secure boot" but nothing changes because of firmware bugs? What
happens if the "non-secure boot" firmware code path crashes instead of booting
your loader? If a program feature isn't essential, there is a pretty good chance
that it won't work, as the PC OEMs won't care whether it works or not.
[ Reply to This | Parent | # ]
|
|
|
|
|
