The Free Software Foundation (FSF) has published a statement outlining the organization’s concerns about secure boot and its potential implications for open source software. The paper also evaluates the solutions that Linux distributors Canonical and Red Hat have adopted to address the issue.

PC vendors that ship Windows 8 will have to ship their computers with UEFI secure booting enabled in order to meet the criteria of Microsoft’s Windows 8 Logo program. The secure boot mechanism ensures that only code signed with a trusted signature can execute at startup, thus protecting the user from malware that tampers with the operating system during the boot process.

As currently proposed, Secure Boot impedes free software adoption

Earlier this year, Linux users began to raise concerns about whether the security mechanism will impair the ability of regular end users to install third-party operating systems and open source bootloaders.

Microsoft’s compatibility specifications require the hardware vendors to provide a mechanism for disabling secure boot on x86 PCs, making it possible to install any third-party operating system without further obstacles. But there are still concerns about whether the process will be simple and transparent enough for new users. Disabling secure boot will also obviously eliminate the security benefits offered by the feature.

Canonical and Red Hat are taking steps to make it possible for users to install their Linux distributions without having to disable secure boot. Red Hat will sign the Fedora bootloader with a key from Microsoft in order to ensure that it can be installed out of the box on any standard Windows PC. Canonical will supply its own key that users will be able to configure as a trusted signature on their computers.

The FSF dislikes Red Hat’s approach because it means that Fedora users will have to rely on Microsoft’s signature and treat Microsoft as a trusted entity. Ubuntu’s approach doesn’t have that problem, but it has additional complexity because end users will have to configure UEFI to respect Canonical’s signature.

The FSF’s statement also addresses concerns about whether the GPLv3 conflicts with secure boot. The GPLv3 includes controversial language that prohibits the use of technical measures that would prevent users from modifying the software that runs on a device. Canonical was concerned that the terms of the license might force the company to disclose its private key in the event that a hardware manufacturer were to ship Ubuntu on a machine that doesn’t allow secure boot to be disabled.

In order to avoid that scenario, Canonical opted to swap out the GPLv3-licensed GRUB 2 bootloader for an alternative with more permissive licensing terms. The FSF says that such a move wasn’t actually necessary. The organization also expressed frustration about not having been consulted before Canonical made the decision.

According to the FSF, the hardware manufacturer would be responsible for ensuring compliance, not Canonical—which means that Canonical would not be compelled to disclose its secure boot private key. The FSF wants Canonical to reverse the decision and switch back to GRUB 2.

In addition to critiquing the implementation methods pursued by the Linux distributors, the FSF also commented broadly on the general premise of secure boot. Although the organization likes the concept in theory, it finds that the model pursued by the hardware manufacturers will raise serious problems in practice.

“Secure Boot, done right, embodies the free software view of security, because it puts users–whether individuals, government agencies, or organizations–in control of their machines. [But] in practice, the situation is more complicated. As currently proposed, Secure Boot impedes free software adoption,” the FSF wrote. “It is highly questionable that the security gains realized from Secure Boot outweigh the difficulties it will cause in practice for users trying to actually provide for their own security by escaping Microsoft Windows.”

The FSF has a petition calling for the hardware manufacturers to support disabling secure boot, ensuring that users can install the third-party operating system of their choice. Of course, any x86 system that is in conformance with Microsoft’s Windows 8 Logo guidelines already meets the minimum expectations stipulated by the petition.

Microsoft doesn’t require that hardware vendors provide an off switch for secure boot on ARM systems, however, so the matter is still a concern on that hardware. The FSF says that it will continue opposing that policy and will make sure that the public is made aware in the event that it trickles over to other form factors and types of systems.