Torvalds strongly objects to Windows 8 secure boot keys in the Linux kernel

Torvalds strongly objects to Windows 8 secure boot keys in the Linux kernel

Summary: Linux founder Linus Torvalds makes no bones about it. He thinks inserting signed binaries into the Linux kernel is "moronic."


It started innocently enough. Red Hat software engineer David Howells asked Linus Torvalds, Linux's founder, to move on code that would let Microsoft-signed binary keys be added dynamically to a kernel while running in secure-boot mode on the Linux Kernel Mailing List (LKML). Torvalds wasn't having it. "Quite frankly, this is f*cking moronic."

Torvalds-2012-San Diego
Linux Torvalds and Bruce Banner, aka the Hulk, "You wouldn't like me when I'm angry."

Specifically, Howells was asking "to embed an X.509 certificate containing the key in a section called '.keylist' in an EFI PE [Extensible Firmware Interface Portable Executable] binary and then get the binary signed by Microsoft." Howell was asking for this so that Linux users can add keys with new Linux software in Windows 8 PCs' UEFI Secure Boot prisons. These keys would be needed to help properly boot Linux that needed to use proprietary, binary-only drivers such as some graphic chipsets from AMD and Nvidia.

Like it or lump it, the easiest ways to get Linux installing or running on Windows 8 PCs with Secure Boot all involve using Microsoft signed UEFI keys.  Matthew Garrett, a Linux UEFI expert and creator of the shim boot method used by Red Hat, pointed out that these keys are only available from Microsoft as PE binaries.

As anyone who follows Linux closely knows, Linux developers have no love for programs that have no source code and are only available as binaries. It goes against the very grain of open-source software. While most Linux users and programmers will grudgingly use such binaries as proprietary graphic and Wi-Fi drivers, the closer a binary comes to the Linux core, to the kernel itself, the less they like it.

Thus, it shouldn't have come as no surprise when Torvalds blew up.

If you want to parse PE binaries, go right ahead.

If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.

Why should *I* care? Why should the kernel care about some idiotic "we only sign PE binaries" stupidity? We support X.509, which is the standard for signing.

Do this in user land on a trusted machine. There is zero excuse for doing it in the kernel.

Garret responded, "Vendors want to ship keys that have been signed by a trusted party. Right now the only one that fits the bill is Microsoft, because apparently the only thing vendors love more than shi**y firmware is following Microsoft specs. The equivalent isn't just Red Hat (or anyone else) programmatically re-signing those keys, it's re-signing those keys with a key that's trusted by the upstream kernel. Would you be willing to carry a default trusted key if some sucker/upstanding and trustworthy member of society hosted a re-signing service? Or should we just assume that anyone who wants to ship external modules is a f*cking idiot and deserves to be miserable?"

Torvalds fired back, "Quite frankly, I doubt that anybody will ever care, plus getting me to care about some vendor that ships external binary-only modules is going to be hard as hell."

Garrett replied that he can't see Red Hat getting into the key signing business. Peter Jones, a Red Hat software engineer and member of the Fedora Engineering Steering Committee, agreed: " Red Hat will not sign kernel modules built by an outside source. We're simply not going to sign these kernel modules. That's one of the big reasons we want a setup where they can sign their own modules in the first place."

In any case, the real issue, as Garrett sees it, is that "RHEL's [Red Hat Enterprise Linux] is going to end up trusting keys owned by Nvidia and AMD [makers of the most popular graphic chipsets] somehow, and chances are that's going to be based on the Microsoft signing service. The question is whether there's a benefit in ensuring that the same key is trusted by RHEL, Ubuntu, Suse and everyone else or whether different kernels are going to have completely different policies." Hence, Red Hat and Garrett's desire to have a means of dealing with this in the common Linux kernel.

The issue has died down for now, which I take as meaning that Torvalds has won the day. Be that as it may, booting Linux on Windows 8 PCs with Secure Boot active is still a headache -- and dealing with binary drivers will only make it more so.

We can only hope, as Ted Ts'o, a core Linux kernel developer said, that "this whole code signing insanity" … "is completely overblown."

Related Stories:

