UEFI boot: how does that actually work, then?

[sunrat]

So you don't understand UEFI? Read all about it and be even more confused!

Possibly the best article I have read on the subject (warning - long):

UEFI boot: how does that actually work, then?

[securitybreach]

Nice article!! Thanks

[amenditman]

The best, most important paragraph in the entire post.

Yes. You read that correctly. The Microsoft certification requirements, for x86 machines, explicitly require implementers to give a physically present user complete control over Secure Boot – turn it off, or completely control the list of keys it trusts. Another important note here is that while the certification requirements state that the out-of-the-box list of trusted keys must include Microsoft’s key, they don’t say, for e.g., that it must not include any other keys. The requirements explicitly and intentionally allow for the system to ship with any number of other trusted keys, too.

Really very few of the tech "journalist" got this point. And it seems like a lot of the developers at distros which use the shim bootloader signed with Microsoft's key are clueless about it also.The second best is,

These requirements aren’t present entirely out of the goodness of Microsoft’s heart, or anything – they’re present in large part because other people explained to Microsoft that if they weren’t present, it’d have a **** of a lawsuit on its hands² – but they are present. Anyone who actually understands UEFI and Secure Boot cannot possibly read the requirements any other way, they are extremely clear and unambiguous. They both clearly intend to and succeed in ensuring the owner of a certified system has complete control over Secure Boot.

Edited February 12, 2014 by amenditman

[V.T. Eric Layton]

My only confusion about UEFI is why was it necessary.

[V.T. Eric Layton]

tl;dr... just skimmed. Yeeeesh! This guy wrote a small book there. My middle finger got fatigued using the scroll wheel on the mouse. See...

 

http://img.photobucket.com/albums/v647/vtel57/Emoticons/middle_finger.jpg

 

I agree with Bob above, though... those two paragraphs are the meat in the pot pie. All the rest is just doughy crust and gravy. Mmm... now I'm hungry.

[crp]

My only confusion about UEFI is why was it necessary.

having used it a few times I will say they are quite nice , easier and more useful than the old BIOS.

Also much more "secureable", even if (as the article states) you use non-Microsoft keys.

(i do disagree with the reason non-Microsoft was allowed in. It wasn't the lawsuit but that OEM's would not go for it.)

[raymac46]

Fine article and would have saved me a lot of trouble and Googling had it been around a couple of months ago. Rod Smith is an excellent resource as well.

A few comments:

If you're buying a new motherboard make sure it has compatibility mode to choose old school BIOS if you don't want to be bothered with UEFI. This assumes you are installing Linux or an older version of Windows. Windows 8 is going to require UEFI.

Be consistent - BIOS requires MBR disk formatting and UEFI needs GPT formatting.

Some Linux distros support EFI but they still want to use/support the old style bootloaders that worked under BIOS. Sometimes they blend the two and it can be a pain getting them to work. If you want to install (say) Linux Mint and be picky about partitioning choose BIOS and MBR. Otherwise go for the defaults if you want to try UEFI.

Rod Smith has a lovely bootloader program called rEFInd that works great with UEFI. The problem is getting it installed, as you need a working system to do so. rEFInd doesn't even need GRUB to get the system booted.

EFI is really quite a nice thing if everybody would just suck it up and use it. It gives a far nicer and more configurable setup menu and it is very straightforward in the way it's specified and designed. It is the future for x86 hardware since most of that is Window-centric.

We've moved past 640K and 32 bit storage limits, DOS and Windows 98, and now XP. Isn't it time a 1980s firmware design got retired too?

Edited February 13, 2014 by raymac46

[V.T. Eric Layton]

Color me staid and hard headed, but I just don't understand the burning need to change something that has worked so well for decades. Why fix something that wasn't broken? What is the NUMBER ONE MAIN ADVANTAGE TO UEFI? Can someone answer me that?

[crp]

[...]

What is the NUMBER ONE MAIN ADVANTAGE TO UEFI? Can someone answer me that?

Sure. It is orders of magnitude

prettier than old BIOS.

 

You can also pick from it is extensible, not limited to largest boot drive size of 2TB , faster booting up than POST, more resilient to "rootkit" type attacks

