Linux Foundation Offers Solution for UEFI Secure Boot

Ever since news broke last year that Microsoft would require Windows 8 machines to have UEFI secure boot enabled, there were concerns that it would be used to block the installation of other operating systems, such as Linux distributions. Now, reader dgharmon sends this quote from Ars Technica about a new defense against that outcome: "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 can boot an operating system." The announcement adds, "The pre-bootloader will employ a 'present user'; test to ensure that it cannot be used as a vector for any type of UEFI malware to target secure systems. This pre-bootloader can be used either to boot a CD/DVD installer or LiveCD distribution or even boot an installed operating system in secure mode for any distribution that chooses to use it."

Comments

So why even bother with secure boot

[Anonymous Coward]

As per subject

Re:So why even bother with secure boot

[GameboyRMH]

Exactly. Malware authors can use this. So we've come full-circle and only gained a big heap of complexity. Which is the best we could hope for once this idiotic idea got going.

Re:So why even bother with secure boot

[Joce640k]

Exactly. Malware authors can use this.

Not if everything in the startup chain has to be correctly signed ... something which a malware author can't do.

Re:So why even bother with secure boot

[GameboyRMH]

They didn't seem to have any problem setting up boot sector viruses without UEFI secure boot, so if they can get a signed bootloader, why should they now? And signing the startup chain will remove even MORE user freedoms, it's a chicken-and-egg problem that won't end until the OS is at least as locked down as iOS.

Re:So why even bother with secure boot

[Just Brew It!]

RTFA. I think you'd notice if your Windows PC suddenly started displaying a Linux Foundation splash screen and waiting for you to hit Enter before booting the OS.

Re:So why even bother with secure boot

[GameboyRMH]

And what will the average noob user do? Hit Enter to use their computer or use a Windows recovery disk* to fix the bootloader? And if they do hit Enter and the computer apparently works fine, what do you think they'll do then?

*Not sold with many PCs, must be burned from the hard disk

Re:So why even bother with secure boot

[smittyoneeach]

If you've got a closed system of bits, then enough time, hardware, and interest should yield a way to jailbreak it.
So the real value would seem to be found in upping the time, hardware, and interest requirements.
What could well happen is that, in making Windows really painful to integrate with other systems, Redmond kills their sales.
And wouldn't that just suck Puget Sound dry?

Re:So why even bother with secure boot

[BLKMGK]

Not exactly, it was signed with a weak key produced by one of their remote desktop solutions that allowed licensing of components. Microsoft has since revoked those keys and bumped up the minimum allowed key size to stop this in the future. This was NOT a case of someone stealing a Microsoft key left in the parking lot.....

Re:So why even bother with secure boot

[just_another_sean]

Become a Linux user?

Re:So why even bother with secure boot

[bmo]

Because secure boot has never been about securely booting.

--
BMO

Re:So why even bother with secure boot

[Hatta]

And I'd be really fucking pissed off if my Linux PC required a user present at the console to reboot. Seriously, how is this a fix?

Re:So why even bother with secure boot

[Miamicanes]

>and still find a way to keep the code signed?

With a certificate bearing the same CN as the original? Low, as long as the bootloader realizes that it's never seen anything signed by s0m3hack3r@foo.to, and presents the user with a dialog that says something like, "You have never booted an OS signed by s0m3hack3r@foo.to, and foo.to is not recognized as a known OSS Organization. Click here to boot into your computer's mini-distro and perform an automated legitimacy lookup (internet access required), or (... options that include 'continue if you trust them' and 'cancel'...)

For a side trip, boot into a mini Linux burned into flash that can grab an ip via dhcp or connect to wifi with ssid/key stored in flash or entered now & wget a lookup of the CN from the UEFI bootloader's organization. Known malware CNs would be blacklisted & identified as such, others could be further researched using Lynx before either continuing the boot (optionally remembering the CN for future boots) or aborting.

Re:So why even bother with secure boot

[TheGratefulNet]

"system error: secure keyboard not found. hit any key to continue."

(that was sort of a real error message back in the DOS days. all except the secure part.)

Re:So why even bother with secure boot

[spike hay]

The average computer user is not going to be monkeying around in the BIOS. This is about making life more difficult for non-MS OSes, and reverting the mistake that was the open x86 platform.

Re:So why even bother with secure boot

[recoiledsnake]

Here we go with the hyperbolics without even RTFA'ing. You can choose to install the key in the store when UEFI is in setup mode so that you don't see the prompt again.

http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-source

Or just fricking turn off secure boot.

Re:So why even bother with secure boot

[DRJlaw]

And I'd be really fucking pissed off if my Linux PC required a user present at the console to reboot. Seriously, how is this a fix?