Topics: Linux, Hardware, Laptops, Open Source, Operating Systems, Software Development, PCs, Windows 8

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Keys are UEFI, not Windows 8

    Windows 8 keys would have no use in Linux.

    However Linux could get their own keys for UEFI from a certification organization and make deals with PC manifacturers to recognize those keys in their UEFI driven hardware.

    Those would thus be Linux secure boot keys
    • Doesn't work.

      MS won't allow keys other than its own.
      • It says that where?

        "MS won't allow keys other than its own."
        William Farrel
        • Try putting a key in then.

          You can't do it.

          MS express requirement is that it not be accessible.
          • Wrong, that is exactly how it is done.

            If you use a key that meets the specification then you can make it work and that is how people are doing it. But right now you have to use the binary and for good reason OS people don't like that.
          • no you don't.


            you can't.
      • Not the problem, it is, as the article said getting a key from a trusted...

        Certification company. In this UEFI space the only company that people currently trust IS MS. There isn't anyone else out there doing it. It isn't that other companies couldn't do it, they can. It is a specification and as long as it meets the specification it will work. The problem is that no one wants to do it. RH is large enough to do it i.e. people would trust them but they don't want to. That leaves MS right now as the only source of trusted certificates. This may change but until it does LINUX people are left with binaries or making the choice not purchase systems that enable UEFI
        • If that's the case...

          ...Then one can't get a system with Windows 8 already installed on it, as the specs for PC's to me Microsoft certified for that OS specifically require a UEFI firmware with Secure Boot enabled by default.
    • Huh?

      So just WHO do you think supplies those UEFI keys? Oh, that's right! Microsoft! AND they ONLY supply those keys in binary form - no source code. And somehow this is the fault of the open source community?
      • MS has nothing to do with it. This is just between the oems and linux maker

        It's not MSs fault oems and Linux vendors aren't playing nice together.
        Johnny Vegas
        • Oems not much to do with it.

          Hi :)
          Seems like someone is a little confused. MS is forcing the issue. OEMs would be quite happy without the mis-named "Secure Boot" which is not even all that secure.
          Regards from
          Tom :)
          • You are the one who is confused

            Linux vendors (distros) could work with oems to have the systems ship with their keys as well. But they don't bother because there are *many* oems and maintaining such an ecosystem is hard work. You are not done when the key has been delivered. You have to run a vetting operation, a revocation service etc.

            The Linux Foundation could do it. It would right in line with their stated purpose. But they have declined as well.

            Microsoft has enough clout with the oems to have *their* key in registered in the system, and they have the infrastructure to run such an operation. They already (as the only mainstream OS vendor) sign 3rd party kernel drivers to ensure that only trusted code can be loaded with into the kernel.

            Garetts idea was to have *Microsoft* sign a shim bootload'er. If it adheres to Microsofts conditions (presumably it must be obvious that an alternative OS is being boot'ed) for such a bootload'er, Microsoft has stated that they'll sign it for a fee of $99 per signing.

            Essentially the bootload'er would piggyback on Microsofts digital key infrastructure, removing the need to have a *Linux* key in every system.

            However, still *nothing* prevents the distros from working with the the OEMs. Also, users/owners of systems with UEFI secure boot can switch it off *or* they can register a key provided by a distro.

            The latter would *theoretically* allow a distro to reap the same security benefits as Windows now have on secure boot systems: A trusted path from the cold boot until the OS has control of the system. Linux is not quite there yet with only partial ability to sign files (only executables) and insufficient support for hibernation etc.

            Note how *both* Linus Torvalds *and* Kroah-Hartmann actually *like* the idea of a secure (trusted) boot path.

            >>>mis-named "Secure Boot" which is not even all that secure.

            Could you explain that, please? How would you bypass a Windows secure boot system? Or are you just pushing FUD and conjecture?
          • Well...

            I mostly agree with you. I think the problem with Linux Foundation or *any* open source group is that the key has to be secure i.e. not-open. For open-source the source has to be available but if the source to the signing binary is available it can't be trusted anymore. They are going to have to work around this conundrum.

          Obviously, you have NEVER READ a MICROSOFT OEM AGREEMENT.
  • I actually agree with Linus on this

    If Linux starts to use Microsoft binaries, it may as well just just be abolished. I am a fan of Windows 8 and Mircrosoft, but the idea that they have control over hardware (other than their own) in this way as well is not something I can support.

    No real fan of Linux, but Torvalds is right to be principled on the issue. Otherwise he may as well just give up now.
    • To a degree.

      But I don't like how they are blaming Microsoft for their problem. If they want a UEFI key they will have to organise it with the OEMs just as Microsoft has done. Microsoft are offering these guys help by giving them presigned binaries which eliminates the need for them to a) do it theirself and b) get OEMs to hard code their keys.

      Don't want secure boot? Don't have it. This issue is being so beat up. Do what you have always done before, don't use secure boot. It really is that simple.
      • Microsoft demanded that UEFI have secure boot.

        The whole concept of secure boot comes from Microsoft, also Linux is a free and open source operating system, why on earth should Linux distributions have to pay OEMs to have their key incorporated into the firmware. It puts a artificial cost of Linux, which should never exist in the first place if Microsoft actually knew anything about Security.

        Secondly the reason we blame Microsoft is because they are forcing OEMs to have Secure Boot enabled by default which goes against why Free and Opensource Software exists.

        So we don't have a choice whether to use Secure boot, and IMHO this should be investigated by the anti-trust organizations, and Microsoft should loose their business licence for this.
        • Secure boot doesnt go against foss. It'd be good for foss to have.

          No one said Linux makers had to pay oems any artificial cost. It's not MSs fault Linux makers and oems aren't playing nice together on this. And MS knows a lot about security, Windows is very secure. More secure than Linux at this point.
          Johnny Vegas
          • More secure?

            Secure boot mean no unsigned driver, which means no open source drivers. That goes against everything Linux was designed for.

            "Windows is very secure. More secure than Linux at this point."
            Funny, Linux by design has several layers of security that Windows will never have. It does make it a pain to use some time, but to get the same experience on Linux as Windows you have to run as root all the time. If you are doing that you don't know how to use Linux and shouldn't.
          • I wonder what layers you are talking about

            Opensource drivers could easily be signed. Opensource or free software doesn't means it has to cost nothing, a mistake that is made quite often apparently.