|
|
Subscribe / Log in / New account

Fedora, secure boot, and an insecure future

By Jonathan Corbet
June 5, 2012
The UEFI secure boot mechanism has been the source of a great deal of concern in the free software community, and for good reason: it could easily be a mechanism by which we lose control over our own systems. Recently, Red Hat's Matthew Garrett described how the Fedora distribution planned to handle secure boot in the Fedora 18 release. That posting has inspired a great deal of concern and criticism, though, arguably, about the wrong things.

On a system with secure boot enabled, the hardware will refuse to run any system that has not been signed by a key it recognizes. Secure boot is meant to be a way to thwart boot-time malware by ensuring that only trusted (and unmodified) software gains control of the system. It is not effective as a digital rights management (DRM) mechanism; if you can gain control of the system, it is relatively easy to fool an operating system into thinking that secure boot is in effect when it is not. Providing the degree of control needed for effective DRM requires a trusted platform module (or similar) and associated software.

Secure boot does offer some hope of preventing a system from booting if its bootloader or kernel have been compromised by malware, though, as the "Flame" malware shows, there are limits to how much one can rely on signatures to keep systems secure. Secure boot could also, unfortunately, be effective in preventing booting if the user has tried to install an operating system of his or her choice.

The Windows 8 logo requirements specify that secure boot must be enabled. After some pushback, the requirements have been amended to also say that it should be possible for the owner of a system to disable secure boot or install new keys. It does not say that these actions need to be easy to carry out, though. Given that changing secure boot is a firmware-level operation, users wanting to make changes will be subjecting themselves to the very best sort of user experience that can be created by BIOS developers. It would be entirely unsurprising, for example, if users were forced to hand-enter new keys as long hex strings. For this to be an unpleasant and error-prone process would not be surprising.

Fedora's plan

Developers in the Fedora camp have evidently come to the conclusion that they do not want to force their users to endure such an experience to be able to install Fedora on their systems. So Fedora has chosen to take a different approach. Availing themselves of the Microsoft developer program, they will purchase a Microsoft-signed key for $99, then use that key to sign a minimal bootloader. UEFI-enabled hardware will then consent to boot that bootloader, which will immediately turn around and boot a special version of the GRUB2 bootloader which, in turn, will boot the Fedora kernel. A Fedora system set up in this mode should boot on a system with secure boot enabled with no changes required.

The appeal of this solution is clear: Fedora will "just work" on UEFI systems without forcing (possibly highly non-technical) users to make scary firmware-level changes. But there is a down side as well. The signed bootloader must ensure that it only runs GRUB2 if the GRUB2 binary has been signed by Fedora (using its own key at this point), and GRUB2 will only boot kernels that have been signed by Fedora. GRUB2 will need to be locked down, and the kernel too; the kernel will, for example, only be able to load modules that bear Fedora's signature. Given that, Red Hat's persistent attempts to get signed module enforcement into the kernel despite some interesting resistance make more sense.

Much of the coverage of this plan in the mainstream media bore headlines like "Red Hat to pay Microsoft for the right to run Linux." Such headlines are not strictly true; the payment ($99 total) evidently goes to Verisign, and what is really being paid for is the ability to boot Linux with a minimum of UEFI-caused user inconvenience. The payment for a Microsoft-signed key raises eyebrows, but it is evidently seen as the best response to a bad situation. And perhaps that is just what it is. But it also raises a number of interesting questions.

A good idea?

For example: what guarantees exist that a Microsoft-signed key will continue to be available in the future for a reasonable price? If secure boot takes over, and the only universally-recognized keys are those signed by Microsoft, then Microsoft will have a monopoly on the right to boot an operating system on future hardware. Corporations are, in general, not known for a principled refusal to exploit that kind of position, and this corporation, in particular, is well known indeed for the opposite sort of behavior. One can only assume that the price of such keys would increase in this situation.

Microsoft will also have the right to revoke keys if they can be said to be a threat to the promises given by the secure boot mechanism. That is why Fedora must be careful to limit anything that enables direct access to the hardware; should somebody be able to get such access, the signed Fedora system could be used to attack Windows systems that have secure boot enabled. In theory, all it would take is a kernel security hole to enable this sort of attack; that could then cause the Fedora key to be revoked. A quick check shows about 20 kernel security updates issued by Fedora since the beginning of this year, with multiple vulnerabilities fixed in most. That could lead to a lot of key churn, especially if, as Alan Cox suggests, every kernel hole will require that its certificate be revoked.

Depending on what software is run on a specific system (if it dual-boots Windows and Linux, for example), a revoked key could find itself into the system's "forbidden signatures" database. That would immediately disable the booting of the signed Fedora image, essentially crippling the machine. The amount of joy resulting from such an outcome can be expected to be small.

Some developers have argued that Fedora's plan is a violation of the GNU General Public License, or, at least, of the Fedora project's own guidelines, despite Fedora's efforts to ensure that users retain as much freedom as possible. GPL enforcement actions in this case seem unlikely; there's no shortage of much more severely locked-down Linux systems out there, and they have not been the target of such actions thus far. But there is a definite risk of damage to the Fedora project's image as users discover that they cannot easily install their own kernels, add third-party modules, or run tools like SystemTap.

Finally, there is the risk that Fedora's plan will legitimize the UEFI secure boot mechanism. For now secure boot can be disabled on x86 systems; what if Microsoft, in the future, points to Fedora 18 as an example of how everybody is able to work within the secure boot system and tries to make secure boot mandatory? Thus, some argue, Fedora is giving aid and comfort to those who would most like to take control of our systems away from us.

Why bother?

Given all of this, one might well wonder why Fedora is pursuing this path. Fedora users are not generally known to clamor for locked-down systems that they cannot easily tweak. Without any inside information whatsoever, your editor suggests that there are two entirely plausible reasons for Fedora's attempt to work with secure boot:

  • The Fedora project, like many free software projects, would like to have a wider base of users. It fears that, in the absence of a "just works" experience on upcoming hardware, it will lose users to other distributions that might be more willing to make that effort. Some of those users may be lost to Linux altogether.

  • The plan starts with a disclaimer that it is not representative in any way of Red Hat's intentions for its enterprise distribution. But it seems clear that there could be actual customer demand for a version of RHEL that runs in the secure boot environment. If one embraces the sort of restrictions that come with enterprise support, the additional rules imposed by secure boot will have a minimal impact, while the apparent benefits are clear. Fedora's role is, among other things, to test out technologies that might go into RHEL; in this case, Fedora's users get to stumble into the secure boot land mines so RHEL users don't have to.

So Fedora's decision to take this approach is not all that surprising. The project has concluded that it is better to restrict user freedom in certain settings to make their life easier in other ways; as Matthew Garrett put it:

[T]here's no way to rationally say that the loss of freedom in terms of users not being able to produce their own signed bootloader or kernel for free is more or less significant than the benefit of having an operating system that users can install without firmware reconfiguration.

For those who do think that the loss of freedom inherent in the Fedora scheme is unacceptable, the time between the present and when Windows 8 hardware starts shipping would be an ideal opportunity to demonstrate better alternatives. But it's not clear what those would be.

Alternatives?

One could simply ignore secure boot, requiring users to disable it before they can install Linux on their machines. That imposes a potentially scary or difficult task on those users; by the specification, secure boot cannot be disabled by the software directly. There may also be resistance from users who see a switch saying "turn off security" and don't want to flip it. This approach will work fine for hard-core Linux users and developers, but seems certain to lose other kinds of users.

An alternative would be to attempt to gain more control of the situation at the hardware level. An example can be seen in Google, which has made a point of ensuring that unlockable Android handsets exist and are available at a reasonable price. Hardware designed to run ChromeOS also, by design, comes with an easily-toggled physical switch that turns off the boot-time checks for users wanting to install their own software. The level of interest in "jailbreaks" for locked-down handsets shows that a lot of users do see value in having full control over the hardware they own. Open (and "open source") hardware has a following; it may be that the only real way to remain in control is to work to ensure that this kind of hardware continues to exist and has a growing market share. There should be a business opportunity here; projects like the Vivaldi tablet show that some people see that opportunity and are trying to pursue it.

In the absence of open hardware, we will continue to be at the mercy of others whose interests are unlikely to be the same as ours (for just about any value of "ours"). That will leave us in a position where attempts to cope like what we're seeing with Fedora seem like the best options available. That does not seem like the path to freedom; it is not why we have spent decades developing free operating systems. Fedora's secure boot plan may be an effective workaround, but leaves the real bug unfixed.

Index entries for this article
SecuritySecure boot