Because it is a fix for those who cannot or will not use the alternative of entering their own list of acceptable signing keys into the UEFI, which would not require a user present but draws a great hue and cry that it is "too complex" for the average Linux user to accomplish.

1. Enter your keys into the UEFI key list, walk away; or
2. Have a user present to acknowledge that they want to boot unsigned/signed-but-not-entered code; or
3. Don't use a UEFI PC; but not
4. Prevent the rest of the world from having access to a secure boot chain because you refuse to lift a finger yourself

Re:So why even bother with secure boot

[mystikkman]

Do you really think that the makers of an operating system which requires 3rd party AV to correct its own security shortcomings devised secure boot to protect users from malware?

You mean the Linux folks designed UEFI Secure boot?

http://www.rootkit.nl/projects/rootkit_hunter.html

I repeat it again, If you want to secure the bios put a jumper before the write pin of the eprom/flash memory/whatever. Those who can't open the case and locate it are surely not qualified for a bios upgrade.
I made one firmware upgrade in the last 15 years on my machines, and that upgrade was necessary only if I wanted 64bit linux.

Secure boot is not about the BIOS, it is about bootkits. You don't know what you're talking about and still get modded +4 interesting, typical Slashdot, really. See below for an example.

TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

Another bit:

The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.

Re:So why even bother with secure boot

[Cajun Hell]

Take it easy dude. Let's try to remember what this whole thing is for.

For all the bitching about secureboot, all currently known (yes, this can change) x86 machines which come with it, allow the user to turn it off. Remember the last 4 times you bought a new computer and, in fact, did diddle with stuff in the firmware, maybe to at least check the timings on your expensive Mushkin memory or whatever? Well, then, this whole article and the software it describes, isn't about you because you're going to turn off secure boot, making every aspect fo this boot loader irrelevant. You won't care about pressing enter, because you won't have to press enter.

This is for users who won't do that. This is for people who are dumber or lazier than your grandma's ditzy bridge partner, for which we do not expect them to follow any directions or do anything "extra" prior to using their computer. They're not installing headless servers. They're not "picky" except in the sense that they don't want to have to read or understand anything longer than one sentence. They can, and will, press enter.

The people who are opinionated enough to be "pretty fucking pissed" about pressing enter, will also tend to care enough to do what is needed in order to make pressing enter become unnecessary.

If there are any people left who become furious about pressing enter, but also feel entitled enough to refuse to turn off secureboot, but also feel entitled enough to refuse to install some other secureboot loader, those people can and should go fuck themselves. Or they can go buy a Mac. Or they can boot Windows, and (think about it) they will never notice that they're not running Linux. Just lie to them and tell them Windows 8 is Linux, and they will believe you, and the lie will never have any consequences because behind the blank smile they gave you when you lied, they already forgot what you said.

Re:So why even bother with secure boot

[mea_culpa]

You are assuming that BIOS settings will be user accessible in the future.

Re:So why even bother with secure boot

[BLKMGK]

You seem to be assuming that the root for both key paths will be the same, somehow I doubt a key used to sign apps for a remote desktop application of any flavor is going to be allowed to sign bootloaders. It also seems you do not understand exactly how the other key came about, someone didn't just steal a Private key laying around. It's not "a" key but "THE" key that's required.

You might also want to figure out that Microsoft is NOT the signing authority for the key being used here. The Microsoft key is being used only because it's a widely distributed key and Microsoft has apparently agreed to allow it's use for others but if they refuse it's possible to have the CA sign another root. Unfortunately that Public key would be far less likely to be as ubiquitous as the Microsoft key. As it stands right now I see no reason why Microsoft wouldn't allow the signing with this key, it has protections built in to prevent malicious usage.

There will be no myriad of CA signing with the Private key to be hacked, Microsoft will have their Public key distributed far and wide in hardware. They will retain the ability to sign their code and the Root will apparently be able to sign other approved code that will leverage the same Public key. This way Linux kernels COULD be signed and use this key embedded in hardware if desired. Some distro are apparently looking to go that way. However kernels change and are sometimes custom so this shim was created and will be signed by this group to sidestep the hassle. They are getting signed by a key given to them that descends from the Microsoft key. I would bet that a revocation process does exist but I doubt it's a very smooth one.

Note that Verisign not Microsoft gets the fees from this process, they are the CA handling this.

Re:just let microsoft die

[GameboyRMH]

You target MS before Apple? That's like shooting at a vicious pomeranian nipping at your heels while a wolf is leaping for your throat.

Re:just let microsoft die

[Anonymous Coward]

cause, no one else except for a small subset of geeks even care

