Announcement

Collapse
No announcement yet.

Secure Boot Breaks Kexec, Hibernate Support On Linux

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

  • Secure Boot Breaks Kexec, Hibernate Support On Linux

    Phoronix: Secure Boot Breaks Kexec, Hibernate Support On Linux

    A set of "controversial" patches were published by Matthew Garrett this morning for the Linux kernel. One of the patch series will disable the kernel's support for kexec and hibernate support when running in a UEFI Secure Boot environment...

    http://www.phoronix.com/vr.php?view=MTI4NjE

  • #2
    Basically Secure Boot with physical access to the system is a joke anyway for several reasons:

    a) You can boot Ubuntu (but not Kubuntu), Fedora and whatever other distro that ships binaries with MS key - then feel free do modifiy whatever you like.

    b) If you use mjg59's shim to add a key/hash it was impossible for me to reset this without reflashing the firmware to a state before. When added it is in for all times (tested with ami uefi - one of the boards tested was an asrock b75 board). So it will always accept your efi binaries.

    c) Some boards like Asrock keep the CSM enabled by default even with Secure Boot on (btw. would you search it under ACPI options???) - just boot via a normal loader.

    d) Even if you don't have a SB enabled iso you can just switch it off in 99% of all cases because there is no firmware password set anyway.

    Even if you only allow signed kernels to be booted from hd you would need to encrypt it. And what protects you from a modified initrd? Maybe it would be more useful to sign that with a personal key, set a uefi password (if it helps - i know boards with password skip jumper...). A tiny bit hard could be a password set on the hd, but when suspend is used that password if often stored as well. Better forget security on local pcs

    Comment


    • #3
      Yes, Secure Boot does nothing to protect against physical attack. Nobody's ever claimed otherwise.

      Comment


      • #4
        And how to you exploit hibernate remotely? Usually you are already root there to do so...

        Comment


        • #5
          You can gain root remotely.

          Comment


          • #6
            Secure Boot is all about protecting against longterm remote exploits (Someone hacks you and replaces a kernel module that you use with one that has a backdoor, or something along those lines) If they've got physical access...you got screwed long before they sat down at your desk.

            Comment


            • #7
              Originally posted by Ericg View Post
              Secure Boot is all about protecting against longterm remote exploits
              Or is Secure Boot all about protecting Microsoft's longterm revenue stream. Keep in mind that up-front the article didn't buy into the security of Secure Boot. They were looking at taking these actions in order to prevent their key from being revoked from Microsoft. When the playing field appears crooked, due diligence becomes all the more important.

              Comment


              • #8
                Originally posted by phred14 View Post
                Or is Secure Boot all about protecting Microsoft's longterm revenue stream. Keep in mind that up-front the article didn't buy into the security of Secure Boot. They were looking at taking these actions in order to prevent their key from being revoked from Microsoft. When the playing field appears crooked, due diligence becomes all the more important.
                Secure Boot's a tool, the wielder chooses how that tool is handled. If Microsoft wants to use Secure Boot for evil, fine, but don't blame Secure Boot. Blame Microsoft for making that choice.

                Comment


                • #9
                  Originally posted by Ericg View Post
                  Secure Boot is all about protecting against longterm remote exploits (Someone hacks you and replaces a kernel module that you use with one that has a backdoor, or something along those lines) If they've got physical access...you got screwed long before they sat down at your desk.
                  Crackers have better things to do. "Secure" Boot being a thing to make installing Linux and other OSes harder is bigger than a big ass.

                  Comment


                  • #10
                    All you need to do is to sign your grub loader (i would like when gummiboot would work as well) - creating it is a bit tricky. I compiled grub2 from ubuntu and then signed the cd efi binary from the amd64.tar.gz in my first test. Basically you gain nothing that way, it just starts with Secure Boot enabled as it does not check for any signed kernels like when you use the precompiled grub-efi-amd64-signed (together with shim-signed) from Ubuntu.

                    Comment


                    • #11
                      Misleading headline

                      Phoronix, "Secure Boot Breaks Kexec, Hibernate Support On Linux" is a very misleading headline.

                      Implementing SB does not 'break' those things. The problem is that those features make it trivial to circumvent SB protections. It's not that these things have to be disabled for SB to 'work'; it's that if you want to have the actual protection of SB, it logically requires that those features be disabled until they are improved from a security perspective. As long as those things are enabled, an attack could circumvent the protections SB is intended to provide.

                      Comment


                      • #12
                        Don't you think that when you are root you cant do enough things already?

                        Comment


                        • #13
                          Originally posted by Kano View Post
                          Don't you think that when you are root you cant do enough things already?
                          Secure Boot is intended to prevent you booting untrusted bootloaders. A kernel that will execute arbitrary code is effectively an untrusted bootloader. Userspace code, even if run by root, isn't.

                          Comment


                          • #14
                            Well you know that you have usally cant use precompiled kernel modules for binary drivers? If you sign em on your own you usually store the key on the hd - easy to find in the bash history. Basically you can skip this test then when an attacker can find it. One other thing nobody mentioned, several boards can be flashed using flashrom, not all but the number is growing. You have direct access to the firmware then...

                            Comment


                            • #15
                              Originally posted by Kano View Post
                              Well you know that you have usally cant use precompiled kernel modules for binary drivers? If you sign em on your own you usually store the key on the hd - easy to find in the bash history. Basically you can skip this test then when an attacker can find it. One other thing nobody mentioned, several boards can be flashed using flashrom, not all but the number is growing. You have direct access to the firmware then...
                              Modern boards can't be flashed with flashrom, because the SPI controller will only allow write access when you're in system management mode. You produce a distro, so I guess you get to figure out how you're going to handle key management for third party modules.

                              Comment

                              Working...
                              X