FSF Weighs in on Secure Boot

In the ongoing saga of secure boot, the Free Software Foundation has issued a whitepaper that “outlines the difficulties Secure Boot poses for the free software movement and free software adoption, warns against the threat of Restricted Boot, and gives recommendations for how free software developers and users can best address the issues.”

In the paper, the FSF recaps the approaches taken by Fedora and Ubuntu to address the problem. The FSF says there is much to like about Fedora’s thinking, but goes on to say, “Unfortunately, while it is compliant with the license of GRUB 2 and any other GPLv3-covered software, we see two serious problems with the Microsoft program approach.” They outline the problems as follows:

1. Users wishing to run in a Secure Boot environment will have to trust Microsoft in order to boot official Fedora. The Secure Boot signing format currently allows only one signature on a binary – so Fedora’s shim bootloader can be signed only by the Microsoft-vouched key. If a user removes Microsoft’s key, official Fedora will no longer boot, as long as Secure Boot is on.
2. We reject the recommendation that others join the Microsoft developer program. In addition to the $99 expense being a barrier for many people around the world, the process for joining this program is objectionable. 

The Ubuntu approach states that machines preinstalled with Ubuntu, will have an Ubuntu-specific key generated by Canonical in their firmware. Ubuntu CDs will depend on Microsoft’s key in the machine’s firmware to boot when Secure Boot is active. And, Ubuntu bootloader images distributed from the official Ubuntu archive will be signed by Ubuntu’s own key. 

The FSF’s main concern here is that Ubuntu plans to drop GRUB 2 on secure boot systems in favor of another bootloader with a different license that lacks GPLv3’s protections for user freedom. In the whitepaper, they urge Ubuntu and Canonical to reverse this decision and reiterate that the focus of the FSF is “to evaluate proposed solutions to the issues posed by Secure Boot on the basis of how well they protect user freedom, to recommend the solutions that do the best job of that, and to stop attempts to turn Secure Boot into Restricted Boot.” You can read the Secure Boot whitepaper online.