The small piece of code will be able to pass control to any operating system.

Microsoft is demanding that systems with the "Designed for Windows 8" badge include a UEFI firmware feature called "Secure Boot" that will only boot software that has been signed with a particular cryptographic certificate. Although Microsoft's stipulations require also that x86/x64 systems provide an option to disable Secure Boot, Linux users are concerned that this will make it harder for them to boot non-Microsoft operating systems.

The Linux Foundation has announced plans to provide a general purpose solution suitable for use by Linux and other non-Microsoft operating systems. The group has produced a minimal bootloader that won't boot any operating system directly. Instead, it will transfer control to any other bootloader—signed or unsigned—so that that can boot an operating system.

On the face of it, this bootloader could be used to circumvent the security of Secure Boot. The entire point of Secure Boot is that it doesn't allow unsigned (and potentially malicious) code to be run before the operating system is started. To address this, the Linux Foundation bootloader will present its own splash screen and require user input before it actually boots. In this way, it can't be silently installed and used to hand control to a rootkit without the user's knowledge.

The Linux Foundation's bootloader is not the only solution for the Secure Boot conundrum. Technically skilled users will be able to add their own trusted certificates to the computer's firmware, and some major Linux distributions including Fedora, SUSE, and Ubuntu intend to provide their own solution to the problem.

However, the Linux Foundation's work is still useful, as it provides a solution that will be suitable for minor distributions, those unable or unwilling to acquire a signature for their bootloader, and anyone developing their own boot system.

51 Reader Comments

From the article:To address this, the Linux Foundation bootloader will present its own splash screen and require user input before it actually boots

That makes about as much sense as leaving the "Keyboard Error: Press F1 to continue" BIOS crap enabled on a whole range of machines. What about servers, or even desktop/workstation systems that are expected to boot/reboot unattended for whatever reason?

If this really is intended as a defence against non-implementation of the secure boot disable feature, it's creating another major problem right there...

From the article:To address this, the Linux Foundation bootloader will present its own splash screen and require user input before it actually boots

That makes about as much sense as leaving the "Keyboard Error: Press F1 to continue" BIOS crap enabled on a whole range of machines. What about servers, or even desktop/workstation systems that are expected to boot/reboot unattended for whatever reason?.

For those types of machines, you can disable Secure Boot. For everyone else, there's this. It's meant to just be a solution you can use OOTB without any configuration.

If this really is intended as a defence against non-implementation of the secure boot disable feature, it's creating another major problem right there...

It allows smaller distros that might not have the resources to deal with the signing process to interoperate with systems that might be in secure boot mode rather than failing in some undefined manner (silently, big warning messages, etc.)

If you're going to need the ability to do an unattended reboot then you'll either handle the signature somehow, disable it, or have some means of dealing with it. I still consider the whole situation suboptimal and biased, but this is at least a step in the right direction.

From the article:To address this, the Linux Foundation bootloader will present its own splash screen and require user input before it actually boots

That makes about as much sense as leaving the "Keyboard Error: Press F1 to continue" BIOS crap enabled on a whole range of machines. What about servers, or even desktop/workstation systems that are expected to boot/reboot unattended for whatever reason?

If this really is intended as a defence against non-implementation of the secure boot disable feature, it's creating another major problem right there...

My question was whether or not it required input every time it booted. If it requires manual intervention once, then just boots (with a splashscreen or not, whatever) after that, it's no big deal IMO. An extra few seconds when provisioning a server.

The problem in my mind was never the x86/x64 market. The problem was the ARM market, which could grow quite large. Before these solutions, Microsoft had effectively locked all Windows 8 ARM devices to only WIndows 8. And considering how hard it is even today to get most laptops without Windows at all, it was a serious detriment to the Linux ARM platform. Hopefully this will solve that problem as well.

My question was whether or not it required input every time it booted. If it requires manual intervention once, then just boots (with a splashscreen or not, whatever) after that, it's no big deal IMO. An extra few seconds when provisioning a server.

Yes, the Linux Foundation approach requires input every time you boot unless you manually transition the system to Setup Mode first. That's a process that differs depending on your motherboard, so it's awkward to document. The MOK approach that Suse came up with allows major distributions to avoid any additional steps, and smaller distributions to have a one-off manual intervention. I'd recommend that distributions adopt that instead.

The problem in my mind was never the x86/x64 market. The problem was the ARM market, which could grow quite large. Before these solutions, Microsoft had effectively locked all Windows 8 ARM devices to only WIndows 8. And considering how hard it is even today to get most laptops without Windows at all, it was a serious detriment to the Linux ARM platform. Hopefully this will solve that problem as well.