to post comments

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 22:15 UTC (Tue) by dashesy (guest, #74652) [Link] (7 responses)

every kernel hole will require that its certificate be revoked.
Does this also apply to NT kernels?

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 22:42 UTC (Tue) by slashdot (guest, #22014) [Link]

I see a problem: before you revoke the certificate, the kernel must be updated, or the machine won't boot.

But if it is a dual-boot system, then either Windows Update can update Linux and apt-get/yum can update Windows, or the other system will be made unbootable once the CRL is applied.

I guess that in principle it should be possible to store the kernels as EFI applications along with an update URL and do exactly that (and then have the kernel alone be capable of updating the rest of the system before it loads it), but I wonder if anyone really thought about this.

In addition, it won't be possible to install operating systems from disk media without an Internet connection, since the kernel on the disk would be almost surely revoked, but that's probably not such a huge concern.

IMHO this whole mess will just get disabled by anyone tech-savvy.

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 22:49 UTC (Tue) by rahvin (guest, #16953) [Link] (5 responses)

Or better yet, the Windows Flame Malware that's using a Microsoft signed software update to hijack windows update and push Malware onto new machines using a Microsoft signed chunk of Malware.

Digital signatures aren't all they're cracked up to be. IMO Secure boot will ultimately be as successful as all the other failed systems. As soon as someone reverses the Microsoft secret key and releases it in the wild 3 years after secure boot has been in the wild you'll see the futility in the system. Doesn't matter if they have revocation lists because unless you are receiving mandatory BIOS updates you aren't going to get them.

I hope everyone can see the futility it trying to put the security into the part of the system that almost no one actually updates (BIOS). This doesn't even touch on BIOS security or code quality. All secure boot is going to do is make BIOS the target and I doubt the BIOS producers can survive the scrutiny.

All secure boot is going to do is cause there the creation of hundreds of Malware that target and exploit the BIOS. Can you imagine a world where you have to apply security updates to your BIOS on a regular basis or Windows won't load?

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 23:39 UTC (Tue) by neilbrown (subscriber, #359) [Link] (3 responses)

I think you are saying that secure boot isn't really a solution, and I think I agree. However it seems that there is still a problem and I wonder if anyone has any ideas that might actually work.

One of the freedoms that I want for my computing experience is the freedom not to run any malware. I have enjoyed that so far largely because Windows is a much bigger target than Linux. However that has not been a complete protection and will not necessarily continue to be any protection. Recent events show that with enough resources, almost anything is possible. Maybe my ethernet card already has a back-door that is allowing unfriendlies in.

One of the things that we do with software is to make unreliable systems more reliable. TCP does this for networks. RAID does this for storage. Multi-path does it for cabling. UPS does it for power (that isn't software though).

Is there some approach that can leverage redundancy or extra analysis or some extra strong segregation that is structurally immune to all non-physical-access attacks?

Or can we look forward to an unending arms race for control of our computers?

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 9:21 UTC (Wed) by steveriley (guest, #83540) [Link] (2 responses)

This is rather the opposite of the prevailing view that software requires a hardware root of trust (https://startpage.com/do/search?query=hardware+root+of+trust). Although I actually think you're onto something here. Must ponder this one for a bit...

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 12:23 UTC (Wed) by alonz (subscriber, #815) [Link] (1 responses)

Since when has “prevailing view” come to mean “right”…?

The security field is full of misconceptions, miscommunications, and improperly-understood ideas. This is one of the major examples: a hardware root-of-trust means that the principal who put his keys in the hardware module can trust (transitively) any software running on the device. But note that the extra security is only enjoyed by the owner of the keys—not by anyone else! So, unless you give the keys to the end-user (owner of the hardware), and trust them to determine what software is trustworthy and sign this software, you end up with a vendor-locked system. (And if you do trust the end-user, I have a bridge to sell you.)

(On the other hand, if you trust the vendor, I have another bridge…)

Secure boot is currently being sold as a magic security solution. It's not magic, and thus can't work as advertised; unfortunately, a good security solution will be more complex to engineer (and thus nobody has an incentive to develop it).

(Full disclosure: I am chief architect at a security solutions company.)

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 12:29 UTC (Wed) by hummassa (subscriber, #307) [Link]

> Secure boot is currently being sold as a magic security solution. It's not magic,

It's not security, and it's not a solution... :-) people still did not understand that there is no such thing as shrink-wrapped security?? It is a process, not a product...

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 5:29 UTC (Wed) by AndreE (guest, #60148) [Link]

Actually such a world exists. MBR malware has existed for a while, and BIOS malware has already surfaced in the wild. That's the whole motivation for secure or trusted path booting in the first place.

If implementing this drives the creation of better BIOS/UEFI firmware, then all the better.

It's like saying that implementing a password system invites attacks on passwords, or implementing SELinux makes SELinux exploits a target. Well that is a truism. Any security mechanism will obviously become a target for those wanting to break it. That's not any reason for opting against one though.

Maybe Fedora should stop signing its distribution packages. After all, someone will reverse their secret key, and unless I am receiving mandatory updates I'm not going to be aware of this anyway

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 22:33 UTC (Tue) by nirik (subscriber, #71) [Link] (4 responses)

Overall great article, but two things:

1) It's worth noting that Matthew's plan is still simply a proposal at this stage. It's not yet been voted on by FESCo or the like. Perhaps something will change before that happens (although I doubt it), or FESCo could decide to reject the idea.

2) Additionally the article didn't touch on it, but hopefully there will be documentation and tools to allow any Fedora user to sign their own stuff. This way you could enable Secure Boot, but not use only your own keys signing your own bootloader shim/grub2/kernel. These tools and docs will of course be free and open.

An evolving resource with information on this for Fedora users:

https://fedoraproject.org/wiki/Secureboot

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 15:42 UTC (Wed) by gmaxwell (guest, #30048) [Link] (1 responses)

RedHat just ran press releases announcing it: http://www.muktware.com/3699/secure-boot-uefi-fedora-red-...

If you want FESCO to vote on it you're going to have to insist, because otherwise that vote isn't going to happen, it's just going to go in as updates to the relevant packages/toolchains.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 9:35 UTC (Thu) by sochotnicky (guest, #65774) [Link]

You *do* realize you linked to muktware, while saying Red Hat ran a press release. Why not just point to the full press release text[1]?

Quoting:
"...first UEFI secure boot implementation *is expected* (emphasis mine) to appear in the upcoming Fedora 18 release."

UEFI secure boot will most likely appear on https://fedoraproject.org/wiki/Releases/18/FeatureList and thus FESCO vote will be mandatory.

[1] http://www.redhat.com/about/news/archive/2012/6/uefi-secu...

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 10:03 UTC (Thu) by nelljerram (subscriber, #12005) [Link] (1 responses)

2) Additionally the article didn't touch on it, but hopefully there will be documentation and tools to allow any Fedora user to sign their own stuff. This way you could enable Secure Boot, but not use only your own keys signing your own bootloader shim/grub2/kernel. These tools and docs will of course be free and open.

How can that make sense? My understanding of Matthew's proposal is that

  • the kernel, being the software with direct access to the hardware, needs to be controlled, so that it can't do things to the hardware that might attack or subvert Windows or the boot system
  • if RH didn't (intentionally or by mistake) provide that control, the ultimate result would be RH's bootloader key being revoked, and then no RH systems would boot ever again.

Given those points, how can any RH/Fedora user be allowed to build and sign their own modified kernel, to be booted from the secure boot chain?

Personally, I just don't see what's hard about finding and toggling the BIOS secure boot setting. And to the extent that working with any of this is hard, I think better for that to create pressure on manufacturers to provide non-Windows-8-logo hardware.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 13:37 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

If a user installs their own key then a user can self-sign their kernel and bootloader.

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 22:45 UTC (Tue) by neilbrown (subscriber, #359) [Link] (11 responses)

Maybe there is an upside to MS mandating secure boot.

It means that Linux users cannot use MS-Windows-8 certified hardware, so instead of just grumbling about paying a "windows tax" they will be more motivated to petition vendors to provide MS-Windows-free systems.

Presumably a vendor could easily sell two versions on the one hardware, one with an MS-Windows sticker and secure boot enabled, one with no sticker (or maybe a "Your Freedom Respected" sticker) and secure boot disabled. They would just need a modest probability of sales to justify the small effort.

I'm sure we have the buying power to support vendors who agree to support our freedom, but as yet the motivation to use it hasn't been strong enough. Maybe secure-boot will change that.

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 23:07 UTC (Tue) by russell (guest, #10458) [Link] (1 responses)

I like your thinking. Perhaps this could also spur free software companies to develop and freely distribute a UEFI implementation that makes managing these issues ( plus UEFI bugs ) easy. Hardware vendors love free, just look at android.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 4:55 UTC (Wed) by misc (subscriber, #73730) [Link]

You mean something based on http://www.coreboot.org/TianoCore as a payload of coreboot ?

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 23:41 UTC (Tue) by faramir (subscriber, #2327) [Link] (2 responses)

I wish Linux desktop users had ANY market power at all. (I'm assuming that it is desktop users that matter here. Server admins are quite capable of setting their BIOS appropriately.)

Picking some random source (statcounter.com) seems to show the number of "other" web browsing OSes out there to be less then 3%. Even if Linux was all of that "other", it would still be less then half the number of MacOS X users. Your "modest probability of sales" is never going to capture that entire 3% and would require the vendor to double the number of types of physical products that they stocked. I'm pretty sure that any MBA worth his salt would laugh at us if we suggested it.

Fedora, secure boot, and an insecure future

Posted Jun 14, 2012 13:51 UTC (Thu) by JanC_ (guest, #34940) [Link] (1 responses)

Canonical mentioned recently that they know about something between 8-10 million computers being sold with Ubuntu pre-installed by OEMs. That's already more than the number of PCs sold with Mac OS X pre-installed, and I'm sure it's more than enough for MBAs not to laugh at it...

Fedora, secure boot, and an insecure future

Posted Jun 14, 2012 13:52 UTC (Thu) by JanC_ (guest, #34940) [Link]

Those numbers were for sales last year BTW.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 1:52 UTC (Wed) by csamuel (✭ supporter ✭, #2624) [Link] (3 responses)

There are already companies out there making hardware (desktops, laptops, etc) for Linux and it'd be a pretty safe bet they won't be shipping anything with secure boot enabled by default, so go support them.

Fedora, secure boot, and an insecure future

Posted Jun 11, 2012 11:37 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

I'd have assumed that... but the company I bought Linux hardware from last is now selling machines advertised as 'Linux-friendly', every one of which requires a binary-only module for its network card and another binary-only module for its graphics. So allowing user recompilation of kernels doesn't seem to be a long way up vendors' priority lists :(

Fedora, secure boot, and an insecure future

Posted Jun 11, 2012 11:50 UTC (Mon) by cortana (subscriber, #24596) [Link] (1 responses)

I've come to begrudgingly accept that proprietary graphics drivers are a fact of life, but I really don't understand the recent (or so it seems to be) fetish with proprietary ethernet drivers! A decade ago any cheap PC had an onboard VIA or Realtek ethernet interface that worked fine with open drivers... what has changed?

Fedora, secure boot, and an insecure future

Posted Jun 12, 2012 1:37 UTC (Tue) by bronson (subscriber, #4806) [Link]

Complex, proprietary wireless stacks covered by tenuous patents.

Turn off security

Posted Jun 6, 2012 8:07 UTC (Wed) by rvfh (guest, #31018) [Link]

Many people run pirated copies of Windows and Office [1]. I think that if people start to have to actually pay for MS software, they might quickly start looking for alternatives and thus unlocked hardware. That's been the hope for quite some time, and it might finally come true.

What is more, I wonder how having a 'secure boot' will prevent Windows system from being infected by viruses.

Also, from what I can see on forums, people do as they are told, even if you tell them to run 'sudo rm -rf /'

This leads me to think that many people might actually "turn off security" on their machines:
* not to pay for Windows
* not seeing any benefit
* not understanding what they are doing and proceeding as instructed on a forum or wiki

[1] http://www.tomshardware.com/news/China-Piracy-steve-ballm...

Lets win the language war this time

Posted Jun 8, 2012 0:58 UTC (Fri) by jmorris42 (guest, #2203) [Link]

> or maybe a "Your Freedom Respected" sticker

No, stop this line of thought. Won't work. If one option is "Secure Boot" and another is something like that we lose. We have to try like heck to influence what phrases the average tech journalist ends up using.

"Vendor Locked" for "Secure Boot" is a phrase we would win on and it just happens to be a lot more accurage. After all it isn't likely to be all that secure but it will tend to act as a way to lock any hardware with the Windows 8 logo to Microsoft.

And we want a nice suit friendly phrase for us to all get behind for the open option. "Vendor Neutral" perhaps? Or just "Unlocked" and an opened padlock logo? Or springboard off the phone/tablet wars and use "jailbroken" with an open cell door. If phone makers are seeing the wisdom as pitching it as a feature it is a pretty good bet motherboard makers would.

Or if the product includes the ability to install our own keys we get even better options to win the idea war. Imagine a logo of a closed lock with a key in the lock and another dangling on a ring like a brand new padlock. And something like "User keyable" under it. Carries all the warm fuzzies of security (such as it actually is) while also giving that user empowerment vibe.

But I'll say it again. If we can't raise enough of a ruckus to get seamless keying built in as an expected feature we are going to eventually lose. What I'm talking about here is that a new machine boots with NO keys. You pop in the Windows 8 media and pick "Install a new OS" from the BIOS and it grabs a keyring off the install media from a standardized location, adds (not replaces) those keys to it's store and boots the media. Later you stick in Fedora and do the same thing. OR if no keys are on the media you get a scary warning about it and are offered the option to install an 'insecure' legacy operating system.

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 23:02 UTC (Tue) by russell (guest, #10458) [Link] (9 responses)

Let's assume that I have a dual boot machine ( I don't ), then after running windows I find that the fedora key has been revoked. So that now means I must get an updated boot chain installed. How am I going to do that? I can't boot into linux to run yum update? Am I supposed to do that from windows? Downloading a livecd or temporarily disabling secure boot is just as confusing for "the fedora userbase" as disabling secure boot in the first place.

I wish fedora would figure out who their users are. You can't be bleeding edge and for newbies all at the same time. In my opinion, it's just not working.

Fedora, secure boot, and an insecure future

Posted Jun 5, 2012 23:19 UTC (Tue) by dashesy (guest, #74652) [Link]

If any key, I guess it would be the boot loader key that is revoked, assuming that it is the actual Fedora key purchased for 99$. In that case once a Windows security update is applied (changing BIOS perhaps) boot loader signature will not be valid anymore. If this is true, you cannot run Windows either (or maybe chainload is automatically triggered in such scenario ?). Unless the revocation is only applied to newly manufactured hardware.

I am reading this, and Samsung is one of the best hardware manufactures anyways, so if they apply "Your Freedom Respected" sticker suggested above, I do not need any other option.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 6:15 UTC (Wed) by smurf (subscriber, #17840) [Link] (4 responses)

Why would anybody revoke Fedora's UEFI bootloader signature? Presumably it's small and simple enough not to be exploitable itself.

One needs to distinguish between the initiall small bootloader, signed by M$/Verisign, and everything else, which will be signed by Fedora.
If some security-circumventing bug is found, there are a couple of options:

* store a list of hashes in the kernel, modules having that hash being forbidden to load.

* Use a sub-key for signing modules / the kernel; if buggy, revoke that subkey, distribute another one, distribute new signatures for non-affected parts of the system. This probably boils down to "don't trust any subkey created before <date>".

* Build a new mini-bootloader that only knows a new Fedora key, and install that. Ship new signatures for GRUB, the kernel, and all modules.

In none of these scenarios is there any possibility of the system being non-bootable – the running system can easily verify that there signature chain is unbroken before rebooting.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 6:51 UTC (Wed) by neilbrown (subscriber, #359) [Link] (3 responses)

> Why would anybody revoke Fedora's UEFI bootloader signature? Presumably it's small and simple enough not to be exploitable itself.

Because the bootloader would have to contain Fedora's key, so it could verify the kernel that it was loading.

If the kernel is exploitable, then anything which trusts the key is exploitable, so the bootloader containing the key is exploitable, so the key which verifies it must be revoked.

Is that right?

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 18:46 UTC (Wed) by pjones (subscriber, #31722) [Link] (2 responses)

No, that doesn't follow. If a signed kernel is exploitable, that kernel needs to be prevented from being used (using whatever mechanism). Other things signed by that key may still be trusted, depending on the circumstances.

Fedora, secure boot, and an insecure future

Posted Jun 14, 2012 5:07 UTC (Thu) by kevinm (guest, #69913) [Link] (1 responses)

It doesn't matter if you release an update for the signed bootloader that refuses to boot the known-buggy kernel, because the original signed bootloader that *doesn't* have that update is still out in the wild. Malware that wants to take over Windows machines will simply use the un-updated signed bootloader together with the signed buggy kernel.

Fedora, secure boot, and an insecure future

Posted Jun 14, 2012 12:03 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

That's why you're able to revoke binaries at the firmware level.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 19:03 UTC (Wed) by daniels (subscriber, #16193) [Link] (2 responses)

Yes, in that case things are a serious pain to get working. I assume they'd quite widely ship a live USB image (perhaps even a Windows executable) to update the bootloader.

The option you always have is disabling secure boot, which means that in its very very worst case it's no better than not doing anything at all. In its best (and presumably overwhelmingly dominant) case then it's infinitely better.

I'm struggling to see the downside.

Fedora, secure boot, and an insecure future

Posted Jun 9, 2012 0:28 UTC (Sat) by wookey (guest, #5501) [Link] (1 responses)

Except on ARM where you don't get the option of disabling it.

Fedora, secure boot, and an insecure future

Posted Jun 9, 2012 1:27 UTC (Sat) by raven667 (subscriber, #5198) [Link]

Yep, Fedora is not playing that game, they aren't going to to ship for Win8 logo ARM machines for this very reason.

Other long term problems

Posted Jun 5, 2012 23:33 UTC (Tue) by smoogen (subscriber, #97) [Link] (30 responses)

1) Having seen this in the past, I am wondering how many UEFI's will be shipped with no way to turn off the secureboot. I don't see vendors getting a no you can't if they don't ship it and it will be one less thing for them to have to put in the interface.

2) The push for secure boot will be coming from more than just Microsoft, I expect it will be required for PCI and various other compliances which will mean the majority of systems bought (eg enterprise systems) will require it. That will shift the systems that do not have security boot to being a very very small minority if at all.

3) My limited understanding is that the cost for designing any motherboard is in the 10-100k range these days depending on the things people want on the board (and all the patent licenses, cross licenses, etc needed).

4) What of the other commercial vendors? What are their plans when dealing with the first two above?

Other long term problems

Posted Jun 5, 2012 23:37 UTC (Tue) by dlang (guest, #313) [Link] (26 responses)

if the push for secure boot includes PCI, then it will need to support Linux well as Linux is _very_ commonly used in PCI environments.

Other long term problems

Posted Jun 5, 2012 23:44 UTC (Tue) by smoogen (subscriber, #97) [Link] (25 responses)

Well my guess is that the PCI and other security/audit requirements will be worded like:

Systems must be able to boot using Secure Boot Method implemented in UEFI.

And then it will be left up to the site to figure out if they want to install their own keys into every system they buy, chain off the ones built into the system, etc. [And then up to every auditor to determine if that matches the 'requirement'.]

Other long term problems

Posted Jun 6, 2012 3:49 UTC (Wed) by laptop006 (guest, #60779) [Link] (24 responses)

I doubt it. There's plenty of sites that would be using SPARC, Power, and other systems that will never support secure-boot as it currently exists.

Other long term problems

Posted Jun 6, 2012 6:32 UTC (Wed) by drag (guest, #31333) [Link] (23 responses)

THey won't support identical EUFI implementations, but it's likely they would have their own 'NIH' mechanism.

One thing to keep in mind is that the secure boot EUFI is designed to help mitigate a _REAL_ problem. Attacks on bootloaders to work around secure kernels and other things is a real problem.

It's a real problem for Linux as much as it is a real problem for Windows.

Other long term problems

Posted Jun 6, 2012 8:52 UTC (Wed) by dgm (subscriber, #49227) [Link] (22 responses)

To help us calibrate how real the threat is, can you please give an actual (non theoretical) example?

Other long term problems

Posted Jun 6, 2012 18:59 UTC (Wed) by pjones (subscriber, #31722) [Link] (17 responses)

http://blog.webroot.com/2011/09/13/mebromi-the-first-bios...

Other long term problems

Posted Jun 6, 2012 23:10 UTC (Wed) by rahvin (guest, #16953) [Link] (16 responses)

Any malware which can compromise the bios can install whatever secure boot keys it wants and tell the OS everything is hunky dory.

This is exactly the problem, people are suggesting that the way to secure their system is to give the BIOS guys the keys to their computers. I'd argue that the BIOS providers are the LAST company on earth we want to be responsible for securing the computer. Maybe if CoreBOOT was standard and Phoenix, Award and all the other culprits were gone it might be an option but these are not companies with a either a track record of reliable updates let alone security and we're talking about giving them the keys to the entire system. It's scary, and what's scarier is that people think it's a good idea.

Other long term problems

Posted Jun 7, 2012 2:14 UTC (Thu) by pjones (subscriber, #31722) [Link] (15 responses)

> Any malware which can compromise the bios can install whatever secure boot keys it wants and tell the OS everything is hunky dory.

No, that's not the case. It has to be quite a bit craftier than just that. The spec requires that most code runs in a mode of operation in which the flash which houses the keys has write enable physically disabled.

Other long term problems

Posted Jun 7, 2012 10:27 UTC (Thu) by etienne (guest, #25256) [Link] (2 responses)

> Flash ... write enable physically disabled.

That is the problem, if it is physically disabled (by a bit which cannot be reseted without complete power-down) nobody can update the key to revoke anything.
If the bit can be reseted with a magic bit manipulation then only few people know how to do it, black-hat paid $250k a shot are part of those mens.
On a side note, I tried to verify the CRC32 of the FLASH at each boot in real mode (no interception possible), but it is completely unusefull: CRC32 changes at each boot, it seems something different (boot counter?) is stored each times the machine reboots.
Basically, we would need a publicly described "file-system format" of the FLASH (simple filename/address/length triplet without non-contigous files and without automatic file creation/growing management) - so that at least the bootloader can display a warning when something which should not change has changed...

Other long term problems

Posted Jun 14, 2012 14:09 UTC (Thu) by JanC_ (guest, #34940) [Link] (1 responses)

The *current time* is updated quite often indeed... ;)

Other long term problems

Posted Jun 14, 2012 15:45 UTC (Thu) by etienne (guest, #25256) [Link]

Why would you write the current time in the FLASH? It would be out of date pretty quickly... The copy of the ACPI variables in RAM are updated all the time, as needed, but it is not my point.
What I noticed is that the FLASH CRC32 was switching in between two values, then I tried to limit the FLASH checkuming part to what is visible (real-mode address 0xE000:0000 to 0xFFFF:0000) but it did not work neither.

Other long term problems

Posted Jun 7, 2012 10:37 UTC (Thu) by nelljerram (subscriber, #12005) [Link] (11 responses)

> Any malware which can compromise the bios can install whatever secure boot keys it wants and tell the OS everything is hunky dory.

No, that's not the case. It has to be quite a bit craftier than just that.

Huh? The OP simply said "malware ... can ..."; they didn't say anything about how "crafty" it needed to be to do that. How does your response relate to what the OP said?

The spec requires that most code runs in a mode of operation in which the flash which houses the keys has write enable physically disabled.

Again, how does that relate? By saying "most" you are allowing that some code runs without key-writing disabled - and clearly this must the case, or else it would be impossible ever to update the keys!

So your post does not refute the previous one, or illuminate it. If anything it corroborates it, but strangely using language that sounds like a refutation.

Other long term problems

Posted Jun 7, 2012 16:16 UTC (Thu) by raven667 (subscriber, #5198) [Link] (10 responses)

My guess is that neither of the posters have the slightest idea of what they are talking about.

Other long term problems

Posted Jun 8, 2012 1:00 UTC (Fri) by pretter (guest, #84918) [Link] (9 responses)

My guess is that you didn't even do a simple search on the posters' names.

http://fedoraproject.org/wiki/User:Pjones and http://fedoraproject.org/wiki/User:Pjones/Features/Secure... would be a good start.

Other long term problems

Posted Jun 8, 2012 8:49 UTC (Fri) by nelljerram (subscriber, #12005) [Link] (8 responses)

I didn't need to do a search to infer that pjones is someone who has been deployed by RH to defend Matthew's plan. A few days ago, pjones wasn't even an LWN subscriber.

This whole thing smells really bad to me. At least two standard ploys have been used here that are usually more associated with politics (in the bad sense of that word).

1. Deploying extra people, previously not well known in the LWN forum, to defend a position by the preponderance of their comments.

2. Saying that we don't need to worry because it's only a proposal at this stage, and nothing is set in stone. (Obviously (1) it is a done deal already, or else all the RH people would be more open in their responses, and (2) when the initial attention and discussion has died down, the proposal will be set in stone.)

Secondly there's the ethical point, that RH have chosen overall to give aid to a Microsoft-inspired and Microsoft-favouring system, and to make themselves hostage to that, instead of unequivocally fighting against that.

Finally there are technical details that just don't seem to make sense, and where the "answers" given in these comments are inadequate and far below LWN's usual level of technical communication.

All in all, I'm afraid it's difficult for me to believe that there isn't an ulterior motive.

Other long term problems

Posted Jun 8, 2012 16:30 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> Secondly there's the ethical point, that RH have chosen overall to give aid to a Microsoft-inspired and Microsoft-favouring system, and to make themselves hostage to that, instead of unequivocally fighting against that.

You make it sound like treason, which is a ridiculous concept when applied to this case. Working with standards that MS also works with and has influence over is not an "ethical" challenge. Fedora and mjg59 have already stated their constraints, they are willing to work on secure boot on systems where key management is available to the end user (even if it isn't as user-friendly as they would like) and are not working on secure boot for systems which are boot locked, without key management (Win8 ARM).

> All in all, I'm afraid it's difficult for me to believe that there isn't an ulterior motive.

This isn't a matter of faith, it's a matter of reading the very open dialog that exists. The fact that you see ulterior motives probably reveals more about your own thought process than illuminates the discussion.

Other long term problems

Posted Jun 11, 2012 11:51 UTC (Mon) by nix (subscriber, #2304) [Link] (6 responses)

A few days ago, pjones wasn't even an LWN subscriber.
pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one). Another subscriber ID in the same thread: 84918.

By extension, unless holes in the ID are being filled in, pjones has been reading LWN for a while.

I'm concerned about this problem too. As I see it there are two possibilities. Either updating keys and adding revocations is prohibited except in a special mode, in which case malware authors will copy whatever that mode is (if necessary by having kernel-mode code loiter and spy on an update in progress to observe variable parameters, before elevating themselves from kernel-mode to BIOS compromise), or updating keys is prohibited but adding revocations is not, in which case malware authors have an instant free DoS attack vector.

It is possible that, given a completely compromise-free kernel, malware could never run in kernel mode to spy on a key update -- but firstly a compromise-free kernel is a pipe-dream and secondly malware that couldn't even get to kernel mode could never compromise the BIOS in the first place.

So as far as I can see, as long as key updates or revocations are possible under software control at all this whole thing adds no security, adds a lot of inconvenience, and allows MS to prohibit other OSes from running on their ARM devices. (Which is the real point of all this.)

Now perhaps key updates and revocations cannot be scripted, and can only be triggered from the BIOS (which means Windows updates cannot provide revocations for insecure keys but can only ask the user to do it). Desktop PCs might be safe, but server-class PCs are not, because they generally allow remote access to their BIOSes using technologies like IPMI. So on such a network malware on *another* machine can watch for a server to start rebooting, add its own key pre-emptively, then later infect it and replace its firmware. In general non-scriptable updates hugely annoy IT staff in large organizations anyway because they mean some poor sap has to walk around physically from desk to desk. So I bet the thing ends up scriptable across all machines, which eliminates its security advantages.

Non-scriptable updates would mean that no keys ever got revoked on most desktop devices. So either this thing adds security only until the first key revocation (non-scriptable case) or it adds security only until the bad guys learn how to use a debugger, i.e. not at all (scriptable case).

So I guess I still can't see the point of all this.

Other long term problems

Posted Jun 11, 2012 12:21 UTC (Mon) by nelljerram (subscriber, #12005) [Link]

A few days ago, pjones wasn't even an LWN subscriber.
pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one). Another subscriber ID in the same thread: 84918.

True, but I thought I saw, a few (or several, now) days ago, "pjones (guest)".

But I could be wrong about that, and in any case it's a somewhat distasteful point to make, so please consider that withdrawn.

Regarding everything else you wrote: I agree, and thanks for expounding it so clearly.

Other long term problems

Posted Jun 11, 2012 19:13 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

> It is possible that ...

> Now perhaps key updates and revocation ...

> So I guess I still can't see the point of all this.

This is an actual written standard with actual implementations, your assumptions are questions and those questions have answers. Instead of spilling a lot of ink with possibles and maybes it would be worthwhile to see how this stuff actually works.

Other long term problems

Posted Jun 11, 2012 22:03 UTC (Mon) by nix (subscriber, #2304) [Link]

That's true. I didn't think of it until after posting, and I don't really want to wade into the EFI swamp right now anyway.

Other long term problems

Posted Jun 11, 2012 23:12 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (2 responses)

There's three levels of key in this. The first is the platform key, or Pk. Below that are the Key Exchange Keys (KEK). Finally there's the actual signature keys, db (for whitelisted keys and hashes) and dbx (for blacklisted ones). KEK updates have to be signed with Pk, and Pk will generally be under the control of the hardware vendor. db and dbx updates can be signed with either Pk or any key present in KEK. So in order to add keys to the white or blacklists, you need to have the private half of a key already.

Most users aren't going to have any of these private keys, so Microsoft mandate that it be possible to enter a "custom mode". The semantics of this aren't well defined, so it's valid for an implementation to manage it either by offering a firmware UI interface to enrol keys directly or to simply let the user delete all the existing keys which results in the system transitioning back to setup mode.

If you have unauthenticated management interfaces on your network then you obviously deserve to lose.

Other long term problems

Posted Jun 12, 2012 7:10 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

So in order to add keys to the white or blacklists, you need to have the private half of a key already.
Aha, that makes sense. (And, again, had I done fifteen minutes of research rather than fifteen minutes' bloviating, I could probably have figured this out myself. So thanks for the information! :) )

I have horrible visions of vendors' getting the setup mode wrong such that the Pk is changed instead, breaking future updates -- but incompetent though most BIOS vendors are, I suppose the Pk is probably burned into the hardware and unchangeable even by an idiot BIOS.

I must say the thought of BIOS vendors writing anything at all to do with crypto fills me with trepidation. I'm somewhat surprised that PCs can even boot reliably, with the boot process under the control of people as bad at writing code as BIOS vendors... adding extra complexity to this, particularly extra complexity designed to fail in the direction of not booting, seems seriously unwise to me.

Other long term problems

Posted Jun 12, 2012 7:13 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

The crypto code itself is just openssl, and the interface on top is part of Tiano. So, thankfully, there's a single reference codebase for all of this.

Other long term problems

Posted Jun 7, 2012 11:45 UTC (Thu) by lemmings (guest, #53618) [Link] (3 responses)

> To help us calibrate how real the threat is, can you please give an actual (non theoretical) example?

Secure boot is the foundation for protecting the entire boot sequence.

Right now, if my Linux machine has init (or equivalent), the kernel, grub (or equivalent) or any other software used in the boot sequence modified by malware, then I am screwed. It could be very difficult to nearly impossible to detect the compromise.

A secure boot enabled system will result in a compromised system failing to boot (assuming all software in the boot sequence chain has its signature checked).

Other long term problems

Posted Jun 7, 2012 13:43 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

We all understand the theory, thanks. What I was (and still am) asking for is a _real_ example. Surely, If Microsoft is pushing this so hard it has to be because customers are clamoring at they doors with their compromised systems in their hands, no?

Other long term problems

Posted Jun 7, 2012 19:13 UTC (Thu) by apoelstra (subscriber, #75205) [Link]

I don't think you're going to find a real example, because as the parent post said, it would be next-to-impossible to detect a compromised kernel even if one was out there.

But I do think that Microsoft has people bugging them for peace-of-mind. For example, for the most part I keep a pretty careful eye on what's installed on my system and what it does, but I have only a vague idea of what the kernel and systemd are doing, and what they should be allowed to do. So I don't actually know if they're legitimate.

Now, my system is weird and useless enough that I don't worry about these things, but if it was storing customer information, subject to PCI audits, facing the Internet, etc, I would worry.

Other long term problems

Posted Jun 14, 2012 3:03 UTC (Thu) by slashdot (guest, #22014) [Link]

I predict that it will boot fine using the Awesome Genuine Trusted Signed Bootloader and Kernel, and then also happily run the malware from /etc/init, $HOME/.config/autostart, or similar.

Other long term problems

Posted Jun 6, 2012 0:03 UTC (Wed) by Fowl (subscriber, #65667) [Link] (2 responses)

1) At this stage, on x86 systems, being able to disable secure boot is certification requirement. (MS makes money selling old versions of Windows!)

2) I would think they would go straight to TPMs.

4) This I'd like to know

Other long term problems

Posted Jun 6, 2012 8:55 UTC (Wed) by dgm (subscriber, #49227) [Link]

> MS makes money selling old versions of Windows!

Not only that. Microsoft also prefers that you use a pirated copy of Windows to any legitimate version of Linux, or any other OS for the matter.

Other long term problems

Posted Jun 8, 2012 10:44 UTC (Fri) by brouhaha (subscriber, #1698) [Link]

I would think they would go straight to TPMs.
I'm sure Microsoft would like to that; they were behind the whole Palladium/Trusted Computing Initiative stuff, but they've already gotten a huge amount of pushback over that in their past proposals. For now they're trying to placate OEMs and customers by pushing something that doesn't increase the direct cost of the hardware. It has lots of indirect costs, but it's much easier to sweep those under the rug.

In the long run, I expect that Microsoft will try to get processor vendors to put keys and hardware, microcode, or a first stage boot in the processor itself (i.e., built-in TPM), so that it isn't even possible to run an unsigned BIOS/UEFI/coreboot/whatever. By building this misfeature into the processor, they can make the incremental hardware cost essentially zero. This will split the processor market into Windows and non-Windows processors, and there will naturally be a price difference based on the production volumes of the variants. This means that non-Windows desktop processors will cost more than Windows desktop processors, but unless Microsoft makes significant inroads on mobile devices, the reverse might be true there. It is thus ironic that Microsoft is focusing the majority of their so-called Secure Boot effort on the mobile market.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 5:25 UTC (Wed) by ajb (subscriber, #9694) [Link] (7 responses)

It seems to me that we need to push for hardware vendors to install easy way of allowing non-microsoft controlled access. For example, a second key controlled by some foundation, either enabled by default, or with a simple yes/no question in the BIOS.

Foundation?

Posted Jun 6, 2012 5:55 UTC (Wed) by smurf (subscriber, #17840) [Link] (3 responses)

The idea has been played with, but a foundation which does this needs a whole lot of money up.front (establish secure infrastructure, badger manufacturers, …)
Apparenty M$ doesn't even do the infrastructure part itself; that's been outsourced to Verisign. A sensible move, if you ask me, but it doesn't necessarily save money.
Anyway, AFAIK no corporation has been forthcoming with the $$ necessary to do this. Unless that happens, we can talk about doing a Foundation (or using an existing one for this purpose) all day long, but won't accomplish anything.

Foundation?

Posted Jun 6, 2012 10:32 UTC (Wed) by Lennie (subscriber, #49641) [Link] (2 responses)

"a whole lot of money up.front (establish secure infrastructure, badger manufacturers, …)"

Euh, CA Cert secure infrastructure runs just fine thank you.

"Audit ready" could possibly be solved by throwing more money at it though.

Foundation?

Posted Jun 6, 2012 12:08 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

Exactly how many browsers get shipped with the CACert root keys pre-installed?

What makes you think they'd have any success with BIOS manufacturers?

Foundation?

Posted Jun 6, 2012 12:35 UTC (Wed) by Lennie (subscriber, #49641) [Link]

I'm just "saying" that infrastructure is possible to achieve.

When they get audit ready, they'll be able to get into Firefox and thus Chrome and probably Windows and Opera too.

But only if they get audit done.

Custom key management

Posted Jun 6, 2012 6:12 UTC (Wed) by DavidS (guest, #84675) [Link] (1 responses)

Yes, it'd be great to have a firmware that would allow easy key mgmt, removing all existing keys and uploading a local key. Judging from the amount of customization one gets from the big-iron shops when purchasing enough, I presume it'll be possible to get a boat-load of PCs with pre-loaded keys.

Running an "independent" certification authority on the other side will make about 99$ difference to using the Microsoft key. Except for the additional cost this "Foundation" has to shoulder to keep their own key safe.

1 Windows updates on dual-boot machines would still *need* to black-list compromised linux certificates
2 Getting the key onto machines would still be a pain
3 The machines would still not allow to run arbitrary code under secure boot
4 The machines would still be vulnerable to 0-day windows exploits

But maybe cacert.org would be interested?

Custom key management

Posted Jun 11, 2012 12:14 UTC (Mon) by nix (subscriber, #2304) [Link]

removing all existing keys and uploading a local key
That sounds like you think that uploading a local key should require removal of the existing ones. Thanks, but no thanks: being able to boot from distro-provided rescue CDs is sometimes very useful!

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 11:36 UTC (Thu) by krake (guest, #55996) [Link]

The whole secure boot topic is an epic fail on part of the Linux Foundation.

Not only did it fail to lobby for key management being possible and easy for computer owners, it did not make sure that its key would be pre-installed along side Microsoft's and available for signing distributor's boot loaders.

Rescue system?

Posted Jun 6, 2012 6:13 UTC (Wed) by tnoo (subscriber, #20427) [Link] (2 responses)

So, what is the procedure for rescuing a system under secure boot? IIUC there is no way one can fix the operating system, file system, or bootloader after something goes wrong. Maybe not a problem for perfect operating systems such as Windows, but what if I misconfigured my Linux box?

Rescue system?

Posted Jun 6, 2012 17:28 UTC (Wed) by nix (subscriber, #2304) [Link]

I suppose a system that won't boot is completely secure against boot-time malware. Not too useful though.

Rescue system?

Posted Jun 6, 2012 19:02 UTC (Wed) by pjones (subscriber, #31722) [Link]

You use a rescue image with a signed bootloader, or you disable Secure Boot temporarily to fix the problem.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 7:38 UTC (Wed) by gioele (subscriber, #61675) [Link]

In a comment by mjg in [1], he pointed out that on systems that have a secure boot firmware you will not even be able to swap out the firmware for freer alternatives like coreboot:

> The move to secure boot means that firmware updates are signed, because otherwise you could disable secure boot simply by pushing out a fake firmware update.

Now my fear is that, in few years, it will be practically impossible to buy an x86 mainboard that allow you to disable secure boot or to re-flash it with coreboot. This is scary.

[1] http://news.ycombinator.com/item?id=4064868

Signed bootloader without verification?

Posted Jun 6, 2012 7:56 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link] (1 responses)

Why can't we pay (once) for a signed bootloader which just boots Grub. Then Grub can chainload anything it wants. After all, a signed copy of Windows can still run unsigned applications from within Windows, so why not have a signed bootloader running an unsigned kernel.

From a UEFI perspective, that would be a major "security hole", but who gets to decide when a key is revoked? If there is a microsoft vulnerability for a particular signature, doesn't MS get to be the one to decide to revoke the key?

Signed bootloader without verification?

Posted Jun 6, 2012 10:00 UTC (Wed) by jamesh (guest, #1159) [Link]

Matthew's article mentions that. If you have a version of Grub that can boot in a secure boot scenario but will run any kernel, then it can be used to subvert the system (e.g. create a new UEFI environment that claims to have secure boot enabled and then boot Windows with it).

While Windows 8 lets you run unsigned applications, it seems that it won't let you load unsigned drivers so that is a bit different to Grub running arbitrary kernels.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 12:10 UTC (Wed) by zoglesby (guest, #70057) [Link] (24 responses)

This whole issue is being blown out of the water, Fedora users would be no less free to do what they want to their machines, they only need to disable secure boot. The actions taking place are to help people who don't want to do that, and that is not the kind of person that would boot a custom kernel, or run SystemTap.

The unfortunate reality is that in order to make your distribution work on a machine that was built for Windows 8 without disabling secure boot you will have to do the same thing. I would expect to hear Ubuntu and others to come to the same conclusion.

If the idea of secure boot is to much to deal with just by a computer from a Linux supporting company like EmperorLinux or System76.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 15:46 UTC (Wed) by gmaxwell (guest, #30048) [Link] (23 responses)

When I write software which Fedora packages I enjoy the same freedom fedora has to fork the distribution, make modified versions of its packages etc. Under this scheme Fedora (and others who pay MSFT) will enjoy a privileged position, able to ship software that just works. If I make a respin of Fedora under that model my version will suck until I pay up.

You can argue that the difficulty of turning it off is small (even though it may not be possible to turn it off, as the UEFI spec doesn't require that, just the windows 8 logo program, and they're unlikely to enforce that particular requirement) but that is somewhat incompatible with arguing that its something Fedora must do.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 16:30 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (9 responses)

> When I write software which Fedora packages I enjoy the same freedom fedora has to fork the distribution

No you don't. The trademark policy already forbids that.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 17:14 UTC (Wed) by gmaxwell (guest, #30048) [Link] (8 responses)

Is no software meaningfully free because I can't use it to kill someone without breaking the law?

You're talking about software which RedHat will be cryptographically signing, the absence of which will leave users in various degrees of not being able to run it on their computers vs not being able to misrepresent my software by leaving an inaccurate name on it.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 17:18 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (7 responses)

No, I'm saying that you never had the freedom to do something you asserted you had the freedom to do. This places yet another obstacle in your way, yes, but your original claim was simply untrue.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 17:20 UTC (Wed) by gmaxwell (guest, #30048) [Link] (6 responses)

I did no such thing.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 17:39 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (5 responses)

"When I write software which Fedora packages I enjoy the same freedom fedora has to fork the distribution"

Fedora can fork Fedora as often as it wants and keep the use of the trademarks (see the various spins for evidence of this). You can't do that. You do not enjoy the same freedom that Fedora has.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 17:54 UTC (Wed) by gmaxwell (guest, #30048) [Link] (4 responses)

Fedora also does not have the freedom to lie about the authorship/identity of the software.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 17:56 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (3 responses)

The trademark license restricts you further than that.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 18:56 UTC (Wed) by cmccabe (guest, #60281) [Link]

If a Linux desktop distribution was ever commercially successful in a meaningful way, the first thing that would happen is black hats would create fake copies of the distribution with spyware and adware installed, or worse. We've seen this time and time again.

If you don't have a trademark, then you can't do anything about it. This is also the reason why Linus Torvalds has a trademark on "Linux."

It's all very well and good to say "well, those people are stupid. They should have gone to the REAL fedoraproject.org." But if you don't have a trademark, there's nothing stopping the black hats from registering therealfedoraproject.org and putting the badware there.

tl;dr Trademark law exists for a reason and it's not evil.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 19:00 UTC (Wed) by gmaxwell (guest, #30048) [Link] (1 responses)

It really doesn't. In the US, at least, the rights scoped by trademark are substantially limited to cases which would create confusion or the potential for misrepresentation. And as I said before— regardless of how Fedora is licensed it remains just as unlawful to use Fedora to kill people or rob banks, and yet we don't consider fedora this problematic for software freedom.

The analogous cases is that I release software under a copyleft license and then FooCorp takes my software an enhances it so that it can run on some new class of devices and then redistributes it. However, downstream recipients are prohibited from making modifications to these enhanced copies unless they pay $99 for a non-transferable right to modify, or if they remove the enhancement. This would generally be prohibited by a copyleft license if accomplished via copyright restrictions.

In this case the enhancement the modification of the software by the addition of a cryptographic signature with a key only known by RedHat and the prohibition is the digital rights management function of the bios instead of a licensing restriction. The fact that there is some obfuscation where the distributor and the device maker are distinct entities isn't really important relative to the recipient's freedom, and for all I know the UEFI firmware makers are just shell companies for RedHat (not that I think they are, but could be for the next party trying to enhance+lockdown Linux systems).

The difference in mechanism may make this behavior pattern compatible with current copyleft licenses. But because the end effect can be the same people can reasonably hold that it's incompatible with the intent and spirit of copyleft licenses, and that perhaps new licenses ought to be authored which prevent gatekeepers from extracting rents on making free software usable by licensing out signing key.

Fedora, secure boot, and an insecure future

Posted Jun 6, 2012 19:14 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Sigh. No. Really. Read the copyright license attached to the files containing the Fedora trademarked artwork. I'm not telling you you have fewer rights because I misunderstand trademark law - I'm telling you you have fewer rights because the license says so.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 13:17 UTC (Thu) by drago01 (subscriber, #50715) [Link] (12 responses)

> Under this scheme Fedora (and others who pay MSFT) will enjoy a privileged > position, able to ship software that just works. If I make a respin of Fedora under that model my version will suck until I pay up.

So you are saying we should make Fedora "suck" to save you 99$ ? This has nothing to do with software freedom. You have the source you are free to sign it (with any key) or not sign it at all.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 16:42 UTC (Thu) by gmaxwell (guest, #30048) [Link] (11 responses)

"If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all."

Yes. You don't and shouldn't get a free pass on the norms of free software because you can wave your arms and say you can't simultaneously satisfy the many goals you may have.

Your modified version— through the addition of a signature chained to Microsoft's cryptographic lockdown, among other change— of the third party free software you distribute should either live free or die.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 17:45 UTC (Thu) by raven667 (subscriber, #5198) [Link] (10 responses)

> free software you distribute should either live free or die.

Great sound bite but I don't really understand what you are trying to say. Any secure boot system where you can install your own keys or disable it is fully compatible with the most stringent of Free Software guidelines. It's not "Tivo-ization" if you can load your own custom code. To claim otherwise is a gross mischaracterization of the issues involved and does not add to any debate of the issues.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 18:28 UTC (Thu) by gmaxwell (guest, #30048) [Link] (9 responses)

A couple of points…

UEFI's specification itself does not require that secureboot can be disabled. The only requirement that it needs to be possible to disable it is in Microsoft's requirements. I can't reasonably expect their enforcement to be too aggressive considering that they previously (and still, on ARM) required the opposite.

Signed Fedora will run equally well on systems where secure boot can't be disabled. In the discussion on Fedora-devel the people promoting this change seemed to be saying that this was a good thing that Fedora still ran, and that Fedora/Redhat would have no recourse if it were to happen. What we seem to have constructed is a nice little bit of indirection where a couple billion dollar corporations can take away users rights with respect to software they didn't even write and then all earnestly claim "wasn't me". Instead of "non-transferable covenants not to sue" we have "cryptographic keys you can't distribute", but since code is law (or even more powerful) when it comes to the freedom users have over the software it doesn't matter that the restriction is a technical one.

I also gave the argument above that this isn't the quite same as tivoization, even though the same cryptographic lockdown technology is involved. Fedora is adding functionality to the software to make it run on some new hardware and distributing these enhancements under terms that make downstream distributors choose between the enhancement, making their own version of the enhancement (with a minimum cost of $99) and still limiting further downstream users, or going without the enhancement. What Redhat should be doing is distributing their secure boot signing key, so everyone can enjoy the enhancement without paying fees or losing their ability to modify the software— but presumably they have contractual obligations which prohibit this. I argue that since they can't simultaneously keep the software as free to modify and redistribute as they got it, they ought not to distribute the enhancement at all. Or at least thats an argument.

(And instead, they should make a special signed bootloader shim which, if secure boot is enabled, it displays a set of help screens to help users turn it off or add their own keys— this would itself not be the freeest of software, but it would be trivial and the author(s) would obviously agree with that kind of distribution)

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 20:23 UTC (Thu) by raven667 (subscriber, #5198) [Link] (6 responses)

> requirement that it needs to be possible to disable it is in Microsoft's requirements. I can't reasonably expect their enforcement to be too aggressive

A boot locked system will be unable to run Win7 which is not a desirable outcome and is why this requirement exists. The manufacturers have no independent desire to boot lock anything. Win8 ARM can be boot locked because there is no installed base.

> billion dollar corporations can take away users rights

bull s**t . Also "OMG CORPORATIONS!". I feel bad being so sarcastic but your point is just so misinformed.

As long as you have local key management and the option to disable your rights have not been infringed in _any_way_.

> minimum cost of $99

Only if you want to be signed by the existing Verisign/MS authority, you can always be your own authority and have the end-user load keys in by hand. The whole purpose of being signed by the Verisign/MS key is to make it easy to work by default without requiring end-user interaction with the firmware. These systems are _not_ boot locked.

> What Redhat should be doing is distributing their secure boot signing key

No.

Seriously, no. You have no need for that to exercise your software freedoms since you can load your own keys or disable the entire secure boot system. There is no restriction preventing you from running your own modified boot loader software. Let me repeat that, there is no restriction preventing you from running your own modified boot loader software.

> displays a set of help screens to help users turn it off or add their own keys

Not possible because you can't modify the authorized keys via booted software, only from the firmware.

> displays a set of help screens to help users turn it off or add their own keys

Now that we've dealt with a number of misconceptions, the real issue is that the key management isn't as easy as it should be. Ideally when booting off removable media (USB, CD, PXE, not SATA) there would be a standard place to put public keys and the end user could be prompted on the console as to whether to import such keys before the beginning of the boot process. That would make it very easy for each spin or custom distro, even locally generated ones, to include their own key infrastructure, and use the secure boot feature, which is currently possible but is more work than strictly necessary. Developers who modify software probably don't have too much trouble jumping through the hoops required to use their own keys but it's not a user-friendly process for the majority of Fedora (or Ubuntu or Debian or SuSE, etc.) users who just want to get a machine installed and working.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 21:07 UTC (Thu) by gmaxwell (guest, #30048) [Link] (3 responses)

> As long as you have local key management and the option to disable your rights have not been infringed in _any_way_.

This simply isn't the case. Free Sofware— and the success of our ecosystem— depends on not just the ability to be personally free but to have the freedom to pass those rights on to other people.

If "just turn it off!" was enough for me it would also be enough for Fedora.

And again, there is no guarantee that it will be deactivatable. It was not until Redhat fought to fix that, and windows 7 existed before then.

As far as the corporation comment— Microsoft and RedHat sat at a negotiation table making these decisions, I'm not saying that I should have been there— but where was the non-profit and/or governmental party representing my interests relative to my ability to distribute software which will easily run on the widely available computers tomorrow?

> That would make it very easy for each spin or custom distro

And Fedora could work to make it easier. In the short term where getting the firmware consistent isn't an option having good help would be an option. This would leave all users, distributors, and authors equal and working towards common goals.

Fedora, secure boot, and an insecure future

Posted Jun 8, 2012 5:17 UTC (Fri) by raven667 (subscriber, #5198) [Link]

>> As long as you have local key management and the option to disable your rights have not been infringed in _any_way_.

>This simply isn't the case. Free Sofware— and the success of our ecosystem— depends on not just the ability to be personally free but to have the freedom to pass those rights on to other people.

And you still haven't provided any example as to what rights aren't being passed on to other people, because there aren't any and you have no argument.

> And again, there is no guarantee that it will be deactivatable. It was not until Redhat fought to fix that, and windows 7 existed before then.

I'm not sure I can even parse that. In any event key management and the ability to disable are part of the Win8 logo requirements which should be widely adhered to. It doesn't have anything to do with RedHat and much to do with Win7.

> As far as the corporation comment— Microsoft and RedHat sat at a negotiation table making these decisions

Maybe they were smoking cigars and drinking whiskey too...

> And Fedora could work to make it easier

And of course the tools Fedora uses to make this happen will be available to anyone so it will be at least as easy for you or me as it is for them.

Fedora, secure boot, and an insecure future

Posted Jun 8, 2012 10:27 UTC (Fri) by drago01 (subscriber, #50715) [Link]

> This simply isn't the case. Free Sofware— and the success of our ecosystem— depends on not just the ability to be personally free but to have the freedom to pass those rights on to other people.

You still have this right (with or without secure boot). Fedora has no obligation by *any* license that can be called free to help your fork. Either by making there software less usable or anything else. All they have to do is to provide you the source and tools needed to create the fork.

And they *do* that. You have the source. You have the tools. If you want to sign it ... fine pay the 99$ and go ahead. If you don't or even can't (because you cannot afford the 99$) that's fine as well this does not make the software any less free.

By your logic Fedora is not free already because they have a competitive advantage over forks by having infrastructure (builders, mirrors, bug tracker...). All those cost way more then the stupid 99$. Oh and the trademark and marketing budget.

This is not that hard to understand really.

Fedora, secure boot, and an insecure future

Posted Jun 8, 2012 13:13 UTC (Fri) by dgm (subscriber, #49227) [Link]

>> As long as you have local key management and the option to disable your rights have not been infringed in _any_way_.

> This simply isn't the case. Free Sofware— and the success of our ecosystem— depends on not just the ability to be personally free but to have the freedom to pass those rights on to other people.

Gentlemen, you need to realize that the problem is not Fedora or what they do. The problem lies in those distributing Fedora, that is, the OEMs. If System77 or Dell ships a laptop with Fedora preinstalled, then they are the ones that _have_ to instruct the user on how to change the keys, should they want to.

Fedora is just trying to be nice to people that didn't chose a preinstalled system, and instead just want to test the distro in hardware blessed for Windows 8. That you can do this is GOOD.

Fedora, secure boot, and an insecure future

Posted Jun 8, 2012 9:56 UTC (Fri) by ballombe (subscriber, #9523) [Link] (1 responses)

> Only if you want to be signed by the existing Verisign/MS authority, you can always be your own authority and have the end-user load keys in by hand.

So far no evidence that 'loading key by hand' will be actually possible has been provided, and indeed this is one of the premise of the Fedora decision. You cannot have it both way.

Fedora, secure boot, and an insecure future

Posted Jun 8, 2012 16:54 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Hardware with the Win8 logo will be shipping with secure boot enabled by default, the MS keys loaded by default and must have the option to disable secure boot, they may also have the option to load their own keys. Fedora will be having their bootloader signed by MS because it's user-unfriendly to require a trip to the firmware to modify secure boot settings before booting an install CD. If you want to install custom software or older software (Win7 or whatever) you will have to fiddle with the firmware in any case.

Fedora, secure boot, and an insecure future

Posted Jun 8, 2012 9:06 UTC (Fri) by nelljerram (subscriber, #12005) [Link] (1 responses)

UEFI's specification itself does not require that secureboot can be disabled. The only requirement that it needs to be possible to disable it is in Microsoft's requirements. I can't reasonably expect their enforcement to be too aggressive considering that they previously (and still, on ARM) required the opposite.

Regardless of what any requirements say, I think what matters is whether the disabling possibility is important in practice to Microsoft. If it is, it will be implemented and well tested by manufacturers, and so we can have some confidence that it will work for us. If it isn't, it won't be well tested even if it's theoretically required and implemented, and then probably won't work for us.

Fortunately there are other comments on this article that claim that disabling is practically important for Microsoft, so there's hope...

(Of course it will still be better to buy from a Linux-supporting manufacturer that doesn't impose the "secure boot" BIOS at all.)

Fedora, secure boot, and an insecure future

Posted Jun 8, 2012 16:33 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> Fortunately there are other comments on this article that claim that disabling is practically important for Microsoft, so there's hope...

The obvious being that Win7 doesn't support secure boot and will need to run on Win8 hardware for the foreseeable future, both for home users and businesses. Maybe in 10+ years we'll be having this discussion again, but probably not before then unless secure boot somehow comes to Win7 via a service pack or something (and if MS are content to leave behind users who can't/won't upgrade software).

I am apalled.

Posted Jun 6, 2012 18:50 UTC (Wed) by ebiederm (subscriber, #35028) [Link] (1 responses)

I can not possibly see how a system that does not leave the owner of a system firmly in charge can make any sort of sense.

If you aren't installing the keys into UEFI that you trust and remove/revoking the keys that you don't trust this is in no sense
limiting a system to it's desired function by the owner of the device.

Frankly the proposed system would make the computer completely unworkable to me.

There might be an excuse for doing something like this after the distribution has been reengineered such that all of the needed policy and controls are in place to make the guarantees you want to make and
the only thing that would change in the magic UEFI secure boot mode would
be the key you sign the bootloader with. Making using UEIF with the
microsoft key as a fallback solution for those days when you just can't
install a key of the administrators choosing.

However doing this simply to get the hands of more people doing a half backed job of locking down the software is ridiculous. If you don't give people freedom to run the software of their choosing when being evangelical about free software and instead stick them with the a system where they can only run fedoras latest bugs I hardly see how that will improve the user experience.

I am apalled.

Posted Jun 6, 2012 19:06 UTC (Wed) by pjones (subscriber, #31722) [Link]

> I can not possibly see how a system that does not leave the owner of a system firmly in charge can make any sort of sense.

You are firmly still "in charge". You can install your own keys, and you can disable this feature altogether in the firmware. On x86, nobody is stopping you from that.

ARM Client machines are a different story. On Windows logo-bearing ARM client machines, you are not in control. That's why we've said we don't intend to support this functionality on ARM.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 9:17 UTC (Thu) by ribbo (subscriber, #2400) [Link]

I would like to point out that at the moment the "Fedora project" hasn't decided anything, this is a proposal put forward by one developer that happens to work for Red Hat. To be accepted into Fedora this has to be proposed as a feature first and approved by FESCO, and possibly the board.

Fedora, secure boot, and an insecure future

Posted Jun 7, 2012 9:58 UTC (Thu) by ortalo (guest, #4654) [Link]

"There may also be resistance from users who see a switch saying "turn off security" and don't want to flip it."

Well, from my experience, the situation is probably quite the opposite. Users anticipate any "security" feature to be an inconvenience for them and may well be willing to act to deactivate it at first confirmation of such inconvenience.
And well, when you think about it, maybe they are not so wrong about the overall situation. When you look at them in more detail, most recent security mechanisms do not adress final customers needs. They have been made to protect network operators, commercial software vendors, gaming companies, content distributors, etc. Being technically savy on computer security [1] may prevent us from asking us the right question about this secure boot security mechanism: should we accept it or reject it (you know, like that patch for the kernel)?

With restect to these recent evolution, it seems to me I'd like to have a different mechanism on my computers. IMHO, if I take this one, I will not have any other in the near future so; maybe I'll go in the users camp in fact and turn off that switch initially at least to show my desaprobation.

Anyway, this is just a mechanism; maybe it does not even fit my security needs... but that is another and more important question.

[1] I (should) be... :-)

Fedora, secure boot, and an insecure future

Posted Jun 14, 2012 9:51 UTC (Thu) by tonyblackwell (guest, #43641) [Link] (1 responses)

lLts of erudite discussion here, but I can't find anything relating to the immediate practical problem. Are there any currently available motherboards which implement UEFI but also provide a BIOS way to disable secure boot for linux?

From my attempted discussions with Gigabyte and ASUS the answer from both of these appears to be 'no', although it was conducted in English text with folk who may have missed the point.

Amoungst our community, does anyone have higher-level contacts than just their generic web interface to get some answers? - or at least discuss the issue?

Fedora, secure boot, and an insecure future

Posted Jun 14, 2012 12:05 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Right now you can't buy any motherboards that implement secure boot at all. No signed operating systems have been released yet - what would the boards boot?

PC suppliers, and the commercial impact of secure boot on them

Posted Jun 15, 2012 22:43 UTC (Fri) by jdobbs1010 (guest, #83118) [Link] (2 responses)

The company where I work has recently migrated from Windows XP to Windows 7 as the standard corporate desktop for its entire workforce. Its taken them a long time and a lot of money to do this. I doubt they will be rushing out to buy Windows 8/secure boot hardware for a few years to come. I've also read in the IT press how Windows 8 is likely to flop like Vista. I suspect there's going to be a lot of Windows 7 desktops around for quite some time to come in the corporate world. Which means corporate PC suppliers (HP etc) must sell PCs that can have this feature disabled if they want the corporate business. I am imagining a little switch at the back, turning secure boot on and off, like the little piece of plastic on 3 1/2 inch floppies to toggle the read-only. Worse for the casual user would be a jumper on the motherboard (if motherboards still have jumpers nowadays)

Another question raised in the comments was 'who would step up and manage a key independently of Microsoft'. What about a big PC vendor? They surely have in interest in it, and might get a competitive advantage - as long as its OK to have 2 keys on the same machine, then why wouldn't they? (apart from risking Microsofts ire). They could even charge something for a 'free software key'. I'd be happier paying that, than a Microsoft tax.

That said, the whole scheme is a recipe for abuse by commercial interests. Some entity has to manage the keys, and hence has power over the hardware owner. Power corrupts etc. Who would you trust - Microsoft? HP? Verisign? Your government? Redhat board of directors? Those Debian fanatics? FSF? Pick your poison!

PC suppliers, and the commercial impact of secure boot on them

Posted Jun 18, 2012 15:22 UTC (Mon) by josephkliener (guest, #85179) [Link] (1 responses)

I trust myself. I would not even trust red hat with a forced global key. At least with the repository PGP keys it is my choice to install them. They don't come pre-installed.

PC suppliers, and the commercial impact of secure boot on them

Posted Jun 20, 2012 18:35 UTC (Wed) by BenHutchings (subscriber, #37955) [Link]

You can't install an OS you don't trust and somehow configure it into an OS you do trust. How can you know it really follows your configuration, and doesn't have a secret backdoor?

Fedora, secure boot, and an insecure future

Posted Jun 18, 2012 15:09 UTC (Mon) by josephkliener (guest, #85179) [Link] (2 responses)

Time and time again, it was even said by Linus himself. Linux should be focusing on pre-installed systems.

The user who knows how to download Linux, put it onto a USB stick or USB, restart their computer (potentially have to press the boot menu key for their computer) and run or install Linux. They know or will know how to disable secure boot and it would not deter them from using Linux if they could do. The user that Fedora and Gnome 3 are tailoring their user friendliness to does not exist. 99% of people if it does not come pre-installed they will not change. How do you think people find about Linux? Is there any T.V. Advertising? This kind of attitude is ridiculous. Paying $99 is just supporting and putting Microsoft in a better position than they are now... which currently is failing in every market. Some of these guys are so old and stuck in the 90's thinking that Microsoft on desktop is still the relevant target. The Tablet and Mobile market and some lesser extent Mac is where it is all concentration is at the moment, and you guys are ignoring ARM (which may be a waste of time or it may overtake x86). Secure boot and Windows 8 are aimed for high-end systems currently (e.g. ultrabooks), and these are going to be direct competition with MacBookPros and iPads.... if you were an un-informed consumer, who could not disable secure boot which one would you buy?

Also I have no idea why you cannot see that Secure Boot is supportive of a DRM system. Sure if you are talking proper access control, with a crypto module and tamper resistance, and remote attestation. Yes it does not support that. But what sort of DRM do we have at the moment? Well it is software based, and can be circumvented by say, using software to dump the memory or effectively installing your own root kit. Well what happens if Windows supports software DRM at the kernel level and prevents memory dumping of a certain application? You have to edit the kernel to circumvent the DRM for your system. What happens if at the kernel level it requires the user space code to be signed by Microsoft and downloaded from the Microsoft store. Well we just edit the kernel... but hang on that windows update last week meant I can no longer disable secure boot.... I cannot boot if I try to circumvent the DRM... Okay so I will have to flash the hardware manually... wait a minute the manufacturer has hard coded their certificate into the chip... crap DMCA territory.

This is exactly how the iPhone works and jailbreaking iPhones has a specific exception granted to it that might or might not be granted if secure boot was one day disallowed from being disabled.
Sure their are ways around certain aspects, the system does not have any real unique identifier that cannot be faked, but as it stands currently windows advantage or whatever uses a bunch of ridiculous random hashes of bios, cpu, driver information. The uniqueness required for DRM is included in the software key, which will disable windows update, etc. if it detects it is circumvented already.
Companies want DRM at any level, they would even accept obfuscation as a form of DRM if they thought it would stop even 1 person from pirating their stuff. All it takes it one person to go.... hey wait a minute if we stop people from disabling secure boot we could be in a better place than we are now.... this would trump whatever anti-trust people would through our way.

Sure you could install pirated software on a pirated copy of windows on a computer without secure boot. But in 5 years time you will be stuck with old hardware, as everything you want to buy will come with secure boot.

I mean another example could be on a system with windows 8 starter, black list the signatures for windows 8 home, and premium, ultimate etc. then if they purchase the upgrade you use windows update and the manufacturer's key to un-blacklist the version of windows they purchased. How can you say this is not DRM...

Coreboot support and linux on pre-installs is the way forward. That $99 could be spent elsewhere. Save the pennies and the dollars will look after themselves

Fedora, secure boot, and an insecure future

Posted Jun 20, 2012 18:45 UTC (Wed) by BenHutchings (subscriber, #37955) [Link] (1 responses)

They know or will know how to disable secure boot and it would not deter them from using Linux if they could do.

What if they're installing it for someone else? Having to find and disable that option is an additional barrier; you'll probably spend the time to do it for your own PC but are more likely to give up on someone else's. Also, what if the other person is a bit naive about downloading programs and would benefit from that protection against malware?

Paying $99 is just supporting and putting Microsoft in a better position than they are now...

The money goes to Verisign, supposedly subsidised by MS.

Well we just edit the kernel... but hang on that windows update last week meant I can no longer disable secure boot....

But you can run it in a VM in which you have a modified UEFI that always says 'Secure Boot is enabled'. The OS cannot verify what the firmware tells it, so this information is not useful for DRM.

Fedora, secure boot, and an insecure future

Posted Jun 20, 2012 19:53 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>The OS cannot verify what the firmware tells it, so this information is not useful for DRM.
That's temporary. The next step is integration with TPM to measure the UEFI integrity.

Fedora, secure boot, and an insecure future

Posted Jun 18, 2012 15:32 UTC (Mon) by josephkliener (guest, #85179) [Link] (2 responses)

Actually it is more than $99.

It is also the wasted time and red hat or community money and resources making a secure boot compatible kernel... this is $100,000's of work and man hours.

Fedora, secure boot, and an insecure future

Posted Jun 18, 2012 19:06 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

What's wrong with the kernel (and other software) being compatible? Should a company or school not be allowed to force that students use their vetted Linux distro/version combo rather than some custom distro? I would like to ensure my servers are using the right versions of things. I'd use my own key, but if we said "Linux shouldn't even support SecureBoot" then this isn't possible. Having a distro get a key from Microsoft or using its own key are separate things.

Fedora, secure boot, and an insecure future

Posted Jun 18, 2012 19:24 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm using my homegrown secure boot + remote attestation solution for physical security of servers containing medical data. Right now it's cobbled from BIOS with TPM support.

Ultimately, secure boot is a good thing. However, the way it's being implemented is far from perfect. By about ten light-years.

Fedora, secure boot, and an insecure future

Posted Jun 21, 2012 6:09 UTC (Thu) by jimbo (guest, #6689) [Link] (1 responses)

Can't we get our own set of keys? This would ensure that we don't have to rely on Microsoft being good guys in the future.

Just how much do UEFI signing keys cost?

--
jimbo

Fedora, secure boot, and an insecure future

Posted Jun 21, 2012 13:10 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Nothing. Then you just have to get every manufacturer to include them. If you want to run a signing service then you'd also need to handle identity verification, key security and revocation. That's likely to cost rather a lot


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds