UEFI and secure boot in depth

UEFI and secure boot in depth

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

SHARE:
4

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.

Topic: Operating Systems

J.A. Watson

About J.A. Watson

I started working with what we called "analog computers" in aircraft maintenance with the United States Air Force in 1970. After finishing military service and returning to university, I was introduced to microprocessors and machine language programming on Intel 4040 processors. After that I also worked on, operated and programmed Digital Equipment Corporation PDP-8, PDP-11 (/45 and /70) and VAX minicomputers. I was involved with the first wave of Unix-based microcomputers, in the early '80s. I have been working in software development, operation, installation and support since then.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • Jamie: You Should Interview A Cryptography Expert

    Jamie,

    This topic has been flaring up off and on over the past few years. Before I read your interview with Mark Doran, I was already reaching for the anti-nausea medication. I knew that he would evade the crux of the matter:

    "Did Microsoft abuse their position in the software industry and use UEFI secure-boot to block out Linux?"

    The answer is obviously "Yes."

    Mr. Doran is using the old "mechanism vs policy" argument. Its predictably pathetic. He prepared months, if not years, in advance, to your question, because he knows full well what Microsoft is doing.

    You should do your readership a huge favor. Interview a world-class cryptography expert [I suggest Ron Rivest over at M.I.T., the "R" in RSA as you know], and ask him/her the following question:

    1. "Is there any technical reason whatsoever that UEFI-Secure Boot should be tied to any particular OS vendor in order for the end-user to realize the benefit of secure-boot?"

    2. "How would you have implemented secure-boot?"

    Ask him/her to go into as much detail as reasonable, so that all the tech-heads who read your journal are able to follow along and conclude for themselves that the binding to Windows is entirely artificial and concocted by Microsoft.

    The reason for doing such an interview is very important: There are a lot of people, including the U.S. Department of Justice, for whom cryptography is a kind of black magic. They do not know what is fact and what is fiction, even after reading the specifications for asymmetric crypto, because it takes a while to be able to understand crypto primitives well-enough to know that nobody is pulling the wool over your eyes. In other words, even someone who might understand modular reductions and Miller-Rabin primality-testing might still lack the confidence to call Microsoft on their B.S.

    Someone, a respected journalist, should follow Mr. Doran's principle and do "mechanism, not policy" thing, meaning that you at least establish for us, by way of certification by an expert, that, at least, it is *TECHNICALLY* feasible to be OS-independent.

    This would go a long way in opening up public-dialogue on the subject, and the general public would decide what to do next.

    Right now, because so many of the concerned do not have solid foundation in crypto, Microsoft (and Intel) are able to wave their hands, speak a blurb, and proceed with impunity.

    Someone needs to set the facts straight, and that is not the responsibility of a cryptographer, or a politician, or law enforcement. It is the responsibility of an objective journalist, skilled in expository writing.
    Le Chaud Lapin
    • Of Course Microsoft Abused Their Position

      Hello, and thanks for the thoughtful comment. I think it is obvious that Microsoft abused their position, but that is no surprise, is it? That is what Microsoft does, and there are plenty of examples. The hijacking of the "standardization" of OOXML, the "Gosh, Sorry, We forgot" farce on browser choice, to name just two.

      I would love to conduct such an interview, and get a set of clear facts published. But I think you are overestimating my standing as a "journalist". I will keep this in mind, though, and perhaps I can do some more along these lines in the near future.

      Thanks for reading and commenting.

      jw
      j.a.watson@...
      • Thank you

        That was an excellent and detailed response from Le Chaud Lapin. And you recognized that. Too many of the writers on this site are clear advocates of particular companies/software sources, so I am happy to be surprised by someone who might be interested simply in what is actually happening in all its raw details.

        I am a forensic scientist and because of that I had to learn to publicly converse (trials) with attorneys who were specifically trained to obscure/distort/misrepresent the facts/truth (when that served their agenda). I had to learn to prevent underlying truths and facts from being buried or misrepresented as I spoke to the jury. Since you might be reading, consider the following question you asked:

        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?

        I suspect you are far more educated on the UEFI subject than your question exposes.

        You need to go through your knowledge and determine what are ultimately the core issues surrounding UEFI as it is being implemented today. Then you need to ask a series of questions that will ultimately lay bare those core issues - very much like Le Chaud Lapin gives examples for.

        Don't stop with the questions until all the "guts" surrounding the core issues are plainly visible. Here is a rule us experts witnesses often use, you might consider its application to your writing. Who gets on juries? Its not the brightest overall, many of those people found a way out. You have to keep the core issues simply understood. If you haven't asked enough questions such that you could expect Mr Average to clearly see the point, maybe a few more questions will clarify.
        dfolk2
  • What Abuse

    As I understand it, one requirement that Microsoft placed on all PC vendors is that it be possible to disable Secure Boot. This requirement is there so that someone who wants to install any other OS can do so.

    BTW, the secure boot was developed by the UEFI forum and Microsoft was very slow to adopt it, mainly to avoid having to deal with all the conspiracy theories that would spring up. However, after seeing the advances in BIOS attacks, there seemed to be no other option for protecting the early part of the boot process other than Secure Boot in UEFI.

    If you want to run Linux on a PC designed for Win8 you can do it. If you get the right versions of Linux, you can even have them boot with Secure Boot. Having Secure Boot on these machines even makes Linux better. Where's the abuse?
    zip98053