Unsuitable for server use?

[Chrisq]

From TFA:

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

Doesn't this mean it is unsuitable for server use - or any "headless" operation such as MythTV?

Re:Unsuitable for server use?

[LordNightwalker]

From TFA:

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

Doesn't this mean it is unsuitable for server use - or any "headless" operation such as MythTV?

From TFA:

To facilitate repeat booting (and to make the pre-bootloader useful for booting hard disks as well as USB keys or DVDs) the pre-bootloader will also check to see if the platform is booting in Setup Mode and if it is, will ask the user for permission to install the signature of loader.efi into the authorized signatures database. If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode.

So they offer a solution for your problem, but user input is required for this as well.

Re:Virtualization

[GameboyRMH]

Not yet:

https://www.virtualbox.org/ticket/7702

But there's no reason it can't.

mjg59.dreamwidth.org

[bfree]

Linux Foundation approach to Secure Boot
James Bottomley just published a description of the Linux Foundation's Secure Boot plan, which is pretty much as I outlined in the second point here - it's a bootloader that will boot untrusted images as long as a physically present end-user hits a key on every boot, and if a user switches their machine to setup mode it'll enrol the hash of the bootloader in order to avoid prompting again. In other words, it's less useful than shim. Just use shim instead.

Further UEFI bootloader work
A couple of people have asked whether we're planning on implementing the Linux Foundation approach of simply asking the user whether they want to boot an unsigned file. We've considered it, but at the moment are leaning towards "no" - it's simply too easy to use to trick naive users into running untrusted code. Users are trained to click through pretty much any security prompt that they see, and if an attacker replaces a legitimate bootloader with one that asks them to press "y" to make their computer work, they'll press "y". If that bootloader then launches a trojaned Windows bootloader that launches a trojaned Windows kernel, that's kind of a problem. This could be somewhat mitigated by limiting this feature to removable media, and we're seriously considering that, but there are still some risks associated. We might just end up writing the code but disabling it at build time, and then anyone who wants to distribute with that policy can do so at their own risk.

The solution is simple

[Anonymous Coward]

The solution is simple. Simply do not purchase ANY computer that requires secure boot, or does not allow you do disable it!

Personally, I think this is a "feature" that is going to come back and bite MS in the derriere.. At least I hope so! :-)

So

[Hatta]

When I turn on my PC, it will boot the pre-boot loader, which will then boot grub, which will then boot my initrd which will finally boot Linux. Can we put any more steps in there?

Re:So

[ledow]

Every time it CHANGES. RTFA properly.

Re:So

[bonniot]

Yes you'll have to press a key to approve the Linux bootloader, every time it boots. Not kidding, RTFA.

I don't think so. From TFA: "To facilitate repeat booting (and to make the pre-bootloader useful for booting hard disks as well as USB keys or DVDs) the pre-bootloader will also check to see if the platform is booting in Setup Mode and if it is, will ask the user for permission to install the signature of loader.efi into the authorized signatures database. If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode."

Re:just let microsoft die

[Anonymous Coward]

That's ridiculous.. they're both wolves, just one is in really sexy sheeps clothing.

Re:Virtualization

[afidel]

Windows 8 doesn't require SecureBoot, otherwise their enterprise adoption would be 0% instead of the likely 1-5%. Windows 8/Server 2012 works under ESXi 5.0 with patches and is supported under 5.1.

Re:just let microsoft die

[GameboyRMH]

Apple is attacking the consumer's expectation of software freedom. You can't go any lower that that without a brain implant.

Re:just let microsoft die

[ByOhTek]

I think it's worse than that.

Apple is building /their/ product and trying to get everyone to adapt their needs to it. At least MS is trying to make it's product general purpose (if ineptly in some cases), and allow people to have options at every level except the OS. Apple tries to restrict options at ALL levels.

No true Scottsman

[Dareth]

No true Scottsman jokes about sheep.

For newbies

[Chemisor]

Your solution of any value mostly to newbies who are incapable of going to the BIOS and typing in a new signing key (yes, all BIOS manufacturers worth buying, like ASUS, offer this option). I, for one, will not purchase any computer without secure boot. I like having a trusted hardware root. I like the fact that no malware can get in the boot process without my consent.

Re:For newbies

[Hatta]

Yeah, that works great until Microsoft deprecates the option for Windows 9 or 10. They've already done so on Windows 8 ARM tablets, why wouldn't they do it on x86 PCs?

Re:For newbies

[thegarbz]

Malware getting in the boot process... So we're creating a system of immense complexity, incompatibilities, which creates an all out shitstorm in the IT world, all to target that 0.001% of malware that actually infects the boot process? What popular malware has done this?