The ARM market is not a PC market right now. It's an integrated device market dominated by dedicated SoC designs, each device built and tuned specifically for the software running on top of it. The iPad, Playbook, and even most Android tablets right now do not allow for easy access to the loader and replacement of the OS, so this is no different. Microsoft does not sell Windows for ARM anywhere, it licenses it to OEMs who design devices around it. Only a handful even have access to it right now. It's just not apples-to-apples with x86/x64, which is protected by requirements to allow SecureBoot to be disabled.

Their stipulations require that ARM systems do NOT provide an option to disable Secure Boot. So this is very important for non x86-family systems.

This solution doesn't necessarily help on ARM. The signing key that Microsoft use for signing third party bootloaders or option ROMs isn't the same as the one they use for signing Windows. On x86 you're pretty much guaranteed to have that second key, because otherwise you'd never be able to swap your graphics card. It's less likely to be true on ARM. So even if you have a signed UEFI bytecode bootloader that'll run on x86 or ARM, any Windows RT devices may still refuse to boot it because they don't carry that key.

Can someone with knowledge explain to me how you would install your own custom certificates? Could there be a way to have that be something done on the liveUSB or is there no way to do this outside of booting into the BIOS and manually making the changes?

Can someone with knowledge explain to me how you would install your own custom certificates? Could there be a way to have that be something done on the liveUSB or is there no way to do this outside of booting into the BIOS and manually making the changes?

With the Linux Foundation approach you either need to enter your firmware and enrol the keys by hand (and different machines require the keys to be in different formats...), or enter your firmware and reset it to Setup Mode, then let the bootloader enrol new keys. The way to do that will vary between machines, so it's a pain to document. The Suse approach (now being used by Fedora, and likely to be adopted by Ubuntu) lets you add new certificates in the bootloader - either in the bootloader directly, or by registering a new certificate in the OS and rebooting into the bootloader.

I'm still confused by this. Part of MS' directive regarding Secure Boot is that it can be turned off. Why is this still such a big fucking deal? Want to fight the eeeevil tyranny of Steve Ballmer? Turn it off

I'm still confused by this. Part of MS' directive regarding Secure Boot is that it can be turned off. Why is this still such a big fucking deal? Want to fight the eeeevil tyranny of Steve Ballmer? Turn it off

Once again for clarity:

On x86 it is mandatory that it can be turned off.On ARM it is mandatory that it cannot be turned off.

This solution doesn't necessarily help on ARM. The signing key that Microsoft use for signing third party bootloaders or option ROMs isn't the same as the one they use for signing Windows. On x86 you're pretty much guaranteed to have that second key, because otherwise you'd never be able to swap your graphics card. It's less likely to be true on ARM. So even if you have a signed UEFI bytecode bootloader that'll run on x86 or ARM, any Windows RT devices may still refuse to boot it because they don't carry that key.

Can you cite some guidelines for this? AFAICT from my reading of the guidelines, the only key that ARM devices can and must contain in the db is the same that is the only key that Windows 8 boot mgr can require. I.e. isn't that the key that will sign {the key that will sign}* this LF bootloader?

I can't say I disagree with MS's requirement of Secure UEFI, given the vulnerabilities that plague the BIOS boot process. Also, I note that this is not mandatory for *all* x86 systems, but only if they want to have a "Designed for Windows" sticker. Finally, they leave room for alternatives, as stated by Lemurs above.

Maybe with this solution from the Linux foundation we'll actually see tablets dual-booting Win8 and some x86 flavour of Android? I'd LOVE an x86 ASUS Transformer Prime-like tabet running both OSs

As for WinRT... Well, I can't say anyone's doing anything different there, are they? Apple doesn't let you run other OSs on you iPad, and Android vendors also block their bootloaders as securely as they can, leaving custom ROMs only to those willing to root their gadgets...

What problem does the secure boot loader solve other than the problem of competition? Is malware that infects the system at that level really prevalent enough to warrant this or is it a solution in search of a problem? I don't really understand why this direction is being taken other than to make it harder to boot alternative operating systems.

the secure boot has already been bypassed before window 8 has even come out to the public so the secure boot only protects from old rootkits only

