Announcement

Collapse
No announcement yet.

The Linux Kernel Prepares To Be Further Locked Down When Under UEFI Secure Boot

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

  • The Linux Kernel Prepares To Be Further Locked Down When Under UEFI Secure Boot

    Phoronix: The Linux Kernel Prepares To Be Further Locked Down When Under UEFI Secure Boot

    For more than the past year we have reported on kernel work to further lock down the Linux kernel with UEFI Secure Boot and it's looking now like that work may finally be close to being mainlined...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Does this mean we can't change GPU driver module parameters as well? What if you're trying to develop a kernel module? Would you then need to disable Secure Boot to develop kernel modules?

    Comment


    • #3
      Originally posted by sandy8925 View Post
      Does this mean we can't change GPU driver module parameters as well? What if you're trying to develop a kernel module? Would you then need to disable Secure Boot to develop kernel modules?
      If I understand correctly what you're saying, yes. The purpose of secure boot is to block any tampering with the boot process. It's just EFI boot + signing + some security features. With that said I have yet to see a machine that doesn't allow you to disable secure boot in some way or another, so it's not really something that blocks developers or end users that tweak with these sorts of things.

      Comment


      • #4
        Originally posted by InsideJob View Post
        You can never be too safe and secure! Too free, yes, but not too safe and secure. People in caves on the other side of the planet are plotting to demolish skyscrapers with jet fuel, you know. We must remain vigilant. 🤪
        I find it amusing -- and really telling about how ignorant many people who claim to be Linux experts actually are -- as to how anything related to preventing tampering with the software image being booted on your machine is an evil attack on freedom when the exact same people all act self-righteous over Meltdown & Spectre flaws that they pretend only affect one company's products.

        You might as well demand that all Spectre & Meltdown fixes be blacklisted from Linux in the name of freedom. I mean, if it's pure evil to prevent tampering with the software image during the boot process, then why the hell isn't it pure evil to prevent tampering with the software via side-channel attacks when the software is up and running?

        Comment


        • #5
          "KERNEL_LOCKDOWN": sounds like the name of a virus or a hacker from a Hollywood "cyber" plot :P

          Comment


          • #6
            init=/bin/bash anyone

            Comment


            • #7
              Originally posted by sandy8925 View Post
              Does this mean we can't change GPU driver module parameters as well? What if you're trying to develop a kernel module? Would you then need to disable Secure Boot to develop kernel modules?
              I'm not getting why this would be an issue for development, developers can just go and disable secure boot on their test rig?

              This lockdown feature disables a bunch of things and may very well break some drivers (also hybernation seems to be disabled). It's likely not designed to be enabled by default, but only on selected/certified systems where the hardware is well-known and you are sure everything works fine.

              Comment


              • #8
                Originally posted by chuckula View Post
                Meltdown & Spectre flaws that they pretend only affect one company's products.
                *that in the case of Meltdown affect only Intel and it's pretty easy to prove that they don't work on AMD because the same hardware call on AMD hardware throws an error as it is not supported.

                What you did there. I see it.

                Comment


                • #9
                  Originally posted by InsideJob View Post
                  You can never be too safe and secure! Too free, yes, but not too safe and secure. People in caves on the other side of the planet are plotting to demolish skyscrapers with jet fuel, you know. We must remain vigilant. 🤪
                  Trolling in a forum can't melt steel beams.

                  Comment


                  • #10
                    Last time I looked, "shim" checked the signature of "grub2", and "grub2" asked "shim" to check the signature of the kernel image to boot, and the linux kernel was able to check signatures of kernel modules to load. BUT: nothing checked a signature to the "initramfs" - so one could easily manipulate the init-scripts in there.

                    Has this situation changed?

                    BTW: Much more useful than all this "secure boot" nonsense (which is easily defeated by using either DMA-capable accessories or the vendor-specific master passwords to the BIOSes) would be a TPM-measured boot that presents a TOTP key to the user (at the time of storage decryption and log-in) based on a secret that is sealed in the TPM plus the readout from the TPM PCR registers.

                    But the world seems to love Snake Oil very much.

                    Comment

                    Working...
                    X