Author Topic: It's official - Linux Foundation Secure Boot System Released (Read 14142 times)

40hz · « **on:** February 08, 2013, 07:24 PM »

Since I'm still getting up to speed on Secure Boot, consider this nothing more than an FYI post.

Linux Foundation Secure Boot System Released
Posted on 8 February 2013 by jejb

As promised, here is the Linux Foundation UEFI secure boot system. This was actually released to us by Microsoft on Wednesday 6 February, but with travel, conferences and meetings I didn’t really get time to validate it all until today. The files are here

PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)

I’ve also put together a mini-USB image that is bootable (just dd it on to any USB key; the image is gpt partitioned, so use the whole disk device). It has an EFI shell where the kernel should be and uses gummiboot to load. You can find it here (md5sum 7971231d133e41dd667a184c255b599f).

To use the mini-USB image, you have to enroll the hashes for loader.efi (in the \EFI\BOOT directory; actually gummiboot) as well as shell.efi (in the top level directory). It also includes a copy of KeyTool.efi which you have to enrol the hash of to run as well.

Read full article and find download links here.

zridling · « **Reply #1 on:** February 09, 2013, 03:58 AM »

Now that MS has both feet in the manufacturing business, it should limit its boot schemes to its own hardware, not the entire PC industry's. I had no problem loading openSUSE last Fall, but I shouldn't even be allowed to buy a UEFI-enabled motherboard when building my own system.
http://freedesktop.o...i/Software/gummiboot

f0dder · « **Reply #2 on:** February 09, 2013, 09:22 AM »

but I shouldn't even be allowed to buy a UEFI-enabled motherboard when building my own system.
-zridling (February 09, 2013, 03:58 AM)

...what?

Josh · « **Reply #3 on:** February 09, 2013, 09:43 AM »

but I shouldn't even be allowed to buy a UEFI-enabled motherboard when building my own system.
-zridling (February 09, 2013, 03:58 AM)
...what?
-f0dder (February 09, 2013, 09:22 AM)

What ^ he ^ said

Renegade · « **Reply #4 on:** February 09, 2013, 11:34 AM »

Can someone distill the implications here? I've got my own take, but it may be skewed as I don't really like being controlled...

40hz · « **Reply #5 on:** February 09, 2013, 01:18 PM »

Can someone distill the implications here? I've got my own take, but it may be skewed as I don't really like being controlled...
-Renegade (February 09, 2013, 11:34 AM)

Distilled and in 25 words or less: I'm afraid your take is likely to be 100% correct.

------------------------

Hmm...Wonder how long it's going to be before somebody innovative (like Gigabyte) introduces a true dual-boot mobo that you can soft switch to boot either via UEFI or traditional BIOS.

f0dder · « **Reply #6 on:** February 09, 2013, 01:49 PM »

Hmm...Wonder how long it's going to be before somebody innovative (like Gigabyte) introduces a true dual-boot mobo that you can soft switch to boot either via UEFI or traditional BIOS.
-40hz (February 09, 2013, 01:18 PM)

"Legacy boot" == BIOS.

They're already there - I doubt you're going to find a retail motherboard without that functionality.

40hz · « **Reply #7 on:** February 09, 2013, 02:20 PM »

They're already there - I doubt you're going to find a retail motherboard without that functionality.
-f0dder (February 09, 2013, 01:49 PM)

I'm interested in one that can more easily toggle between than the current ones seem to be set up to do.

Right now it seems to be handled more like a setting - as in something that doesn't normally get selected each time you fire it up.

Although that may also be because I just haven't seen a mobo that does it that way yet.

Jibz · « **Reply #8 on:** February 09, 2013, 02:57 PM »

I am not sure I quite understood how exactly this works yet, but off the bat it sounds like a compromise such that:

A) Techy people can go through some hoops to continue booting whatever Linux they like on their machine, stopping them complaining

B) Non-techy people have little chance to try anything but Windows on their machine, stopping Microsoft worrying

f0dder · « **Reply #9 on:** February 10, 2013, 01:07 AM »

