X
Business

UEFI and secure boot in depth

Q&A: My questions on UEFI and secure boot, answered by Mark Doran, the president of the UEFI Forum.
Written by J.A. Watson, Contributor

Following my recent posts concerning my experiences with Unified Extensible Firmware Interface (UEFI) and secure booting, here's a Q&A with Mark Doran, the UEFI forum president. In general I agree with what the UEFI Forum says — and I believe that it was long past time to do something about the ridiculously old and limited MS-DOS BIOS.

Q: There seems to be quite a bit of variation in the actual implementation of UEFI boot, and in particular in the ease of (or sometimes possibility of) changing the configuration. Is this something you anticipated?  Does it concern you, and do you think it has contributed to a negative impression of UEFI boot, in some areas?

This is something we do talk about, yes. UEFI firmware is still relatively new to many end users. We believe that with more experience in the marketplace, UEFI implementations will strike the optimal balance of uniformity and innovation.

Creating conditions that promote richness in the offerings of member companies is the Forum's prime consideration. Ultimately, this leads to more choices and innovations. The UEFI Forum has chosen to focus on defining mechanisms that represent interoperability interfaces and, whenever possible, to avoid discussion of policy choices about how to implement or consume the interfaces that make up the interoperability surface.

We recognize that this is somewhat of a double-edged sword. On one hand, this allows implementers of the standards the flexibility to examine the needs in the markets they serve, as well as to respond with implementation choices from the standards that best match their customers’ needs. On the other hand, focus on mechanism leaves room for different policy choices among different platforms and operating systems, which creates a variety of combinations and variations in presentation.

Q: Most UEFI boot implementations include optional "Legacy Boot" support. What are the implications of activating this? Does it actually disable a significant part of the UEFI BIOS functionality?

MD: Yes. Enabling Legacy Boot does disable the UEFI Secure Boot feature, as well as the UEFI runtime functions.  However, this feature is required in some systems, in order to enable use of older operating system versions that lack UEFI capability, as well as older expansion cards that lack UEFI Option ROM drivers. Generally, enabling Legacy support on a system that has been tuned to boot fast with that support disabled will lead to longer boot and resume times.

Q: The user interface for changing the UEFI boot configuration on most systems today has had mixed reviews. Are there any plans or discussions to produce a standard UEFI configuration editor, or even a standard UEFI multi-boot control program?

Configuration editors and/or multi-boot programs fall into the category of policy engines for the platform. This is where determinations are made about how various boot elements are controlled. Today, these things typically fall outside the scope of the UEFI Forum specifications.

The possibility for de facto standards to emerge for these components certainly exists. It seems likely that market feedback will help guide vendors towards improved solutions for these problems. Efforts are being made in various open source venues.

Q: Are you familiar with "rEFInd" utility for EFI multi-boot control?  What is your opinion of this program in particular, and this type of program in general?

MD: Yes. UEFI specifications make a number of pre-boot utilities possible. However, on a system with UEFI Secure Boot enabled, the binary of any utility must be signed by a trusted signing authority. Projects like this that might go the extra mile to produce a signed binary could make it easier for ordinary users to take advantage of their work on a broader range of systems.

Editorial standards