ARM version is what needs targeting so that Linux can run on that (as you currently can't disable secure boot on ARM)

Drivers are the issue on ARM that limit what you can do on them why there are no Linux for iPad, same thing happens with custom roms Lack of GPU drivers is an issue no HW gpu so gets laggy (moto not updating phones that should support ICS or higher but custom roms lack HW GPU drivers so better staying on 2.3)

What problem does the secure boot loader solve other than the problem of competition? Is malware that infects the system at that level really prevalent enough to warrant this...?

Yes,as a matter of factit is. The infection rate is relatively low right now, and I think we'd all prefer to keep it that way since the only real solution to cleanup this type of infection is to nuke it from orbit. In this case, an ounce of prevention is worth a couple dozen kilotons of cure.

EDIT: That said, Microsoft probably finds that obstructing the installation of operating systems which are now viable competition to theirs is a very convenient side effect.

There is no reason why Linux should be treated as a second-rate boot experience. Besides if Linux ever catches on, everyone will be accustomed to booting with this "nag" screen so much so that the point of having the nag screen eats itself. "Oh that's the linux nag screen" will be used by rootkits. The problem is you can't boot the boot and see what will actually be booted. If it could examine the kernel to be booted and present the signer for that kernel, then that would be usefull information. About to boot kernel "Linux-3.2 signed by Canonical Inc" would be good enough. In fact any signed kernel would be adequate for auto-boot. Then the only hazard is when the kernel is not signed because virus writers won't ever present enough information to authorities to sign a kernel.

I don't know if this is a veiled attempt at shooting secure boot in the foot, or an unveiled one. The fact that this can be done at all shows secure boot is not secure, it is just about giving Linux a second-rate boot experience.

If there is "user intervention required" then this kills linux in server farms.

the secure boot has already been bypassed before window 8 has even come out to the public so the secure boot only protects from old rootkits only

ARM version is what needs targeting so that Linux can run on that (as you currently can't disable secure boot on ARM)

Drivers are the issue on ARM that limit what you can do on them why there are no Linux for iPad, same thing happens with custom roms Lack of GPU drivers is an issue no HW gpu so gets laggy (moto not updating phones that should support ICS or higher but custom roms lack HW GPU drivers so better staying on 2.3)

I've only seen it claimed a few times that Secure Boot has been circumvented and all of those times it was just hyped up headlines with nothing to back them up.

There is no reason why Linux should be treated as a second-rate boot experience. Besides if Linux ever catches on, everyone will be accustomed to booting with this "nag" screen so much so that the point of having the nag screen eats itself. "Oh that's the linux nag screen" will be used by rootkits. The problem is you can't boot the boot and see what will actually be booted. If it could examine the kernel to be booted and present the signer for that kernel, then that would be usefull information. About to boot kernel "Linux-3.2 signed by Canonical Inc" would be good enough. In fact any signed kernel would be adequate for auto-boot. Then the only hazard is when the kernel is not signed because virus writers won't ever present enough information to authorities to sign a kernel.

The worry isn't that a signed Linux boot loader will be used to boot into rooted Linux... it's that a signed Linux bootloader would be used to boot into a rooted Windows machine. While Linux users too stupid to disable secure boot will get used to the "Linux nag screen," Windows users won't. So when they boot to the Linux nag screen, they'll see something is up. If the bootloader allowed silent and non-interactive booting, it would almost certainly be subverted to run malicious code on the Windows machines most desktop users run, and would soon thereafter be blacklisted. If someone is going to bother getting a Linux bootloader signed, it needs to be secure.

Frankly, given the unlikelihood of someone targeting any given Linux version with a root kit, I think having secure boot enable for Linux isn't all that helpful. So I think the best signed Linux boot loader would be a program that simply prints instructions to go into the BIOS and disable secure boot when it's enabled, and is silent when it's not, so that the real OS can boot unencumbered.

Can you cite some guidelines for this? AFAICT from my reading of the guidelines, the only key that ARM devices can and must contain in the db is the same that is the only key that Windows 8 boot mgr can require

Yes.

Quote:

I.e. isn't that the key that will sign {the key that will sign}* this LF bootloader?

No. The key used for signing 3rd party code does not chain to the key that the hwcert requirements insist be present in the firmware. Practically speaking it *will* be [resent on x86 because otherwise plug-in hardware won't work, but ARM has different design constraints and so may not carry it.

What problem does the secure boot loader solve other than the problem of competition? Is malware that infects the system at that level really prevalent enough to warrant this or is it a solution in search of a problem?

Take a look at the technical writeups for TDSS/Pihar, and the (old version of) ZeroAccess. There are some very skilled criminals working on these things, if there's a way to subvert secure boot they will figure it out.

TDSS is very wide spread, it's the most common malware I deal with every week.

I'm still confused by this. Part of MS' directive regarding Secure Boot is that it can be turned off. Why is this still such a big fucking deal? Want to fight the eeeevil tyranny of Steve Ballmer? Turn it off

You haven't been watching Microsoft for very long have you? They usually do a watered-down version first to get in through the door. The next x86 version may not have the option to turn it off and by then it's entrenched.

Is malware that infects the system at that level really prevalent enough to warrant this...?

Quote:

Yes, as a matter of fact it is. The infection rate is relatively low right now,

Quote:

That said, Microsoft probably finds that obstructing the installation of operating systems which are now viable competition to theirs is a very convenient side effect.

True enough. Or, alternatively, preventing malware is a convenient side effect and Trojan Horse for their obstructing the installation of operating systems which are now a viable competition to theirs.

Note: There's no reason to believe that Microsoft is not as concerned about Mac OS on generic PC (or more concerned) than they are Linux. Apple doesn't distribute Mac OS right now, but they certainly could. Microsoft's general approach is to protect Windows at all costs.

To be perfectly frank, speaking as a Linux users, so what? Any designed for Win 8 ARM machine is nothing but a disposable appliance, with the hardware and software closely integrated.

In the x86 space, I can see where this could be a play against alternative OSs if it couldn't be disabled, but it can. And really, if you're so uncomfortable messing with the BIOS settings, then if you use an alternative OS at all, it should be one of the big name ones that already has a solution in place.

Consider say, an iPad or a Kindle or a Nexus. Do really think people are going to be loading other OSs on them, even if it was possible? I mean sure, you might have a tiny faction of people who might load something other then iOS on their iPad ... but what's the point? The hardware is just a disposable way to run the OS you want. Want Linux? Go android. Buy the hardware that comes with the OS you like, because you're buying a package, not a computer.

I'm still confused by this. Part of MS' directive regarding Secure Boot is that it can be turned off. Why is this still such a big fucking deal? Want to fight the eeeevil tyranny of Steve Ballmer? Turn it off

You haven't been watching Microsoft for very long have you? They usually do a watered-down version first to get in through the door. The next x86 version may not have the option to turn it off and by then it's entrenched.

FUD much?

Maybe you should read-up on how Secure Boot works. It's up the hardware manufacturers, not Microsoft. For x86 they only need to have Secure Boot as an option (which must be disablable) in order to have the Windows Logo, they don't have Secure Boot at all, they simple don't get the logo on their hardware (and who really cares).

Microsoft can't force the hardware manufacturer to enable Secure Boot. If Windows only ran on Secure Boot enabled hardware, then all of the computers being sold up to now would not be able to run it, which means massive losses in sales, as no one would be able to upgrade; they'd need to buy new computers. And then there'd be anti-trust concerns... so they'd be shooting themselves in the foot, and then inviting the government to shoot them in the other foot.

I don't believe that this is some giant conspiracy to shut down alternative OSs on x86. Why? Because it's just not worth the trouble. The only desktop\laptop OS competitor MS is worried about is Apple. Linux on the desktop never happened in any number worth mentioning, and it'll never happen in the future either, especially now that desktop\laptops are on the decline.

Now, I run a Linux desktop (Debian) and I've run other *nixes as my desktop as well (Solaris, IRIX) so it's not like I'm some windows fan, or Linux hater, but the truth of that matter is joe six pack isn't going to download and run a distro, no matter how polished it is. Sure, it happens to some extent with geeks that set it up for their friends or family ... but that's a tiny percentage that's not even on MS's radar.

Linux is doing well server side, desktop side? Not so much. And that's why secure boot doesn't exist for the purpose of hindering alternative OSs.

I'm still confused by this. Part of MS' directive regarding Secure Boot is that it can be turned off. Why is this still such a big fucking deal? Want to fight the eeeevil tyranny of Steve Ballmer? Turn it off

You haven't been watching Microsoft for very long have you? They usually do a watered-down version first to get in through the door. The next x86 version may not have the option to turn it off and by then it's entrenched.

The day a computer being sold does does what you're saying, is the day enterprise customer stop purchasing that computer.

Custom boot is a REQUIREMENT of enterprise. You know, that multi-billion dollar market.....

Can't wait until Linux users understand that this involves the LF "playing ball" with secure boot in UEFI, i.e. supporting "digital restrictions management". And yet when no one dies because of it, they'll be crying over the bodies.