I'm interested in one that can more easily toggle between than the current ones seem to be set up to do.
-40hz (February 09, 2013, 02:20 PM)

Right, you want it as a boot-time hotkey kinda thing, rather than a flip-flop in the firmware configuration?

Dunno about that - doesn't seem too important to me. If you often need to dualboot between a legacy OS and a secureboot OS, you're probably enough of a power user that you don't need SB, so just turn it off... but OK, we might not be able to legacy-boot Windows in the future. OK, that's a valid concern.

So, why not just shim-secureboot the legacy OS? (Or "real-secureboot" it after installing the right keys in your firmware)? You can leave SB enabled, and boot both whatever-restricted Windows as well as whatever other OS you've installed keys for? Sure, it's more work than now, but it's doable.

As long as Microsoft sticks to the things they've promised, and outlined in their current Windows certification documents. And that ___is___ a big if, IMHO - and I don't take that for granted.

A) Techy people can go through some hoops to continue booting whatever Linux they like on their machine, stopping them complaining
-Jibz

Yup, on x86 anyway - ARM is locked.

And it's not that bad, hoop-wise (for now!). First off, even if you turn off Secure Boot, Win8 will keep booting as happily as it did with SB enabled - you'll just have a bit less system protection. (There's no guarantee that it'll keep behaving this way, though, and one could imagine DRM requiring SB enabled).

Toggling SB on/off depending on booted OS is somewhat annoying if you dualboot and change booted OS a lot. If that's a realy annoyance to you, keep SB enabled, and use a 3rd party SB-signed bootloader (like the Shim I've mentioned a gazillion times by now), and you won't have to disable SB even when booting legacy OSes. You'll be eschewing some safety by not booting a chain of fully trusted drivers, but that's fine with us developer types. And of course there's going to be linuxen around that actually do have a fully verified boot chain.

B) Non-techy people have little chance to try anything but Windows on their machine, stopping Microsoft worrying
-Jibz

People who are brave enough to attempt installing <whatever> alternative OS - or even booting from a LiveCD - should have no trouble doing the additional tiny step of disabling Secure Boot (or trying a linux distro that has a signed bootloader). I really do not see the problems for this usecase.

Once again, however, I'll have to add the disclaimer that this is how things are looking right now, with the current Win8 logo certification guidelines, et cetera ad nauseam. We should all be weary and wary - but at the same time, we should stick to facts.

Renegade · « **Reply #10 on:** February 10, 2013, 01:50 AM »

Can someone distill the implications here? I've got my own take, but it may be skewed as I don't really like being controlled...
-Renegade (February 09, 2013, 11:34 AM)

Distilled and in 25 words or less: I'm afraid your take is likely to be 100% correct.
-40hz (February 09, 2013, 01:18 PM)

Sigh... That is NOT what I really wanted to hear...

I was just hoping that someone who knows more about it than I do would show me that I was wrong.

40hz · « **Reply #11 on:** February 10, 2013, 09:49 AM »

So, why not just shim-secureboot the legacy OS? (Or "real-secureboot" it after installing the right keys in your firmware)? You can leave SB enabled, and boot both whatever-restricted Windows as well as whatever other OS you've installed keys for? Sure, it's more work than now, but it's doable.

As long as Microsoft sticks to the things they've promised, and outlined in their current Windows certification documents. And that ___is___ a big if, IMHO - and I don't take that for granted.
-f0dder (February 10, 2013, 01:07 AM)

Understood. And me neither btw.

But what I am more concerned about is that this so called non-Microsoft non-Windows initiative is about as open as that other famous "open" standard (Java) that somehow never really was because Sun (and now Oracle) insisted on always keeping a very tight rein on it.

To my mind, if some bit of technology is truly "open" as advertised, then you don't have a situation where some animals on the farm are more equal than others like they were in George Orwell's story. But that's exactly what UEFI/SecureBoot is shaping up to be. You have two big players, a few small-time semi-players (who are mostly toadies and hangers-on looking to gain a marketing advantage) - with everybody else in the world being seen as "little people."

***

