Ubuntu details its UEFI secure boot plans

Posted Jul 3, 2012 19:41 UTC (Tue) by mjg59 (subscriber, #23239)
In reply to: Ubuntu details its UEFI secure boot plans by jmorris42
Parent article: Ubuntu details its UEFI secure boot plans

You don't qualify for the Windows 8 sticker without the ability to rekey and disable secure boot.

Ubuntu details its UEFI secure boot plans

Posted Jul 4, 2012 2:56 UTC (Wed) by giraffedata (guest, #1954) [Link] (18 responses)

You don't qualify for the Windows 8 sticker without the ability to rekey and disable secure boot.

I don't think that's so. From what I can tell from various reports on the web, Microsoft defines a "custom mode" in which the user has the ability to rekey and disable secure boot, but it is optional for Windows 8 certified computers. And for ARM systems, it isn't even an option -- custom mode is prohibited.

For those where it's optional, I predict manufacturers will provide it, and other commentators seem to agree, but there is still an objection to the Windows 8 certification program because it's not easy enough to enter custom mode - the computer is required to ship in "standard mode" (boots only Microsoft-approved things) by default and you have to go into a machine setup dialog to do it (obviously, standard mode doesn't let an installer program just switch out of standard mode programmatically).

Ubuntu details its UEFI secure boot plans

Posted Jul 4, 2012 3:07 UTC (Wed) by naptastic (guest, #60139) [Link]

All of this begs the question: Is anyone seeking an injunction against this behavior, which is clearly an antitrust violation?

Ubuntu details its UEFI secure boot plans

Posted Jul 4, 2012 3:30 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Check out section System.Fundamentals.Firmware.UEFISecureBoot in document http://msdn.microsoft.com/en-us/library/windows/hardware/... especially paragraphs 17 and 18 which state that custom mode and enable/disable are mandatory on x86.

You might want to be more skeptical of some of the "various reports on the web", the sites you have been reading clearly aren't doing even the most basic of research and are probably not worth your time to read. Stick to LWN 8-)

Ubuntu details its UEFI secure boot plans

Posted Jul 4, 2012 3:32 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (13 responses)

> I don't think that's so.

'MANDATORY. On non-ARM systems, the platform MUST implement the ability for a
physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:'

Followed by a requirement that it be possible to clear PK, which guarantees you the ability to enrol whatever set of keys you want.

Ubuntu details its UEFI secure boot plans

Posted Mar 23, 2015 8:15 UTC (Mon) by spaetz (guest, #32870) [Link] (12 responses)

Flash from the not too distant future. Being able to turn off secure boot boot is no longer mandatory for windows 10 but only "optional". Surprise, surprise. Another turn of the screw.

Ubuntu details its UEFI secure boot plans

Posted Mar 23, 2015 16:08 UTC (Mon) by paulj (subscriber, #341) [Link] (11 responses)

Who, I say who, could have predicted that SecureBoot would change from "optional"? Also, note that the "SecureBoot mandatory" now changes from "ARM" to the more general "Mobile":

http://cdn.arstechnica.net/wp-content/uploads/2015/03/win...

"Win10 Mobile: Must not allow secure boot to be turned off on retail device".

Thank you to all those who helped make SecureBoot a reality for Linux. I look forward to a future where I have to follow shady instructions on forums on how to hack around SecureBoot on a SecureBoot-mandatory PC device in order to be able to install my own copy of Linux.

Ubuntu details its UEFI secure boot plans

Posted Mar 23, 2015 17:20 UTC (Mon) by zlynx (guest, #2285) [Link] (9 responses)

In this future of shady SecureBoot work-arounds why did you buy a PC that doesn't allow you to customize the boot keys? It would be like buying a laptop with integrated WiFi with no Linux driver.

Ubuntu details its UEFI secure boot plans

Posted Mar 23, 2015 21:22 UTC (Mon) by paulj (subscriber, #341) [Link] (6 responses)

So I'll have to choose between being able to boot my own Linux, or being able to boot major vendor's linux distros. Great to have to make that choice!

Ubuntu details its UEFI secure boot plans

Posted Mar 23, 2015 21:58 UTC (Mon) by raven667 (subscriber, #5198) [Link] (5 responses)

I don't think there is an either/or decision here, a SecureBoot signed bootloader doesn't care, and maybe can't even tell, if it's booted on a non-SecureBoot-enabled system, so if you can boot your own Linux you can certainly boot any OS you want.

A system where you can't control the boot keys is not a system that you own, you are only renting, any system that you own you can do whatever you want with. If we can't convince MS to require owner-modifyable SecureBoot settings as part of their validation testing for the good of the community then this should be kicked up to the legislature of whatever region you are in and the right thing to do is to try and pass a law forbidding the notion that you are "buying" a computer if you don't have the access to own it, or forbidding the notion of rentable computers entirely.

Ubuntu details its UEFI secure boot plans

Posted Mar 24, 2015 8:10 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

UEFI has a global variable called "SecureBoot" which indicates whether the firmware operates in SecureBoot mode or not. So a bootloader can certainly tell with a UEFI call.

Further, at least some of the point of SecureBoot seems to be to give MS (or more likely partners) a false sense of security that the copy of Windows that is booted is the code that MS shipped. The whole point of SecureBoot is to *not boot* some code, unless signed and not blacklisted. As Microsoft states in their SecureBoot FAQ (emphasis mine):

“Secure Boot is a security standard developed by members of the PC industry to help make sure that your PC boots using only software that is trusted by the PC manufacturer.”

I don't know if MS Windows 8 refuses to boot on platforms with SecureBoot disabled, however if SecureBoot on is mandatory for Windows 10 it surely can refuse to boot if it detects SecureBoot is off. (Course, a malicious firmware can just pretend, but then SecureBoot isn't about security for you or I - its about control).

There are SecureBoot shims for Linux available which I gather will boot anything. They exist just to provide a properly signed image that MS-signed SecureBoot will accept, and then boot whatever. However, you have to wonder how long this will be tolerated by Microsoft. This SecureBoot shim can be blacklisted with the firmware at any time, by any SecureBoot OS (e.g. Windows could do so say).

It is quite clear what Microsofts' aim is with SecureBoot. They state it openly. Their aim is to be able to control what software is allowed to boot on any windows-capable system. First they had to get the technical infrastructure in place, with them controlling the key. That is now done, on the back of "it won't be mandatory (except on ARM, cough)". Next they will work to have more and more systems, and classes of systems, ship with mandatory SecureBoot. This is the logical outcome (SecureBoot doesn't make much sense otherwise), and it is their stated goal for this technology. So believe them!

Ubuntu details its UEFI secure boot plans

Posted Mar 24, 2015 15:54 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> Further, at least some of the point of SecureBoot seems to be to give MS (or more likely partners) a false sense of security that the copy of Windows that is booted is the code that MS shipped.

It doesn't actually do that, it's completely misdesigned if that were the case, it's intended to stop the boot process if the low level boot code has been trojaned so that you can boot into a recovery partition and wipe away the trojan without requiring a support call or a trip to the computer shop to have a technician do it for you. Ideally you can get an anti-malware system started early to clean out the higher level OS components which have a greater attack surface area. SecureBoot doesn't provide any reliable way to attest whether the OS has been booted correctly, aside from the fact that the OS booted at all, unlike TPM which tries to measure the running state to see if anything has been changed.

Ubuntu details its UEFI secure boot plans

Posted Mar 24, 2015 17:19 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Well, a low-level attack, e.g. VM/BluePill attack: Indeed, SecureBoot can't stop that because, as you describe, SecureBoot doesn't have a secure anchor to attest the running state. The VM can simply emulate SecureBoot.

What others involved in the Linux side of SecureBoot have said is that it is there to prevent persistent exploits. This is for a narrow definition of machine. E.g. on Fedora UEFI validates the SB shim's signature. The SB Shim validates the Fedora signature on the kernel. The kernel validates signatures on any modules are loaded.

In theory they could go further and also have the kernel validate signatures of ELF objects, at least for certain classes of ELF objects (by user, by SELinux label, whatever).

That's quite a chain of software that can be verified as "Secure", from bootloader to modules (already) and potentially even to (select) user-space binaries - no technical barrier. I don't know the details of the Windows solution, but I gather they also have signed drivers that are checked, so I assume they have a similar chain of trust.

Now, this chain of trust is still rooted in a firmware that can't be validated by the OS, but that's hard. The chain on Linux includes a good bit of software which almost certainly has a multitude of unknown security bugs.

So, I don't know quite know what you mean by “It doesn't actually do that, it's completely misdesigned if that were the case, it's intended to stop the boot process if the low level boot code has been trojaned”.

From what I can tell, SecureBoot *is* being used to validate (to an extent) that kernel and driver code is signed with a trusted key - certainly on Linux, and I thought somewhat on Windows too. So it is being used to try validate that the booted code (inc OS) is the vendor shipped code.

I also agree SecureBoot doesn't do much to actually prevent or detect after boot whether or not the OS actually:

a) Is the code that was meant to be booted

b) Has not been subverted.

Even assuming the firmware itself was not exploited. Yet, this seems to be the hope some have for SecureBoot. Also, I think just measuring the code is insufficient. It ignores the other, essential, part of computing: The state. And exploits often originate in the state!

Either we're actually in agreement or one of us is confused. ;)

Ubuntu details its UEFI secure boot plans

Posted Mar 26, 2015 15:00 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> Now, this chain of trust is still rooted in a firmware that can't be validated by the OS, but that's hard.

Sure, that's why they didn't go down that road, SecureBoot is narrowly scoped so as to be easier to implement and less disruptive. There already exists the TPM for trying to validate a running system.

> VM/BluePill attack

SecureBoot doesn't attempt to stop people from running VMs, that would be silly, but that is the problem people worry about with kexec or grub if malware can _transparently_ rewrite the whole boot process using signed tools (bootloader, kernel, userspace) in a way that doesn't require user intervention and that the end user and anti-malware software can't trivially detect. It's no problem if no one actually builds widely deployed malware that uses this tactic, but if it starts get widely used to deploy malware then you would probably want to revoke the bootloader at the top of that chain, but that may not be possible, as we've seen in an analogous instance with X.509 CAs who have poor validation practices, sometimes they are too much trouble to revoke.

If the signed grub or whatever didn't have a way to boot arbitrary things without user intervention, even if it just had some forced wait in a menu/splash screen or required an interactive OK before booting something arbitrary so that it would be obvious it was there, that might be enough to make it unattractive for malware.

> Either we're actually in agreement or one of us is confused. ;)

As a co-worker always says, "blame me, it scales well".

Ubuntu details its UEFI secure boot plans

Posted Mar 25, 2015 22:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> unlike TPM which tries to measure the running state to see if anything has been changed.

I thought TPM was the reverse problem: does the software trust the hardware?

Ubuntu details its UEFI secure boot plans

Posted Mar 23, 2015 22:02 UTC (Mon) by spaetz (guest, #32870) [Link]

Because major vendors aren't going to bother making things easy for anybody not using Windows. So the selection of hardware devices working with Linux are going to shrink to a tiny selection of geek devices. Great.

It is also telling how quickly the "taken for granted" compatability as eg touted here https://lwn.net/Articles/497949/ will be vanish.

Ubuntu details its UEFI secure boot plans

Posted Mar 26, 2015 2:19 UTC (Thu) by nix (subscriber, #2304) [Link]

Because they won't tell you whether or not key customization is supported until you bought it and got it home and found you were screwed, and then it's more or less too late (huge inconvenience factor in going back and getting it replaced, and no guarantee at all that the next machine won't be just the same).

i.e. they'll treat Secure Boot just like they treat every other remotely technical property of the machine and let you discover it for yourself.

Ubuntu details its UEFI secure boot plans

Posted Mar 23, 2015 18:06 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Well, the work on SecureBoot for Linux means that this should be a no-op for the major existing distros, they already use a bootloader shim that will continue to work. That doesn't mean that we shouldn't still condemn the practice of making the end-user configurability of SecureBoot optional, it should continue to be mandatory for the end user to retain control over their device. We should continue to encourage the proliferation of user controllable devices on Mobile as well, the Nexus line is fairly open and many others aren't bothering to prevent enduser modification.

I can understand why MS no longer cares about certifying that new hardware can run Win7 because they don't have interest in selling that configuration, but they can be helpful in using their position as the biggest power in the desktop/laptop ecosystem to keep that ecosystem open. Certainly there is going to continue to be devices where SecureBoot is configurable because there is a sufficient market for them but it'd be nice to not require people to have to buy "Pro" or "Developer" versions of machines to fully control their software.

Ubuntu details its UEFI secure boot plans

Posted Jul 4, 2012 4:08 UTC (Wed) by Fowl (subscriber, #65667) [Link] (1 responses)

"Custom mode" must be user (not programmatically) accessible in order to certify.

On the other hand, it only requires the ability to disable secure boot, not re-key it.

Ubuntu details its UEFI secure boot plans

Posted Jul 4, 2012 4:15 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Argh no really the entire point of custom mode is that it allows re-keying. It's distinct from being able to just disable secure boot.

Ubuntu details its UEFI secure boot plans

Posted Jul 5, 2012 21:01 UTC (Thu) by jmorris42 (guest, #2203) [Link] (1 responses)

I wasn't referring to official policy, I'm in the real world discussing what will actually happen. Most motherboard vendors have trouble making a lot of 'mandatory' things that customers actually care about work. Just how much effort do you think they will put into making this stuff work beyond what is required to boot Windows 8 and get the little sticker?

How many motherboards have you fought to make power management work on? How about the temp/voltage/fan sensors? Last I heard working ACPI is also a requirement for the Windows logo program.

Now add in the fact that Microsoft is almost certain to be quietly 'encouraging' motherboard makers to break this particular feature. Raise your hand if you don't think an OEM would instantly get into the double secret marketing co-op program and qualify for special pricing or marketing kickbacks for discouraging OS migration?

Ubuntu details its UEFI secure boot plans

Posted Jul 5, 2012 21:05 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

This functionality is required to get the little sticker, and ACPI functionality is tested by Microsoft. The problem with ACPI is that it's only tested under Windows, and our implementation isn't identical to Windows. That's not a concern at this level of firmware. Plus, like I said, this is functionality that's already present in the firmware that OEMs get. They'd need to actively put work into removing it.