Announcement

Collapse
No announcement yet.

Secure UEFI. Great for Windows, not so much for Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Secure UEFI. Great for Windows, not so much for Linux

    Originally posted by Matthew Garrett
    http://mjg59.dreamwidth.org/5552.html
    Since there are probably going to be some questions about this in the near future:

    The UEFI secure boot protocol is part of recent UEFI specification releases. It permits one or more signing keys to be installed into a system firmware. Once enabled, secure boot prevents executables or drivers from being loaded unless they're signed by one of these keys. Another set of keys (Pkek) permits communication between an OS and the firmware. An OS with a Pkek matching that installed in the firmware may add additional keys to the whitelist. Alternatively, it may add keys to a blacklist. Binaries signed with a blacklisted key will not load.

    There is no centralised signing authority for these UEFI keys. If a vendor key is installed on a machine, the only way to get code signed with that key is to get the vendor to perform the signing. A machine may have several keys installed, but if you are unable to get any of them to sign your binary then it won't be installable.

    This impacts both software and hardware vendors. An OS vendor cannot boot their software on a system unless it's signed with a key that's included in the system firmware. A hardware vendor cannot run their hardware inside the EFI environment unless their drivers are signed with a key that's included in the system firmware. If you install a new graphics card that either has unsigned drivers, or drivers that are signed with a key that's not in your system firmware, you'll get no graphics support in the firmware.

    Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely.

    A system that ships with only OEM and Microsoft keys will not boot a generic copy of Linux.

    Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM.

    There's no indication that Microsoft will prevent vendors from providing firmware support for disabling this feature and running unsigned code. However, experience indicates that many firmware vendors and OEMs are interested in providing only the minimum of firmware functionality required for their market. It's almost certainly the case that some systems will ship with the option of disabling this. Equally, it's almost certainly the case that some systems won't.

    It's probably not worth panicking yet. But it is worth being concerned.
    Source: http://mjg59.dreamwidth.org/5552.html


    Personally I am not terribly worried as this sort of thing has come along before and the law has prevented it. This time M$ are also "investigating" dual boot and as large companies such as Novell, RedHat etc... are on the Linux side there shouldn't be a problem.

    Just making people aware.
    Last edited by Lorem-Ipsum; 22-09-11, 17:48.
    Desktop: Intel i5-4690K | 16GB DDR3 | Gigabyte Z97N-WIFI | EVGA GTX 660 3GB | Windows 10
    Server 0: Gen8 HP Microserver | Proxmox Hypervisor Server 1: Gen8 HP Microserver | FreeNAS

  • #2
    Spotted this on osnews.com
    It will be interesting to see how this is implemented

    Comment


    • #3
      Yeah, would be annoying to have to use custom firmware to boot a second O/S. However I can't see this getting pushed through, there was a big ruckus about the trusted computing platform back in 2003, and that never happened - and this is potentially even more draconian.

      Certainly something to keep an eye on though!

      Comment


      • #4
        An update:
        http://www.osnews.com/story/25185/Mi..._Address_Issue

        Comment


        • #5
          Interesting. Looks like I'm going to have to turn to cracking. Next Defcon could be a good one!
          Desktop: Intel i5-4690K | 16GB DDR3 | Gigabyte Z97N-WIFI | EVGA GTX 660 3GB | Windows 10
          Server 0: Gen8 HP Microserver | Proxmox Hypervisor Server 1: Gen8 HP Microserver | FreeNAS

          Comment


          • #6
            This is just stupid, i have also been watching it on osnews (i read them everday without fail, i love Thom).

            I don't get how they can be sued by the EU for bundling IE and WMP with Windows and then this and see to be getting away with it so far...we need choice, not lock in.

            Good job i build my own computers though so it never affects me.
            GamingOnLinux.com - The number 1 Linux gaming community

            Comment


            • #7
              http://www.theinquirer.net/inquirer/...e-boot-process

              The firm was keen to mention that the user is the person in control over whether Windows 8 secure boot is used, with Microsoft's Tony Mangefeste saying, "The security that UEFI has to offer with secure boot means that most customers will have their systems protected against boot loader attacks. For the enthusiast who wants to run older operating systems, the option is there to allow you to make that decision."
              not going to be a problem?

              Comment


              • #8
                Originally posted by Icm76 View Post
                In english that means those that use illicit ways to activate windows will be unhappy.
                I am not losing weight! I'm getting rid of it. I have no intention of finding it again!

                Growing old is inevitable. Growing up is optional

                Comment


                • #9
                  No doubt that's a big part of the motivation for MS, but as long I can keep dual booting I'll be happy.

                  The OEM suppliers not providing the option to turn off secure boot does sound like it may be an anti-trust lawsuit waiting to happen.

                  Comment


                  • #10
                    Yeah and it's supposed to be an option in the BIOS to turn it off/on isn't it? So unless OEM's are ripping that out of the BIOS it shouldn't be a problem. Certainly not a problem for any of us pc builders anyway.
                    GamingOnLinux.com - The number 1 Linux gaming community

                    Comment


                    • #11
                      Originally posted by Mr Banana View Post
                      Yeah and it's supposed to be an option in the BIOS to turn it off/on isn't it? So unless OEM's are ripping that out of the BIOS it shouldn't be a problem. Certainly not a problem for any of us pc builders anyway.
                      its more laptops i'm worried about. I've not built a desktop PC in years (well, not for desktop computing anyway.)

                      There's also the issue of the ability to repurpose aging hardware (eg cheap media centres, home servers,etc)

                      Comment


                      • #12
                        I think that it's just Microsoft flexing their muscles again, they did something like this a few years back.

                        Comment


                        • #13
                          Originally posted by GSVRasputin View Post
                          I think that it's just Microsoft flexing their muscles again, they did something like this a few years back.
                          The trusted computing thing, yeah. But that shouldn't mean we get complacent

                          Comment


                          • #14
                            Originally posted by Plan9 View Post
                            The trusted computing thing, yeah. But that shouldn't mean we get complacent
                            No I totally Agree, I for one will never back Ms Windows 8 nor a prebuild with any secure UEFI on it, You should be allowed to choose what software to run your hardware with.

                            The only thing that worries me is if the *nix world has enough power to drag Microsoft through the courts on a Monopoly charge of some sort.
                            If not, I am sure a work around will be in place quick enough.

                            Comment


                            • #15
                              Originally posted by GSVRasputin View Post
                              No I totally Agree, I for one will never back Ms Windows 8 nor a prebuild with any secure UEFI on it, You should be allowed to choose what software to run your hardware with.

                              The only thing that worries me is if the *nix world has enough power to drag Microsoft through the courts on a Monopoly charge of some sort.
                              If not, I am sure a work around will be in place quick enough.
                              Opera managed to for IE, so I can't see why Canonical couldn't.

                              Companies like Novell might not be able to due to patent agreements with MS though.

                              Comment

                              Working...
                              X