Is it even a credible threat?

Don't forget to visit the TSA website and drop in a few dollars in the donation form while you're at it.

Re:For newbies

[StormReaver]

I like having a trusted hardware root.

The problem is that Restricted Boot (euphemistically known as "Secure Boot") is not there to work in your best interest. It is there to work in Microsoft's best interest. It is just another tool in Microsoft's arsenal to make sure you can't use your computer in any manner not approved by Microsoft.

Restricted Boot is not there to protect you. It is there to protect Microsoft from you leaving Microsoft. Any statement to the contrary is smoke and mirrors to confuse you.

Re:For newbies

[Chemisor]

If motherboard manufacturers (not Microsoft) decide to not provide the option any more, we'll stop buying their boards. At this time this is a purely hypothetical and unlikely event, for that very reason. If and when it happens, we can complain and vote with our wallets; until then you're just spreading unjustified FUD.

Re:Virtualization

[lord_rob the only on]

I've installed and run Windows 8 correctly in VBOX on my Debian SID. I mean Win 8 final (RTM, not the CTP this version doesn't work).
It was just a glance at the OS though because I was expecting a real crap, and I wasn't deceived ...

There is a general truth to consider...

[3seas]

If we make it, we can break it. Making secure boot just more locks to keep honest people out and more headaches for honest people to deal with.

Perhaps the real question here is why do people continue with Windows, when there are other options that have better general security?

Re:There is a general truth to consider...

[jones_supa]

Perhaps the real question here is why do people continue with Windows, when there are other options that have better general security?

Because in its current state Windows is secure enough. And after that, the other features matter more (all software and hardware works, it came preinstalled, etc).

Re:just let microsoft die

[somersault]

I'm Scottish, and it's written Scotsman/Scots by the way.

Anyway, back to the topic at hand; I have to say that I don't know what you're talking about. I'd say that at least 80% of sheep aren't that sexually attractive.

Obtaining a Microsoft signature will take a while

[swm]

the Linux Foundation will obtain a Microsoft Key and sign a small pre-bootloader which will, in turn, chain load (without any form of signature check) a predesignated boot loader which will, in turn, boot Linux (or any other operating system).

The purpose of Secure Boot is to prevent people from booting non-Microsoft operating systems.
Why on earth would Microsoft sign such a bootloader?

The process of obtaining a Microsoft signature will take a while, [...]

Anyone want to open an over/under line on when this happens?
I'll put $100 on the first patch Tuesday following the heat death of the universe.

Re:just let microsoft die

[Pascal Sartoretti]

Apple is building /their/ product and trying to get everyone to adapt their needs to it. At least MS is trying to make it's product general purpose (if ineptly in some cases), and allow people to have options at every level except the OS. Apple tries to restrict options at ALL levels.

One huge difference between Apple and Microsoft is that nearly nobody is forced to buy or use Apple products : people use it by choice, and are free to use alternatives. Maybe a few persons use a Mac at work because their company enforce it, plus of course the iOS developers.

In contrast, millions (billions?) of persons use Windows and Office because they have to (company policy) or because they need to produce Office documents.

Re:just let microsoft die

[Hatta]

Apple's policies only affect Apple hardware. Microsoft is pushing this on everyone.

Re:just let microsoft die

[jader3rd]

One huge difference between Apple and Microsoft is that nearly nobody is forced to buy or use Apple products

Okay, so what happens when millions (billions?) of persons use OS X and iTunes because they have to (company policy) or because they need to product iWhatever documents? Would you rather live in the Apple "Cupertino controls your entire experience" world or the "Build on top of our platforms to do what you want, just don't muck directly with the licensed software" world of Microsoft?

Re:Srsly, what is wrong with you people?

[Hatta]

Secure boot is a good thing when the owner of the PC has ultimate control over which signatures are valid. But Microsoft has tipped its hand with Windows 8 ARM tablets, and I see no reason not to expect them to lock down secure boot on x86 PCs in the future.

If this was a vendor neutral initiative, I can see how it would be useful. But this is being done by Microsoft, for Microsoft. This will not end well for open source.

Re:Why is the linux community struggling with this

[cpghost]

That seems like a LOT more of a pain in the butt than simply turning off the secure boot option.

How long will motherboard BIOSes ship with the option to turn off UEFI secure boot? Maybe not tomorrow, but what about 1, 2 or 3 years down the road? That's the real issue here! The problem is that the PC commodity market is about to be turned into a walled garden controlled by, guess who? Microsoft in this case. That's pretty scary stuff actually, and I wouldn't wonder if the regulating authorities (at least in the EU) will sooner or later consider this as anti-competitive behavior.