Matthew Garrett ([personal profile] mjg59) wrote2012-05-30 11:11 pm
Entry tags:

Implementing UEFI Secure Boot in Fedora

Edit 16:17EDT 31/5/12: Clarification of who gets the $99
Edit 02:10EDT 01/6/12: Clarification that it's a one-off payment

(Brief disclaimer - while I work for Red Hat, I'm only going to be talking about Fedora here. Anything written below represents only my opinions and my work on Fedora, not Red Hat's opinions or future plans)

Fedora 17 was released this week. It's both useful and free, and serves as a welcome addition to any family gathering. Do give it a go. But it's also noteworthy for another reason - it's the last Fedora release in the pre-UEFI secure boot era. Fedora 18 will be released at around the same time as Windows 8, and as previously discussed all Windows 8 hardware will be shipping with secure boot enabled by default. While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora. We've been working on a plan for dealing with this. It's not ideal, but of all the approaches we've examined we feel that this one offers the best balance between letting users install Fedora while still permitting user freedom.

Getting the machine booted

Most hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key[1].

We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.

An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.

The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.


We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.

What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.


Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.

Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship, but what about out of tree drivers? We don't have a good answer for that yet. As before, we don't want any kind of solution that works for us but doesn't work for other distributions. Fedora-only or Ubuntu-only drivers are the last thing anyone wants, and this really needs to be handled in a cross-distribution way.

Wait signed what

Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.

But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.

And modules? Again, modules are just code. It's a little trickier, but if your signed kernel loads an unsigned module then that unsigned module can set up a fake UEFI environment and chain into a compromised OS bootloader. Now the attacker just has to include a signed kernel and a minimal initramfs that loads their malware module. It'd slow down boot by a couple of seconds, but other than that it'd be undetectable. X? If you can access the registers on a GPU then you can get the GPU to DMA over the kernel and execute arbitrary code. Trickier again, but still achievable - and if you've locked down every other avenue of attack, it's even attractive.

If we produce signed code that can be used to attack other operating systems then those other operating systems are justified in blacklisting us. That doesn't seem like a good outcome.


A lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys. There's three approaches here. The first is for a user to generate their own key and enrol it in their system firmware. We'll trust anything that's signed with a key that's present in the firmware. The second is to rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling. The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.

But I don't trust Microsoft

A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. Barring firmware backdoors, it's possible to configure secure boot such that your computer will only run software you trust. Freedom means being allowed to run the software you want to run, but it also means being able to choose the software you don't want to run.

You've sold out

We've been working on this for months. This isn't an attractive solution, but it is a workable one. We came to the conclusion that every other approach was unworkable. The cause of free software isn't furthered by making it difficult or impossible for unskilled users to run Linux, and while this approach does have its downsides it does also avoid us ending up where we were in the 90s. Users will retain the freedom to run modified software and we wouldn't have accepted any solution that made that impossible.

But is this a compromise? Of course. There's already inequalities between Fedora and users - trademarks prevent the distribution of the Fedora artwork with modified distributions, and much of the Fedora infrastructure is licensed such that some people have more power than others. This adds to that inequality. It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be.

What about ARM

Microsoft's certification requirements for ARM machines forbid vendors from offering the ability to disable secure boot or enrol user keys. While we could support secure boot in the same way as we plan to on x86, it would prevent users from running modified software unless they paid money for a signing key. We don't find that acceptable and so have no plans to support it.

Thankfully this shouldn't be anywhere near as much of a problem as it would be in the x86 world. Microsoft have far less influence over the ARM market, and the only machines affected by this will be the ones explicitly designed to support Windows. If you want to run Linux on ARM then there'll be no shortage of hardware available to you.

Is this all set in stone?

No. We've spent some time thinking about all of this and are happy that we can implement it in the Fedora 18 timescale, but there's always the possibility that we've missed something or that a new idea will come up. If we can increase user freedom without making awful compromises somewhere else then we'll do it.