There's a very interesting analysis over on the BeginLinux blog that looks at UEFI and some of its implications in light of it being embraced to the exclusion of Coreboot - an open standard that provides the advantages of UEFI- but without the cruft - and more importantly, without enthroning Microsoft Corporation as its de facto gatekeeper.

I frequent the Reddit Linux page at reddit.com/r/linux, and I monitor what people have to say about the Free Software Foundation’s campaign against secure boot. The most common complaints that I see are as follows:

Secure boot can be turned off on x86 machines, so why is it a problem?
Why does the FSF complain about secure boot’s lockdown of ARM Windows RT devices when Apple and many Android phones do the exact same thing?

Both are very valid criticisms, so let me address them both. x86 PCs still maintain somewhere around 90% of the global PC market share. In contrast, Apple holds a miniscule share of the desktop PC market. If Apple decides to lock users of Apple computers out from controlling the computer’s firmware, the consumer has a lot of choices outside of Apple. Similarly, some Android phones come with locked bootloaders, but there are a lot of Android phones and tablets that have boot loaders that can be easily unlocked. In fact, any Nexus-branded Android device has an unlockable boot loader, by Google’s mandate. So again, the Android consumer has choices.

On the GNU/Linux side, secure boot will introduce confusion, and a set of two very bad choices. Choice A: secure boot is good technology from a security standpoint, but if I want to use GNU/Linux without being dependent on a Microsoft-signed key, I have to disable it. More on this later. Choice B: I can enable secure boot to get the security benefits, but I will have to depend on a key signed by Microsoft, and they can choose to disable that key at any time. If I make this choice, who is REALLY in control of my PC?

Now back to choice A. Think about who the biggest users of Windows 8 will be be from a revenue standpoint: probably businesses. Businesses usually want to run the most secure option, so they will probably choose to enable secure boot by default. This scenario discourages them from running GNU/Linux, Windows 7 or earlier, or any alternative operating system. I think that this is the whole point. Secure boot pushes the user in the direction of a Windows 8 choice. This is an abuse of market position, and it is anti-competitive. It is also clearly wrong.

The fact that secure boot can be turned off is not a valid counter argument. It demotes the GNU/Linux user to an inferior status: either they have to settle for a crippled system where innate security capabilities of that system are disabled, or they are left in a position of dependency on a Microsoft key. Either scenario is sub-optimal. Right now, Linux has an incredibly good reputation for security. Here is the reputation that Linux will end up getting: “Linux is the operating system that you have to turn off security to install.” This is not an accurate statement, but this is how memes start: non-technical people talking about technical topics. “Turn off secure boot” becomes “turn off security”. “Linux is secure” becomes “Linux is insecure”. Certainty becomes uncertainty. The confidence of being able to install whatever you want to gives way to confusion. This confusion can only be fully resolved by sticking to one dominant vendor [4].

If security was really the primary concern when the need to replace BIOS was being investigated, then coreboot was available, it was free, and it was open source. Why in the world would anyone have thought that UEFI/secure boot was a better solution? I’d like you to please give this question more thought AFTER you read Table 1 below.
.
.
.

Read the rest of the article here.

Those not familiar with Coreboot who wish to learn more about it (or bootloaders in general) can check out this uber-geek video presentation which goes into it in depth. Wikipedia also has a decent summary article on it here.

ABSTRACT

Coreboot, formerly known as LinuxBIOS, was originally started in 1999 to complement LOBOS [2] (Linux OS Boots OS) as part of an effort to move away from inscrutible and inflexible proprietary BIOS firmware used in clusters at high-security government research labs. However, coreboot took on a life of its own and quickly overcame many obstacles thanks to the help of a friendly and knowledgable open source community. This talk will give an overview of coreboot, what it is capable of, what it is incapable of, and what makes it different from the traditional PC BIOS and EFI. We'll focus on developments in version 3 which cleans up the development model substantially, has much improved ACPI and SMI support, usage of the Linux kernel build system to build coreboot, new ways to boot locally and over a network, do some demos, and more!

This project is still active despite being widely unknown to most Linux desktop users. Hopefully, with the advent of UEFI/SecureBoot, it will gain significantly more exposure and presence in the coming year.

Renegade · « **Reply #12 on:** February 10, 2013, 10:13 AM »

@40hz - Thanks for that. I'll watch the video after it downloads and I have time.

f0dder · « **Reply #13 on:** February 10, 2013, 10:35 AM »

On the GNU/Linux side, secure boot will introduce confusion, and a set of two very bad choices. Choice A: secure boot is good technology from a security standpoint, but if I want to use GNU/Linux without being dependent on a Microsoft-signed key, I have to disable it.
-40hz (February 10, 2013, 09:49 AM)

...or enroll your own key in the firmware.

40hz · « **Reply #14 on:** February 10, 2013, 01:58 PM »

On the GNU/Linux side, secure boot will introduce confusion, and a set of two very bad choices. Choice A: secure boot is good technology from a security standpoint, but if I want to use GNU/Linux without being dependent on a Microsoft-signed key, I have to disable it.
-40hz (February 10, 2013, 09:49 AM)
...or enroll your own key in the firmware.

-f0dder (February 10, 2013, 10:35 AM)

@f0dder - Sure. But lets forget for a moment that the vast majority of PC users must easily know as much about computer systems and programming as you do.

Lets think for a minute about the the tiny minority who just know enough to boot the thing and use it...(kidding!)

See what I'm saying? I'm still confused about some of this and I'm not exactly an amateur when it comes to either Linux or Windows. And you would probably blow my doors off on most of this when it comes to the real hardcore tech - yet even you still have questions.

No big deal? We can work around it? Yeah. We can - and probably will - so all's well and fine.

But that's us.

Microsoft and all the other participants in the "fence in the platform" crowd don't care about us. They're targeting the millions with their new vision. They don't need to worry about the likes of us because we can only use what they make. And if they get to make things the way they want, there will no longer be a platform you can truly make your own.

In many respects it will become much like the old phone systems. One legal provider. One type of service. One manufacturer. With the customer free to do anything they want - provided it's sanctioned by and purchased from those who have been authorized to provide it.

And once that happens, innovation will die because they'll use paranoia and ignorance to have governments outlaw anything that deviates from their model. All in the name of "security," "anti-terrorism" and "legal use."

It used to be a criminal offense in the US to plug any device into the phone system that wasn't manufactured by the phone system. And the US phone system remained a study in archaic 30s technology until that ban was lifted. In very short order we got touch tone dialing, a huge number of telephone styles with all sorts of features, lower costs, direct long distance service, and all the rest when 'Ma Bell' no longer had a stranglehold on US telecommunications.

But that never would have happened if the Bell System continued to be allowed to hold back technology and innovation in order to milk as much revenue as possible out of what they already had. You see it today with data caps on bandwidth. A few entrenched suppliers with monopolies continue to prop up an old revenue model that makes no sense with what we have today.

I once heard a phone company person admit that it probably cost his company more to monitor telephone use and bill for it than it would for them to just charge everybody a flat monthly fee per demarc point and allow unlimited use.

When I asked him why they didn't, he said it was because the government would prefer that they didn't. Apparently my government relies very heavily on the surveillance and monitoring possibilities that a detailed phone bill can provide. And in the USA, they don't need a warrant to look at one.

So there are bigger factors at play behind some of this direction the new PC design is going in... And it's not mere paranoia or "FUD swallowing" should you start noticing it...

Josh · « **Reply #15 on:** February 10, 2013, 02:19 PM »

OK, so I am coming into this cold but.....What exactly is Microsoft's role in UEFI? From what I am reading, it sounds like the UEFI has been around for a while and that the standard has been known...It sounds like Microsoft is requiring UEFI be turned on by default to have the "Windows 8 certified" logo applied. Now, since most users will not care to install anything else, I fail to see this becoming a problem. For those who are more tech saavy and want to install an alternative OS on the system, the issue will have to be known that they are buying a "Windows 8 certified" system, and as such, will have to load a private key into the firmware to install an alternative OS. It does not seem that this is intended to lock users in, but instead serve as a way to progress forward past the traditional bios.

