* Linus Torvalds: > So here's what I would suggest, and it is based on REAL SECURITY and > on PUTTING THE USER FIRST instead of your continual "let's please > microsoft by doing idiotic crap" approach.
I think the real question is this one: Is there *any* device out there which comes with Microsoft Secure Boot enabled, but doesn't have a copy of Windows 8 on it? I guess there isn't. So Secure Boot support is only required for supporting dual-booting Windows 8, while still retaining the automated recovery capabilities (which might well remove the Linux installation on the same box). Without dual-booting, there is currently no reason whatsoever to enable UEFI Secure Boot (or the Microsoft variant). Not providing a signed boot loader forces the user to configure the device in a way that ensures long-term supportability and feature stability (i.e., they don't suffer when someone decides to introduce further restrictions under CAP_COMPROMISE_KERNEL). Unfortuantely, almost all people I talked to *want* secure boot, presumably because security is good. Many of them hate the Microsoft key (but wouldn't want to own the key, either), but the proposed alternatives, such as distro-specific keys, are impractical. Do we really want systems on which you cannot install Fedora once you have installed Debian? > So instead of pleasing microsoft, try to see how we can add real security: > > - a distro should sign its own modules AND NOTHING ELSE by default. I strongly agree with that (but obviously not the wording, *ahem*). Actually, we already sign our own kernel modules (and all the software we ship) in one way or the other. Some of us even sign a lot of third-party software which we haven't built from source. > - 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. This needs a trusted input/output path to the user. Currently, this seems difficult to provide once arbitrary userspace code has run as root. Hence the round-trip through the UEFI pre-boot environment. One thing that would be neat is an assurance that if you boot some image over PXE, it doesn't do any harm to your system. This isn't something Microsoft Secure Boot promises at the moment because a signed boot loader can easily lead to an initrd which wipes your hard disk. It's really hard to get there, but at least it would be something useful. Similarly, server firmware in a datacenter could validate the recovery image before executing. (Actually, I view boot path validation mainly as a server technology—for clients, you just save $1 for the known-good, read-only recovery medium.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