[1] In fact, chances are that everything will carry the Microsoft key. Secure boot requires that UEFI drivers also be signed. The signing format only permits a single signature per binary. For compatibility, approximately all add-on hardware shipped will be signed with Microsoft's key, and that means that all system vendors have to recognise Microsoft's key in order to permit that hardware to run on their systems.
[2] Current source is here. It relies on a port of the UEFI crypto library and OpenSSL that I have building with some handholding, and which I'll upload as soon as possible.

[identity profile] 2012-05-31 06:24 am (UTC)(link)
I don't understand how I could use a signed Linux system to "attack Windows" when Windows isn't running?

More importantly, doesn't the GPL require that you provide sufficient source to reconstruct the binary artefacts that constitute the program? (We now proceed to argue about what constitutes a "program" that isn't executable code). Either I can modify the kernel (in which case I don't understand the point of this signature chaining being _required_) or I can't (in which case it's a GPL violation to distribute it).

I may also be confused about how mandatory all this is.

Re: list of kernel restrictions?

(Anonymous) - 2012-06-01 05:38 (UTC) - Expand

Re: list of kernel restrictions?

(Anonymous) - 2012-06-01 08:10 (UTC) - Expand


(Anonymous) - 2012-05-31 07:13 (UTC) - Expand


(Anonymous) - 2012-05-31 19:37 (UTC) - Expand


(Anonymous) - 2012-06-01 00:53 (UTC) - Expand

Stop this nonsense now!

(Anonymous) - 2012-06-04 11:41 (UTC) - Expand

Re: Stop this nonsense now!

(Anonymous) - 2012-06-06 23:16 (UTC) - Expand

Re: Stop this nonsense now!

(Anonymous) - 2012-07-20 01:58 (UTC) - Expand


(Anonymous) - 2012-06-02 01:03 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-01 03:05 (UTC) - Expand

(no subject)

(Anonymous) - 2012-07-13 19:35 (UTC) - Expand

(no subject)

(Anonymous) - 2012-12-30 15:55 (UTC) - Expand


(Anonymous) - 2012-06-01 10:14 (UTC) - Expand

(Anonymous) 2012-05-31 06:35 am (UTC)(link)
Thanks for the highly informative post!

I've got a question which could possibly be answered by the site were it not "offline for maintenance" right now.

You say users can "rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling." But without audits and strict rules for how they use and handle their own signing keys, it seems like this makes the whole system completely useless. It would be as if the Certificate Authorities of the https PKI sold subordinate roots willy-nilly (which it turns out they actually do, but for a whole lot more than $99 and they don't advertise it to the general public!). What am I missing here?

Also, what is Fedora's plan if Microsoft changes these terms of their $99 signing program to exclude you?

(no subject)

(Anonymous) - 2012-05-31 06:54 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-01 14:39 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-03 08:33 (UTC) - Expand

(no subject)

(Anonymous) - 2012-05-31 15:01 (UTC) - Expand

(no subject)

[identity profile] - 2012-05-31 15:29 (UTC) - Expand

win update mod firmware?

(Anonymous) - 2012-05-31 19:41 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-05 15:33 (UTC) - Expand

risk management

(Anonymous) - 2012-06-06 01:41 (UTC) - Expand

Blacklist key

(Anonymous) - 2012-06-24 11:54 (UTC) - Expand


(Anonymous) - 2012-05-31 19:36 (UTC) - Expand

(Anonymous) 2012-05-31 06:47 am (UTC)(link)
One thing is not clear to me: Does "signing by Microsoft" mean that Fedora will provide Microsoft with the binary bootloader and Microsoft will return what Fedora can only hope is a signed, but otherwise unmodified copy of it, or will Microsoft provide a signing key that the Fedora project can use to sign its bootloader using open-source software?

Because the first option, to be quite frank, sounds beyond unacceptable to me.

signed doesn't mean encrypted

(Anonymous) 2012-05-31 07:50 am (UTC)(link)
as I understand it the binary would be inspectable and comparable to the original, there would be a signature portion added which is a kind of hash of the binary and the signing key, which can be verified against the public portion of the Microsoft key and the binary itself. No real scope for Microsoft to return a modified binary.

checking the signed binary

(Anonymous) - 2012-05-31 13:28 (UTC) - Expand

Re: checking the signed binary

(Anonymous) - 2012-05-31 14:41 (UTC) - Expand

Re: checking the signed binary

(Anonymous) - 2012-05-31 15:52 (UTC) - Expand

Re: checking the signed binary

[personal profile] cpanceac - 2012-06-17 07:26 (UTC) - Expand
If we can run virtualization software in Linux, couldn't it also set up a fake-secure EFI VM and boot Windows inside it? Does this mean VirtualBox must be prevented from running on a secure boot system?

Re: Virtualization

(Anonymous) 2012-05-31 08:45 am (UTC)(link)
Note that hardware virtualization is not necessary for this attack, something DosBox-like would be enough.

In such a system it seems to be always possible to trick software into thinking it is running on bare metal. Is there something else (e.g. some hardware device) that would not work in such a situation?

Re: Virtualization

(Anonymous) - 2012-05-31 18:25 (UTC) - Expand

Re: Virtualization

(Anonymous) - 2012-06-01 12:04 (UTC) - Expand

Re: Virtualization

(Anonymous) - 2012-05-31 13:23 (UTC) - Expand

Re: Virtualization

(Anonymous) - 2012-05-31 14:11 (UTC) - Expand

Re: Virtualization

(Anonymous) - 2012-05-31 14:31 (UTC) - Expand

Re: Virtualization

[personal profile] novalis - 2012-05-31 16:48 (UTC) - Expand


(Anonymous) 2012-05-31 08:02 am (UTC)(link)
Everythin about this seems to be overly complicated for very little gain. Freedom from users is severely limited whereas protection is not that much improved.

In order for all of this to be useful, you need to be able to blacklist some keys. I'm not sure how this would work, is it possible to just update the list or do you have to flash a new EFI? Who can update the list, only Microsoft? Could you blacklist the Microsoft key?

Obviously, once a key is blacklisted, all OSes using that key won't be able to boot. If it's a malware, you just won't be able to boot your OS (obviously a malware would remove the official signed bootloader and put his own one).

So in the end I guess it's a technology that will only be able to protect Microsoft Windows, and I'm not even sure that the threat is that great. Do we have numbers about the quantity of bootloader-level malware out there? The only benefit I see is that Microsoft Windows users will know that their OS is compromised right away (by not booting at all) instead of the OS to be able to make bad things unnoticed.

Will bare motherboards (to build a custom computer) include Microsoft keys as well? If all computers start to use locked-down bootloaders, it will be a pain to install other OSes on all x86 hardware (except Apple hardware I guess, which would be overly weird since Apple is one of the most closed-down OS out there).

Re: Complexity

(Anonymous) 2012-05-31 01:30 pm (UTC)(link)
The blacklist is a UEFI variable that can only be updated under certain conditions. It's possible to ship a signed blob that can add things to the blacklist, so it's possible to distribute an addition to the blacklist that's both verifiable and portable.

It'll protect us some as well, though the idea of using Linux to attack windows may cause an increase the number of attempts against Linux systems.

Motherboards that carry the windows 8 client logo must include Microsoft keys. Others may at their option.

-- pjones

Re: Complexity

(Anonymous) - 2012-05-31 14:55 (UTC) - Expand

Re: Complexity

(Anonymous) - 2012-05-31 15:16 (UTC) - Expand

Re: Complexity

(Anonymous) - 2012-05-31 14:37 (UTC) - Expand

Re: Complexity

(Anonymous) - 2012-05-31 16:24 (UTC) - Expand

Re: Complexity

(Anonymous) - 2012-05-31 20:00 (UTC) - Expand

Re: Complexity

(Anonymous) - 2012-06-06 22:38 (UTC) - Expand

Fedora revocation

(Anonymous) 2012-05-31 08:45 am (UTC)(link)
Will we need to also set up a revocation system that prevents booting old and known-vulnerable kernels?

Options are not mutually exclusive

(Anonymous) 2012-05-31 08:58 am (UTC)(link)

You've talked about each of the options as if they were mutually exclusive. They aren't, you should consider implementing all of them. This should be considered security defence in depth, preparation, for the inevitable day when Microsoft changes the key signing rules.

In particular you should be giving as many manufacturers as possible a Fedora key and a linux key so they become accustomed to the idea of working with people other than Microsoft and you actually have some say when Microsoft changes the rules. I assume that you are aware that Microsoft is "boiling the frog". You should be doing your best to minimize this - think long term and not just the next release.

Re: Options are not mutually exclusive

(Anonymous) 2012-05-31 01:38 pm (UTC)(link)
That's one of the reasons I've been working on signing tools. In the event of some major policy shift - or the case that you don't trust Microsoft at all - at the very least you'll be able to sign your own bootloader for your systems. The current tool is at github ( There's not much documentation just yet, but I'll be working on that sometime in the upcoming weeks.

-- pjones

Re: Options are not mutually exclusive

(Anonymous) - 2012-05-31 14:21 (UTC) - Expand

Re: Options are not mutually exclusive

(Anonymous) - 2012-06-08 08:22 (UTC) - Expand

Re: Options are not mutually exclusive

(Anonymous) - 2012-06-01 16:27 (UTC) - Expand

[identity profile] 2012-05-31 09:06 am (UTC)(link)
Can secure boot and kexec work together? Any plans to instrument kexec to check signatures?

(Anonymous) 2012-05-31 09:09 am (UTC)(link)
Current versions of GNU GRUB2 uses GPLv3, not GPLv2. Thus, by producing a signed version of GRUB2 and distributing it, you've incurred an obligation to supply your signing keys so that people can produce modified binaries.

(no subject)

(Anonymous) - 2012-05-31 12:05 (UTC) - Expand

(no subject)

[identity profile] - 2012-05-31 12:16 (UTC) - Expand

(no subject)

[personal profile] simont - 2012-05-31 12:17 (UTC) - Expand

Intent of distribution counts?

(Anonymous) - 2012-05-31 19:14 (UTC) - Expand

Re: Intent of distribution counts?

(Anonymous) - 2012-06-01 03:20 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-02 01:02 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-03 05:03 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-04 16:01 (UTC) - Expand

(no subject)

(Anonymous) - 2012-06-03 05:15 (UTC) - Expand

(no subject)

(Anonymous) - 2012-05-31 12:40 (UTC) - Expand

(no subject)

(Anonymous) - 2012-05-31 21:39 (UTC) - Expand

What about tracing modules?

(Anonymous) 2012-05-31 09:18 am (UTC)(link)
What about debugging and tracing tools that use kernel modules like systemtap? Where does the user get the right signing key from to insert the instrumentation into the kernel?

Re: What about tracing modules?

(Anonymous) - 2012-05-31 12:14 (UTC) - Expand

Re: What about tracing modules?

(Anonymous) - 2012-06-01 05:52 (UTC) - Expand

Re: What about tracing modules?

(Anonymous) - 2012-06-01 12:20 (UTC) - Expand

Re: What about tracing modules?

(Anonymous) - 2012-06-01 19:07 (UTC) - Expand

Re: What about tracing modules?

(Anonymous) - 2012-06-07 09:37 (UTC) - Expand

Re: What about tracing modules?

(Anonymous) - 2012-05-31 13:10 (UTC) - Expand

Re: What about tracing modules?

(Anonymous) - 2012-06-01 13:19 (UTC) - Expand

What if Microsoft won't sign the bootloader?

(Anonymous) 2012-05-31 11:53 am (UTC)(link)
Apart from a theoretical agreement cooked up by lawyers between Microsoft and RedHat, there is no guarantee that Microsoft will sign anything. Or at some point it will refuse to sign anything or provide any other arbitrary chosen reason why it will not sign the bootloader. Or it will commonly blacklist these, so dual boot will not work.

I do understand that this is the easy way, disabling secure boot is an option, setting up own key is an option. However, if that happens, the damage will be done. Is there any reason for going down that route?

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 12:11 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 12:45 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 13:17 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 13:38 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 14:18 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 14:36 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 20:10 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 12:45 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-05-31 15:15 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-06-01 12:26 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-06-01 05:56 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-06-03 05:24 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-06-08 08:34 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-06-03 05:20 (UTC) - Expand

Re: What if Microsoft won't sign the bootloader?

(Anonymous) - 2012-06-20 19:19 (UTC) - Expand


[identity profile] 2012-05-31 11:56 am (UTC)(link)
While this doesn't seem like the most palatable option, it does look like a workable one. Thanks for keeping an eye out for this and doing the dirty work!

Best Regards, David

Re: Thanks

(Anonymous) 2012-05-31 12:42 pm (UTC)(link)
I don't believe it is workable as it basically means users can't build and develop their own kernels. Nor is it IMHO likely to be lawful given that the GPLv2 requires the necessary install scripts and the like are provided.

It will be a good reason to dump Fedora as Fedora will no longer be free or open source software at that point, nor able to run third party modules or many debugging tools.

Re: Thanks

(Anonymous) - 2012-05-31 12:48 (UTC) - Expand

Re: Thanks

(Anonymous) - 2012-05-31 23:53 (UTC) - Expand

Re: Thanks

(Anonymous) - 2012-05-31 15:30 (UTC) - Expand

Re: Thanks

(Anonymous) - 2012-05-31 19:52 (UTC) - Expand

Certificate instead of shim code with embedded signature

(Anonymous) 2012-05-31 12:44 pm (UTC)(link)
I guess I should wait for to come back up, but I can't help but wonder why they wouldn't just sign certificates that the firmwares would use to in turn verify the signatures of the bootloaders. I don't know the capabilities of EFI, but these certificates could be stored anywhere, most logically on EFI system partitions (or whatever they're called). It would remove the need for the shim code, which does look like a bit of a technical kludge to me.

Did I miss something?

Grub 2 and Compatibility Support Modules

(Anonymous) 2012-05-31 01:15 pm (UTC)(link)
Is Grub 2 fully EFI capable? It's my understanding that SecureBoot requires the legacy Compatibility Support Modules to be disabled, so anything that executes as a boot loader or that is chained to by one has to work without CSMs, right?

(also, thank you for your posts. You're the guy documenting and solving these difficult problems for the rest of the planet :) )

Signed FSF's petition yet?

(Anonymous) 2012-05-31 01:47 pm (UTC)(link)
For anyone who doesn't like what MS is doing, the least you can do is sign FSF's petition:

28,000 signatures so far. Pass it on.

CiarĂ¡n O'Riordan

An wath happend if

(Anonymous) 2012-05-31 02:46 pm (UTC)(link)
Wath happend if a judge in any country declare MICROSOFT signed violate the GPL?
and/or say Linux only can provide they own and unique key and companig can select if add or not them?

The signing format only permits a single signature per binary?

[identity profile] 2012-05-31 03:20 pm (UTC)(link)
"The signing format only permits a single signature per binary."

That sounds like a large piece of brokenness. Is it too late to fix it? If it is, in hindsight, what standard was it and what year was it when we should have seen this coming and objected?

what about video driver blobs?

[identity profile] 2012-05-31 04:05 pm (UTC)(link)
Any idea what amd / nvidia are planning to do with their linux blobs in the secure-boot world?

Re: what about video driver blobs?

(Anonymous) - 2012-06-01 00:34 (UTC) - Expand

Re: what about video driver blobs?

(Anonymous) - 2012-06-01 01:28 (UTC) - Expand

Re: what about video driver blobs?

(Anonymous) - 2012-06-01 06:19 (UTC) - Expand

Re: what about video driver blobs?

(Anonymous) - 2012-06-03 05:31 (UTC) - Expand

Re: what about video driver blobs?

(Anonymous) - 2012-06-06 02:05 (UTC) - Expand

Totally unacceptable

(Anonymous) 2012-05-31 04:17 pm (UTC)(link)
This completely unacceptable to me. I'm very disappointed with Redhat. Redhat is a billion dollar company with a large market share in the server market, therefore has a lot of influence on hardware manufactures (a lot of server manufacturers also make laptops and desktops), therefore Redhat should have used its influence to force a solution that would be acceptable to the FOSS world. I will NEVER buy any hardware where 'secure boot' cannot be FULLY DISABLED (either by a BIOS option or by flashing a custom BIOS or with a hardware dip-switch) and if that means I will be stuck with 2012 hardware then so be it.

Re: Totally unacceptable

(Anonymous) 2012-05-31 04:34 pm (UTC)(link)
Note that this currently only applies to machines certified with the Windows 8 "Client" logo. Servers aren't included. I'll let you reach your own conclusions as to why.

-- pjones

Re: Totally unacceptable

(Anonymous) - 2012-05-31 17:30 (UTC) - Expand

Re: Totally unacceptable

(Anonymous) - 2012-05-31 19:50 (UTC) - Expand

Re: Totally unacceptable

(Anonymous) - 2012-05-31 21:16 (UTC) - Expand

Re: Totally unacceptable

(Anonymous) - 2012-05-31 23:08 (UTC) - Expand

Re: Totally unacceptable

(Anonymous) - 2012-06-03 05:35 (UTC) - Expand

Re: Totally unacceptable

(Anonymous) - 2012-06-04 16:14 (UTC) - Expand

Re: Totally unacceptable

(Anonymous) - 2012-06-18 08:28 (UTC) - Expand

Re: Totally unacceptable

(Anonymous) - 2012-07-04 11:45 (UTC) - Expand

Generic Linux Key

(Anonymous) 2012-05-31 05:07 pm (UTC)(link)
Relying on this Microsoft signing service for more than one or two releases would be a mistake in my opinion. However, I realize that setting up your own CA is an expensive and risky option. Have you tried approaching any existing CAs to see if they would be willing to manage a generic Linux root cert? StartCom in particular would be a good one to talk to, since they have their own Linux distro.

Re: Generic Linux Key

(Anonymous) 2012-06-06 02:16 am (UTC)(link)
A custom CA is much less useful if the CA's root cert is not installed the UEFI images shipped with hardware. And since the UEFI format does not allow multiple signatures on a binary, an OS has two choices:

1) Use the Microsoft key that ALL consumer hardware is going to have, and hence always work.
2) Use a Linux CA that a small fraction of hardware is going to have, and hence only work on a small fraction of hardware

The vast, VAST majority of Linux users get started out of pure curiosity, and just to tinker. They do not usually start out as Free Software supporters (yes, exceptions exist, and I don't care about your personal anecdotes) until _after_ they're exposed in depth to Free Software. Making it hard for novice users to even give Linux a try means that the Linux adoption rate will go from it's current snail pace to (worst case) a sub-1.0 rate (as in, less users come in than leave, due to age or those of us who just give up on Linux ever being a truly competetive desktop OS).

Paying Microsoft

(Anonymous) 2012-05-31 06:19 pm (UTC)(link)
I'm sorry to hear that Fedora is going to be paying Microsoft. I never thought I'd see that.

Re: Paying Microsoft

(Anonymous) 2012-06-01 01:39 am (UTC)(link)
This is an outrage. I can't believe there isn't a way to get around this ridiculous crap that Microsoft has schemed up this time. I totally respect Red Hat and its decision, and am an avid Fedora user. I hope Linux continues to take over the server market as recent numbers have shown, while Microsoft eats their own garbage and tries to go after everybody over software patents.

One time $99 fee...

(Anonymous) 2012-05-31 07:16 pm (UTC)(link)
"it would mean finding an entity who was willing to take responsibility for managing signing or key distribution [...] nobody was jumping at the opportunity to volunteer."

But that is, essentially, what Microsoft are charging the $99 for. I'm sure folks at Microsoft believe they're doing this for a good cause, but of course it'll eventually turn into a clusterf*k when their suits decide to see if their competition can survive without hardware support longer than it takes to get to court...

Re: One time $99 fee...

[identity profile] gua [] 2012-05-31 09:32 pm (UTC)(link)
I do wonder why Intel+AMD or the various firmware vendors aren't stepping up to make a http://FirmwareKeySigning.example service, since they're the ones having to follow all of this.

Is no firmware vendor questioning whether or not Microsoft is the best entity to do the signing?

Re: One time $99 fee...

(Anonymous) - 2012-06-01 15:13 (UTC) - Expand

Re: One time $99 fee...

(Anonymous) - 2012-06-02 21:02 (UTC) - Expand

Re: One time $99 fee...

(Anonymous) - 2012-06-11 21:43 (UTC) - Expand

How will RHEL handle the problem?

(Anonymous) 2012-05-31 07:23 pm (UTC)(link)
Will the RHEL clones (Scientific Linux, CentOS) have to register their own keys with Microsoft or will Redhat allow them to use the RHEL keys?

Re: How will RHEL handle the problem?

(Anonymous) 2012-05-31 07:45 pm (UTC)(link)
We won't be in a position to allow them. Even if we wanted to (which I doubt) we wouldn't be able to procedurally.

-- pjones

Just say NO. Loudly, and clearly.

(Anonymous) 2012-05-31 07:45 pm (UTC)(link)
The minute a Linux vendor sells-out -- like this -- is the minute we're all doomed.

MS will lead them on for a couple of years, and then quietly insist that x86 vendors comply with the same restrictions that ARM vendors have already kowtowed to.

At which point, only Redhat Linux will boot and run. No others. Or at least not until all of the others also sign-up and pay MS for permission to run non-MS software on end-user hardware.

Then, a year or two later, MS will raise the signing fees, and eventually begin blacklisting Linux systems for various "reasons".

By then, it's too late to do anything about the situation.

Much, MUCH better to just not comply from Day-1. Don't pay MS for key-signing. This means that a user has to enter the BIOS *once* to get Linux installed. Big Deal.

Hardware vendors will be loath to ever implement stage-2 as a result -- they'll refuse to disable non-secureboot because it would lock them out of the Linux market.

But if we pay-up to MS on Day-1, then the hardware vendors will not have as big an issue with locking everyone out later on.

Just say NO. This is a very clever MS scheme, and an very bad idea for Redhat to comply.

Re: Just say NO. Loudly, and clearly.

(Anonymous) 2012-05-31 07:53 pm (UTC)(link)
Well said, I 100% agree with this.

Re: Just say NO. Loudly, and clearly.

(Anonymous) - 2012-05-31 21:18 (UTC) - Expand

Re: Just say NO. Loudly, and clearly.

(Anonymous) - 2012-05-31 21:59 (UTC) - Expand

Re: Just say NO. Loudly, and clearly.

(Anonymous) - 2012-06-03 05:37 (UTC) - Expand

Re: Just say NO. Loudly, and clearly.

(Anonymous) - 2012-06-04 21:47 (UTC) - Expand

Re: Just say NO. Loudly, and clearly.

(Anonymous) - 2012-06-06 02:23 (UTC) - Expand

Re: Just say NO. Loudly, and clearly.

(Anonymous) - 2012-06-05 20:51 (UTC) - Expand

Time to make calls to your congressional representative.

(Anonymous) 2012-05-31 07:48 pm (UTC)(link)
It's interesting that RedHat is not going to the government claiming anti-trust. I wonder if their plan is to just pay Microsoft some hush money to allow another OS install option? I also don't see how secure boot will make things any safer in the Windows world or Unix Like OS world.

Re: Time to make calls to your congressional representative.

(Anonymous) 2012-06-01 03:52 am (UTC)(link)
I won't be affected. I have stopped buying machines designed to run windows. Now, i run legacy windows OSes to run legacy software in VMs. It feels like we are going full circle. How long before we start buying Microsoft clones? It is starting to feel like the 80s all over again.

regarding blindness...

(Anonymous) - 2012-06-02 03:12 (UTC) - Expand

Re: regarding blindness...

(Anonymous) - 2012-06-02 22:14 (UTC) - Expand

Page 1 of 4

<< [1] [2] [3] [4] >>