I am sure others will pipe in with more.

[securitybreach]

Eric, here are some advantages:

http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Advantages

http://docs.oracle.com/cd/E20881_01/html/E20891/gltbf.html

http://www.techrepublic.com/blog/10-things/10-things-you-should-know-about-uefi/

[goretsky]

Hello,

 

The BIOS firmware standard dated back to the early 1980s and had been updated and revised over and over. UEFI grew out of a need to replace that in the mid-1990s when Intel began to develop the Itanium line of CPUs with their IA-64 instruction set, with what was just called EFI. About nine years ago, Intel turned the spec over to a trade group (which made is UEFI). Interestingly enough, the largest shipper of EFI systems has been Apple.

 

From a security perspective, UEFI allows you to do some interesting things:

 

Nuts and bolts

A big change for Windows 8's security posture-and one of the most vocally debated-is the requirement for computer manufacturers to replace the BIOS firmware (software embedded on motherboards) with a new type of firmware called UEFI.

 

BIOS, short for Basic Input/Output System, is the name of the ad-hoc specification designed to perform some basic self-tests after a computer has been powered on, initialize the computer's hardware and then pass control to the operating system. Originally introduced for the IBM PC in 1981, the BIOS technology used by PCs has been updated numerous times since then to account for new generations of computers. Unfortunately, the basic design has many limitations, some of which directly affect a computer's security.

 

UEFI, the Unified Extensible Firmware Interface, is a replacement for BIOS technology. Originally called EFI and created by Intel in the mid 1990s for use with its Itanium line of processors, this technology is now managed by the UEFI Forum, a consortium of several hundred companies including Apple, Canonical (Ubuntu), Dell, Hewlett-Packard, IBM, Intel, Lenovo, Microsoft, Oracle and Red Hat¹⁶.

 

Microsoft draws a line in the silicon

While UEFI is not particularly controversial, one of its features, Secure Boot, has received some criticism: Secure Boot is a feature that prevents a computer from booting into an operating system unless the boot loader code is digitally signed with a certificate derived from a key stored in the UEFI firmware. This digital signature allows the UEFI firmware to verify that the boot loader code it read from the disk into memory is from a trusted source before allowing the processor to execute it. This means the boot loader is actually the very first program to run from a disk when the computer is started.

 

This is an important security feature, because digital certificates are used to verify the authenticity of code, i.e., that the code is intact and unmodified. Digital certificates have been stolen and used by malware authors to sign code in the past, however, it is still quite rare for any malicious code to use a digital certificate. Blocking unsigned boot loader code basically prevents the computer from running a bootkit, immunizing it against intrusion.

What Microsoft has done is to place a requirement in the Windows 8 logo tests¹⁷ that computers shipping with a 64-bit version of Windows 8 (which will be most desktop and notebook computers) ship with Secure Boot enabled in their UEFI firmware by the manufacturer¹⁸.

 

The same requirements state that the user must be able to disable this feature, however.

While computer manufacturers can ship systems that have not passed Microsoft certification, doing so prevents them from receiving marketing benefits and being able to purchase licenses at volume prices, so skipping certification is not an option for most manufacturers.

 

Unfortunately, this small change, intended to improve the security of computers at boot time, has received condemnation, mostly from advocates of the Linux operating system, who are afraid this requirement for digitally signed boot code will prevent them from installing Linux or other operating systems that do not contain the appropriate digital signatures in their boot code.

 

The UEFI specification does not actually specify whose digital keys need to be in the UEFI firmware, and in addition to Microsoft, Linux providers Red Hat¹⁹ and Canonical (Ubuntu)²⁰ have come up with ways to support UEFI Secure Boot. In addition to that, the specification provides for toggling the Secure Boot mechanism²¹. If that is not enough reassurance, Microsoft has reiterated its position in its Microsoft Hardware Certification Requirements, stating that although Secure Boot must be enabled, the ability to turn it off must also be present on computers in order to pass certification.

 

¹⁶ UEFI Forum. "Membership List" United EFI, Inc. http://www.uefi.org/join/list