In the end, I think techy users will still be able to do what we do, and regulars users will still be able to do what they do. Is there more to the story that I am missing? I fail to see the issue here...It sounds like Microsoft is forcing the alternative OSes (read: Linux) to progress forward...Yes, there is coreboot, but like Linux, there are dozens of alternatives to every one solution that is attempted to be setup as a "standard". I guess that is one of the problems of having such a diverse system.

40hz · « **Reply #16 on:** February 10, 2013, 03:12 PM »

@Josh - Microsoft is not doing anything to make Linux "progress" forward. There's been serious discussion in the Linux world to go beyond BIOS for some years now. And several initiatives have been proposed, the best of which was coreboot. Coreboot can do what UEFI/SecureBoot does. And it's been around longer.

The big difference is that coreboot is a true open standard whereas UEFI is not. UEFI's board is composed of nine of the the most closed-system oriented businesses out there. And, with the exception of Apple (who is also on the board) all are exceedingly Windows friendly. There is NO open software representation anywhere on the board. A curious omission when you consider the huge number of servers running Linux - as well as the slow but steady growth of Linux desktops in municipal government circles.

The other problem is, because of its size, Microsoft and Microsoft signed keys are currently the only viable way of dealing with SecureBoot for the vast majority of PC users. And while the key signing process is supposed to be fair and open to all, Microsoft has introduced several unnecessary hoops you'll need to go through to get one if you don't use Microsoft software.

There's a write up here about why RedHat compromised and went along with what was required to obtain a Microsoft signed key.

In the wake of criticism and the potential for legal actions, Microsoft has since "clarified" (as in backed off on some of the hints and insinuations) of what was causing concern in the above article. I'll leave it to others to argue about whether that partial "clarification" was - or wasn't - in response to some of the pushback being felt.

But that is of no consequence to the rest of the article which explains why, from an average end-user experience perspective, most OS creators will be virtually forced to go along and do it Microsoft's way.

And considering what the Linux Foundation recently went through to get theirs, it doesn't seem like Microsoft is about to back down any on that score.

Microsoft's official role in UEFI is that it sits on the board. But if you're asking what Microsoft's functional role is - they're the 800-pound gorilla in the room that's currently calling most of the shots.

f0dder · « **Reply #17 on:** February 10, 2013, 05:24 PM »

What exactly is Microsoft's role in UEFI? From what I am reading, it sounds like the UEFI has been around for a while and that the standard has been known...
-Josh (February 10, 2013, 02:19 PM)

Right, so...

It all started with EFI, which was Intel's replacement for BIOS for their Itanium systems back in the late nineties. This was later involved into UEFI, and while the EFI spec is owned eclusively by Intel, the UEFI spec is handled by a cartel of the big boys. To give a hint at how important Microsoft is in that group, consider the fact that the executable format chosen is Microsoft Portable Executable (i.e., the format of Windows .exe and .dll files).

It sounds like Microsoft is requiring UEFI be turned on by default to have the "Windows 8 certified" logo applied.
-Josh (February 10, 2013, 02:19 PM)

You can do UEFI without Secure Boot; but in order for vendors to get the Win8 certified logo, they have to enable Secure Boot. With Microsoft's master key. The implicaitons of this has been discussed to death in other threads, and there's craploads of FUD around. But even when ignoring the FUD and sticking to facts, this is problematic.

In the end, I think techy users will still be able to do what we do, and regulars users will still be able to do what they do. Is there more to the story that I am missing?
-Josh (February 10, 2013, 02:19 PM)

While Win8 cert requires that the end-user can disable Secure Boot (iirc it doesn't require that the UEFI has key management, just that you can turn off SB...), there's no guarantee that this will continue to be a requirement on Win9 or Win10 or a bit further down the road. Good ol' slippery slope... and I honestly don't have a lot of faith in Microsoft. Yes, they'd probably end up with antitrust lawsuits if they tried to pull that stunt, but they could do a lot of damage to the PC ecosystem before those suits are settled.

See what I'm saying? I'm still confused about some of this and I'm not exactly an amateur when it comes to either Linux or Windows. And you would probably blow my doors off on most of this when it comes to the real hardcore tech - yet even you still have questions.
-40hz (February 10, 2013, 01:58 PM)

How many "regular users" installs Linux by themselves? I honestly don't see key enrollment as a problem - and it's only necessary if you don't want the current compromise of bootloaders signed by Microsoft (which I do find somewhat problematic, it's too much power in the hands of a non-neutral party).

