That said, there still needs to be some way to deal with the necessary evil of Secure Boot key management. Or, does there?
Part of the concern driving the desire to manage Secure Boot at a low-level in Linux is that a Microsoft-signed, Linux Secure Boot key might be used to hack systems. If that were to happen, some developers fear that Microsoft would disable the key. This would have the effect of disabling Linux PCs using that Secure Boot key. And, no one wants that.
But how serious is this threat? James Bottomley, CTO of Server Virtualization at Parallels and the Linux kernel developer behind the Linux Foundation UEFI pre-bootloader, told me that he discounts the arguments that "Microsoft will blacklist our key argument"
"There are two points to consider here: firstly we don't have a key: if you look at shim and my PreBootloader, they're actually signed with the *same* key. That means that there's no real distro-specific key to blacklist. Secondly, Microsoft isn't going to get into the business of policing Linux security. What they've told us privately is that as long as no-one comes along with a plausible exploit for Windows based on using a secure boot enabled Linux system, they don't care what we do. This 'plausible exploit' has to be some way of getting ordinary Windows users to run the code and become compromised, it's not an experienced Linux user becoming root and subverting Windows on their local box."
Other senior Linux kernel developers agreed with Bottomley. Ted Ts'o wrote:
"Microsoft would take a severe hit both from a PR perspective, as well as incurring significant legal risks if they did that in certain jurisdictions --- in particular, I suspect in Europe, if Microsoft were to break the ability of Linux distributions from booting, it would be significantly frowned upon."
Greg Kroah-Hartman, another prominent Linux kernel programmer, wrote that he doesn't buy Garrett's interpretation of what Microsoft wants. "I fail to see how Microsoft should be dictating how Linux, or any other operating system, works, especially when they aren't even signing the kernel, they are merely signing a bootloader shim and saying 'do your best for keeping the rest of the system secure please.' "
"We do need pieces in the kernel to exploit secure boot in a way that users can take advantage of, so signed modules is definitely part of that. The only bit I don't buy is the lock root out of modifying the hardware approach because I can't really see a use case for it outside of 'we think this will make Microsoft happy.'"
Torvalds then goes on, in his own take-no-prisoners style, to suggest a plan on how to deal with Secure Boot signed keys and modules, which "is based on REAL SECURITY and on PUTTING THE USER FIRST instead of your continual 'let's please Microsoft by doing idiotic crap' approach.' "
A distro should sign its own modules AND NOTHING ELSE by default. And it damn well shouldn't allow any other modules to be loaded at all by default, because why the f*ck should it? And what the hell should a Microsoft signature have to do with *anything*?
Before loading any third-party module, you'd better make sure you ask the user for permission. On the console. Not using keys. Nothing like that. Keys will be compromised. Try to limit the damage, but more importantly, let the user be in control.
Encourage things like per-host random keys--with the stupid UEFI checks disabled entirely if required. They are almost certainly going to be *more* secure than depending on some crazy root of trust based on a big company, with key signing authorities that trust anybody with a credit card. Try to teach people about things like that instead.
Encourage people to do their own (random) keys, and adding those to their UEFI setups (or not: the whole UEFI thing is more about control than security), and strive to do things like one-time signing with the private key thrown out entirely. IOW try to encourage *that* kind of "we made sure to ask the user very explicitly with big warnings and create his own key for that particular module" security. Real security, not "we control the user" security.
Torvalds concluded, "It really shouldn't be about Microsoft blessings, it should be about the *user* blessing kernel modules. Quite frankly, *you* are what the key-hating crazies were afraid of. You peddle the "control, not security" crap-ware. The whole "Microsoft owns your machine" is *exactly* the wrong way to use keys."
So the first order should be: "we provide modules to cover all normal users". You use the RH [Red Hat] key for that.
The *second* order should be: "we encourage and tell people how to add their own keys and sign modules they trust".
The third order should probably be "we encourage people to use random one-time keys - probably with UEFI key checking turned off entirely, because let's face it, that doesn't really add any real security for most people". It's what kernel developers and most servers would probably want to use. They likely don't do the whole UEFI crap anyway, and random one-time keys are actually better against things like rootkits etc than *any* centrally administered chain of trust.
Only somewhere really really deep down should the "OK, what about a MS signature" thing be. It could be part of the user-level application (part of your distribution) that displays the "Are you really sure you want to load this module with an unrecognized signature? I can tell that it has a MS signature on it". But by the time you get this far, you've already failed the first few normal levels.
So, there you have it. Until you pry Torvald's cold dead fingers from Linux, Microsoft Secure Boot keys and signed binary modules are not going to be in the Linux kernel.
You will, however, be able to use these to install and boot Linux on Windows 8 PCs; but that will be done in userspace, not Linux's heart. And, if you really want to load Microsoft-signed drivers, such as hypothetical, future binary-only graphics drivers from Nvidia or ATI/AMD, you'll be able to do that too as well. It just won't be incorporated to automatically happen in Linux's core functionality.