¹⁷ Microsoft. "Windows Hardware Certification Requirements: Client and Server Systems." 2 Jul., 2012. Microsoft Corporation. http://download.micr...ents-system.pdf

¹⁸ Sinofsky, Steven. "Protecting the pre-OS environment with UEFI." Building Windows 8 Blog. 22 Sep., 2011. Microsoft Corp. https://blogs.msdn.c...-with-uefi.aspx

¹⁹ Burke, Tim. "UEFI Secure Boot." News June 2012. 5 Jun. 2012. Red Hat. https://www.redhat.c...efi-secure-boot

²⁰ Langazek, Steve; Kerr, Jeremy and Watson, Colin."UEFI Secure boot and Ubuntu - Implementation" 22 Jun. 2012. https://lists.ubuntu...une/035445.html

²¹ UEFI Forum. Unified Extensible Firmware Interface Specification, Version 2.3.1, Errata C. 27 Jun. 2012. Unified E

Source: ESET White Paper Windows 8: FUD* For Thought [PDF, 357KB] (quoted without the permission of the author)

 

Right now, though, UEFI technology is still relatively in its infancy, at least with respect to the development of third-party security tools, which makes an interesting area to keep an eye on.

 

Regards,

 

Aryeh Goretsky

[raymac46]

I would say the #1 advantage is standardization. If the firmware engineers and software engineers get their acts together, just about any O/S for a given class of hardware could boot the same way. We wouldn't need to worry about Windows bootloader, Grub 1 Grub 2, LILO etc. etc.

Add in security, scalability, nice look and feel and it's a good package of features.

Besides that is how the Windows elephant is moving so you can expect that the mobo makers will tag along. Better to learn about it now.

[sunrat]

.... If the firmware engineers and software engineers get their acts together,...

And there's the rub. The article has some despairing remarks about that.

[abarbarian]

Color me staid and hard headed, but I just don't understand the burning need to change something that has worked so well for decades. Why fix something that wasn't broken? What is the NUMBER ONE MAIN ADVANTAGE TO UEFI? Can someone answer me that?

 

To make money and have control of the pc world.

 

You see,

 

"About nine years ago, Intel turned the spec of EFI over to a trade group (which made is UEFI)"

 

"this technology is now managed by the UEFI Forum, a consortium of several hundred companies including Apple, Canonical (Ubuntu), Dell, Hewlett-Packard, IBM, Intel, Lenovo, Microsoft, Oracle and Red Hat^{. "}

 

Now they added,

 

"Secure Boot is a feature that prevents a computer from booting into an operating system unless the boot loader code is digitally signed with a certificate derived from a key stored in the UEFI firmware. "

 

Now Microsoft seem to be the only folk who have certificates for secure boot. You can turn of secure boot but then you loose some of the security it brings. An for some strange reason Red Hat and Canocial have done a deal with Microsoft and can use some of thier certificates.

 

Which I find strange as,

 

"The UEFI specification does not actually specify whose digital keys need to be in the UEFI firmware"

 

So why are Microsoft the only certificate folk, why did Red Hat and Canocial bend thier knees to the lords of Microsoft, why did the linux and open community not rally around and team up to get their own certificates ?

 

Simple answer, loot and power.

 

[V.T. Eric Layton]

 

 

Simple answer, loot and power.

 

 

WOO-HOO! While probably not totally true, this is an anarchist's answer that I can live with.

[sunrat]

Simple answer, loot and power.

Discussions of UEFI so often seem to devolve to discussions of Secure Boot which is an optional feature.

I do think the Linux Foundation could work out a way to make it work better with Linux in general, rather than just disabling it. Canonical seem very selfish about this, Red Hat maybe not so much.

I also recommend reading the whole article I posted, and comments.

[Guest LilBambi]

The sad thing is, so many devices to disallow installation of other OSes and some do NOT give you the control to turn it off.

 

Most, but not all OEMs do have a place to disable it in the UEFI firmware area of the system.

[V.T. Eric Layton]

You can't disable UEFI on any system where it is being utilized instead of BIOS. You are supposed to be able to disable Secure Boot, though. Secure Boot is the component of UEFI that everyone is up in arms about. At least that's my understanding from the article that Roger linked to here.