What I do find problematic is the "tiny little detail" about key management features not being mandatory. Haven't seen any prebuilt "ready for windows 8" systems, so I don't know what the status of their UEFI setups are - can only comment on my own motherboards, which do offer the full key management bonanza. (I think large parts of UEFI implementations are going to be the Intel UEFI Standard Base, so at least key management UI might have some de facto standard

).

So there are bigger factors at play behind some of this direction the new PC design is going in... And it's not mere paranoia or "FUD swallowing" should you start noticing it...
-40hz (February 10, 2013, 01:58 PM)

Oh, I agree about that - as I've stated multiple times, I'm wary & weary.

I just feel that a fair amount of people on the interwebs either focus on things that are non-issues, or simply spread FUD... which isn't very helpful. And it's kinda silly, since there's enough pretty problematic stuff even if you stick with the facts.

Edvard · « **Reply #18 on:** February 10, 2013, 05:29 PM »

...or enroll your own key in the firmware.
-f0dder (February 10, 2013, 10:35 AM)

So, you're saying we can make up our own key and plug it in? It can't be that simple, this would have been over by now...

f0dder · « **Reply #19 on:** February 10, 2013, 05:43 PM »

So, you're saying we can make up our own key and plug it in? It can't be that simple, this would have been over by now...
-Edvard (February 10, 2013, 05:29 PM)

Well, it isn't that simple - for a couple of reasons.

1) there's no guarantee the all UEFIs will provide key management; for Win8 cert it's only a requirement that SecureBoot can be turned off. (Or, well, see the somewhat muddy quote below).
2) there's no guarantee certification for future Windows versions will require this flexibility... although dropping it would probably result in antitrust, even if MS tries to pull a "it's up to the OEMs".
3) UEFI tooling (the bootloaders as well as all the signing stuff) is still very early days - and there's buggy UEFI implementations out there (*cough* Samsung *cough*).

There's a bit more information in this post, including link to the Windows 8 certification requirements.

page 121, section 17.a:
It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
-Windows 8 System Requirements

40hz · « **Reply #20 on:** February 10, 2013, 08:15 PM »

they'd probably end up with antitrust lawsuits if they tried to pull that stunt,
-f0dder (February 10, 2013, 05:24 PM)

Maybe in the EU, but probably not in the US. At least not as easily. Because GNU/Linux is, of itself, not a business or commercial product. So if Windows is unfairly "competing" with Tux, what exactly is it competing against? Something that's free and can be acquired by anybody just for the asking? And in most cases at no out of pocket? What competitor's business is being harmed?

What business is being hurt? Some PC vendor that wants to put Linux on their machines? Why not Windows? That's a commercial product that this same vendor can get from Microsoft under the same terms any other PC vendor can. Sure there will be breaks for volume purchases - but there's nothing illegal about that. Discounts are an accepted part of business as long as they're not offered as a form of favoritism.

And requiring some specific UEFI setting in order to load or run Windows is no different really than requiring a certain level of CPU, graphics subsystem, or RAM complement to run something. Or needing .NET or a similar runtime like JRE.

As long as UEFI can be disabled (with all that implies) - and the hardware supplier controls how and if it can be done - Microsoft has 'plausible deniabilty.' And that would force a plaintiff to argue something was an "effective" monopolistic behavior or practice as opposed to an actual one. That's extremely hard to prove. Especially in a legal system like the US has where the "letter of the law' generally prevails even when it's pushed to logical extremes. Because, in the US, anything not specifically prohibited by law is generally deemed to be 'legal' by default. With us, unless you've been told you can't - you can.

So I don't see there's anything here that a US antitrust complaint can be directly based on. It would require extrapolation. And that's a tough sell.