The Linux Foundation's UEFI approach won't secure computers but will allow homegrown Linux distributions to work with new hardware

Attempting to arrive at a solution to a complicated issue, the Linux Foundation has introduced a possible way that smaller Linux distributions can be run on machines using UEFI (Unified Extensible Firmware Interface) technology.

Linux Foundation technical advisory board member James Bottomley has posted a description of software that the foundation has developed to allow small and homegrown Linux distributions to run on new computers that have UEFI, also know as "secure boot" technology, installed.

"It is a good initiative, one that addresses the different use cases" of how people use Linux, said Gerald Pfeifer, director of product management for SUSE, which offers the commercial-grade SUSE Linux distribution.

SUSE, however, has no plans to use the foundation's approach for its own enterprise Linux distributions, and instead will use another approach that takes full advantage of UEFI's capability of securing machines. Red Hat, which did not immediately comment on the issue, appears to be following a similar approach, judging from blog entries from company engineers. Canonical did not offer an immediate comment.

The controversy centers around how to implement UEFI, an industry initiative to secure computers against malware by designing the computer's firmware to require a trusted key before booting. UEFI would provide a foundation for a chain of trust that would connect all the way up to the software layer, which could thwart attempts to install illicit, and harmful, software on computers.

Microsoft is requiring UEFI on all Arm-based machines running Windows 8, and many OEMs (original equipment manufacturers) will start placing the technology on x86-based machines as well. Linux observers expect that many machines will not run Linux at all, unless they have a UEFI trusted digital key.

Microsoft, through Verisign, is providing keys for third-party software to run in trusted mode on these machines, for a one-time $50 fee. The question the Linux community faces is how to provide keys for Linux distributions to run on UEFI machines in a way that does not lock out open-source software programs written by volunteers.

Over the past year, SUSE, Fedora and Canonical have all developed proposed solutions to this problem, mostly through the use of shims, or software workarounds and digitally signed kernels. This approach, however, has been met with criticism because it does not provide a way for the smaller or home-built Linux distributions to run on UEFI machines since each shim is built for its own specific distribution.

In the foundation's plan, the organization will obtain a Microsoft key to use on a new piece of software, called a pre-bootloader, which, when the computer is started, will load a program called a bootloader that, in turn, will boot Linux, or another operating system. The pre-bootloader will require a user to be present at the time it is run. The foundation will post the key and bootloader for anyone to use at no cost.

Board member Bottomley admitted that this approach provides no security protections.

"The current pre-bootloader .... provides no security enhancements over booting Linux with UEFI secure boot turned off," Bottomley wrote in a blog post. "Its sole purpose is to allow Linux to continue to boot on platforms that come by default with secure boot enabled."

This approach is only a stopgap measure, Bottomley admitted. The foundation is still encouraging the major Linux distributions to develop approaches that take full advantage of UEFI to secure a machine.

Red Hat developer Matthew Garrett, who has followed the issue closely on behalf of Red Hat and Fedora, discounted the Linux Foundation approach, stating that it is "less useful" than the shim approach because it "will boot untrusted images as long as a physically present end-user hits a key on every boot."

The Linux Foundation approach "requires manual intervention at some level, and requires you to know what you are doing, which is perfectly fine for a Linux kernel developer," SUSE's Pfeifer said. In contrast, SUSE's shim approach "will be much more transparent unless you want to dive into it." The SUSE kernel will be signed, so it can take full advantage of the UEFI.

"There are different approaches of doing things, and each has benefits and drawbacks," Pfeifer said. "There's nothing where UEFI and Linux wouldn't be able to get along very well."