[securitybreach]

You can't disable UEFI on any system where it is being utilized instead of BIOS. You are supposed to be able to disable Secure Boot, though. Secure Boot is the component of UEFI that everyone is up in arms about. At least that's my understanding from the article that Roger linked to here.

 

Actually you can. For instance, my motherboard has an option to let you choose to between UEFI or MBR (as do most UEFI motherboards out right now). It actually has a secondary UEFI bios as well in case of corruption. http://www.gigabyte....spx?pid=4145#ov

 

This is a reply I found (amazing enough in the arch forums) that describes this function:

I have a UEFI DualBIOS Gigabyte board. It's UEFI. The "DualBIOS" bit means what headkase mentioned, there's a second chip on the board containing a backup of the UEFI firmware. The reason they call it DualBIOS is because it's their trademark - they've had this feature of a backup chip already in the old BIOS days.

 

However, like many UEFI boards, this one has a BIOS compatibility mode - the built-in boot menu shows two entries for each device, one prefixed with UEFI and one without. So it's up to you what to use: create a GPT disk with an EFI partition and put an EFI boot manager there (gummiboot is very nice), or create a MBR disk and boot it in BIOS compatibility mode using a classic bootloader. Since it's an UEFI board, you might as well go with that.

https://bbs.archlinu...php?pid=1331739

 

The reason I have done this is because I would have to switch my partition table to GPT and I haven't had the time to move that much data. I have been meaning to get around to it but I just havent the time and I need even more drives (already got 6.5tb).

 

The Archwiki has a really extensive page for UEFI covering pretty much every aspect of it including differences. https://wiki.archlin...mware_Interface

 

You can even boot archlinux with secureboot enabled: https://wiki.archlin...ace#Secure_Boot

[V.T. Eric Layton]

You cannot use "UEFI bios" in a statement. One is not the other nor related. It's like saying that truck out in the parking lot is a ChevyDodge. HAS ANYONE commenting here actually read that article linked to above by Sunrat?

 

So, what you're saying is that your mobo has two different (at least) methods of handing over hardware initiation to the operating system or boot loading software found on your hard drive, right. You can choose between UEFI or another method like BIOS instead.

 

From the article above:

 

First, let’s get some terminology out of the way. Both BIOS and UEFI are types of firmware for computers. BIOS-style firmware is (mostly) only ever found on IBM PC compatible computers. UEFI is meant to be more generic, and can be found on systems which are not in the ‘IBM PC compatible’ class.

You do not have a ‘UEFI BIOS’. No-one has a ‘UEFI BIOS’. Please don’t ever say ‘UEFI BIOS’. BIOS is not a generic term for all PC firmware, it is a particular type of PC firmware. Your computer has a firmware. If it’s an IBM PC compatible computer, it’s almost certainly either a BIOS or a UEFI firmware. If you’re running Coreboot, congratulations, Mr./Ms. Exception. You may be proud of yourself.

 

About Secure Boot:

 

Secure Boot is not the same thing as UEFI. Do not ever use those terms interchangeably. Secure Boot is a single effectively optional element of the UEFI specification, which was added in version 2.2 of the UEFI specification. We will talk about precisely what it is later, but for now, just remember it is not the same thing about UEFI. You need to understand what Secure Boot is, and what UEFI is, and which of the two you are actually talking about at any given time. We’ll talk about UEFI first, and then we’ll talk about Secure Boot as an ‘extension’ to UEFI, because that’s basically what it is.

 

Just trying to get this figured out in my mind...

 

Help me out here, Roger. You started this.

[securitybreach]

Yes, I can change between MBR and UEFI depending on my configuration and arch can boot secure boot as long as setup some things. I realize that UEFI is a replacement for bios but amazing enough, some mb companies(including mine) call it UEFI Bios.

[sunrat]

Help me out here, Roger. You started this.

Haha. I refer my esteemed fellows to the last sentence of my previous post.

[abarbarian]

The best, most important paragraph in the entire post.Really very few of the tech "journalist" got this point. And it seems like a lot of the developers at distros which use the shim bootloader signed with Microsoft's key are clueless about it also.

 

[sunrat]

This bit is important:

The above describes the basic mechanism the UEFI spec defines that manages the UEFI boot process. It’s important to realize that your firmware user interface may well not represent this mechanism very clearly. Unfortunately, the spec intentionally refrains from defining how the boot process should be represented to the user or how the user should be allowed to configure it, and what that means – since we’re dealing with firmware engineers – is that every firmware does it differently, and some do it insanely.

and

Wait, we can simplify that. “Any firmware is crap code”. Usually pretty accurate.

Thus, what happens on one computer may not necessarily be the same on another.

UEFI is still new to most users and we are all noobs explorers.

 

Wow, I'm having a dark day today. Abused 2 posters at Debian forums, 4 kids at the local swimming pool, and now this non-optimistic post. And perversely enjoying it.

[crp]

I don't think ASUS turns on Secure Boot as a default.

[abarbarian]

I don't think ASUS turns on Secure Boot as a default.

 

If the Asus pc has a Windows 8/8.1 sticker on it it has to have Secure Boot turned on as do all pc's from any manufacturer.

 

Read this Microsoft blog post on the matter.

 

http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx

 

There have been some comments about how Microsoft implemented secure boot and unfortunately these seemed to synthesize scenarios that are not the case so we are going to use this post as a chance to further describe how UEFI enables secure boot and the options available to PC manufacturers. The most important thing to understand is that we are introducing capabilities that provide a no-compromise approach to security to customers that seek this out while at the same time full and complete control over the PC continues to be available. Tony Mangefeste on our Ecosystem team authored this post. --Steven

 

As this thread from Jan 2013 shows UEFI is still very much in its infancy.

 

http://www.eightforums.com/tutorials/17058-secure-boot-enable-disable-uefi.html

 

On top of that HP makes things very confusing because the UEFI Firmware Settings page is exactly the same as the Legacy Bios page. There is nothing you will see that's any different - the only thing you will notice is some functionality change. Now, you can disable Secure Boot while still using UEFI and it will not switch to Legacy Bios mode by default. This way you are still in UEFI mode with Secure Boot disabled.

 

Hope this helps. HP still does not allow the correct functionality of being able to delete or add your own Secure Boot Keys as is required by Microsoft in the "Windows Hardware Certification Requirements for Client and Server Systems" as mentioned above. Hopefully they will have a bios update to fix this oversight soon.

 

BTW, Here is a closer look at UEFI. UEFI has many great features but it's buggy as **** and lots of those features (even without Secure Boot enabled) can give more problems than it's worth. The code is buggy and there are no good standards to help fix these problems as of yet.

The first half of this tells you the benefits of UEFI and the last tell of it's nightmares. It's clearly not ready as an IO platform yet and Microsoft was dead wrong to insist on OEM's using it.

 

An for an in depth look at UEFI this video gives insight to the workings or not of UEFI.

 

 

At 32 mins and 39 mins and especially 47.5 minutes some very interesting points are raised.

 

It seems from reading all around the subject that Microsoft were indeed trying to lock in hardware to their os but were foiled by a public outcry. Knowing their history they will try again to lock in hardware to their products.

The video points to the spectre of DRM and the horrors this would bring if it were allowed to infiltrate the standard. An even bigger spectre would be if the NSA claimed they needed to interfere because of national security.

 

As I said before this is all about power and loot.

 

[V.T. Eric Layton]

 

I also recommend reading the whole article I posted, and comments.

 

Umm... I second that motion.

[V.T. Eric Layton]

Intense debate... Oh, goody!

[crp]

The ASUS boxes were bare, and the UEFI screens look nothing like the old BIOS screens.

Microsoft already does lock down the OS to their devices, just try to get another OS installed on any Surface.

Are Apple devices locked down to the OS? If so, does that mean when a major release is made that older devices won't be able to do an update but a full blown over-install?

HOWEVER, the enforced lockdown of other OEM's was never in play. What they did and do want , and what other OS should also want, is that when an OS is being put in as a replacement is to have the user provide manual confirmation of what is going on. Since there are quite a few practical problems with this approach it probably won't happen for a while.

[V.T. Eric Layton]