Secureboot uses the TPM (Trusted Platform Module) to store keys to signed bootloaders (the windows bootloader for example), and then tells the BIOS to not run unsigned bootloaders.

Dual booting is when you install multiple OSs on your system. the most common dual boot configuration is windows and linux. unless you run stock ubuntu, your Linux bootloader is not signed and will not function with secureboot enabled.

as seen in another post here its possible to hack the TPM requirement off, but for how long will this work? temporary fixes, especially security hacks, never last long and are patched quickly.

My recommendation to everyone who doesn't want to be locked out is Virtual machines. Virtualize your windows using QEMU/KVM. libvirt makes it really easy nowadays.

  • eduardog3000 [he/him]
    ·
    edit-2
    3 years ago

    You know you can just... install a signed bootloader right? There are signed Linux bootloaders. Or just sign one yourself and have the computer trust your key.

    Also, from the official Debian wiki:

    What is UEFI Secure Boot NOT?
    UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot.
    SB is also not meant to lock users out of controlling their own systems. Users can enroll extra keys into the system, allowing them to sign programs for their own systems.

    If you're installing a Linux distro that doesn't already support Secure Boot, you're already getting into the weeds. It's not that much extra work to get Secure Boot working. Here's wiki page with information on getting it working.

    • Chloe [they/them,she/her]
      ·
      3 years ago

      Yeah but it still adds a huge layer of extra pain, which is why the usual advice is just to disable SB if you're installing Linux. Even on that page, in the list of what SB limits, it mentions:

      Loading kernel modules that are not signed by a trusted key. By default, this will block out-of-tree modules including DKMS-managed drivers. However, you can create your own signing key for modules and add its certificate to the trusted list using MOK.

      This includes the NVIDIA drivers, adding a layer of additional headache to something that's already unfortunately overcomplicated relative to Intel and AMD drivers that work OOTB. Hibernation doesn't work either. And of course, SB is still going to make it impossible to run any OS that doesn't support it on bare metal, including a number of Linux distros as well as any of the BSDs, the Hurd, Redox, ReactOS, etc., countless smaller hobbyist operating systems. and it's disappointing to enter a future where tinkering is something you have to fight your computer to do. It's a niche case, sure, but why should that be restricted? Why not let users do what they want as long as they're effectively warned of the risks?

      Sure, in most cases, as long as you're not going to be dual-booting, you can just turn it off, but there's going to be a point where there's little financial incentive for OEM PCs to let you disable SB. A lot of modern motherboards already don't support legacy boot, IIRC. And I hate the fact that you're having to make a choice between Windows and freedom over your own computer. "Truly secure boot means YOU specify what system is allowed to run in your computer."

      • eduardog3000 [he/him]
        ·
        edit-2
        3 years ago

        Sounds like the main problem here is that those Linux distros aren't catching up to new standards, no? Maybe on NVIDIA too for not supporting Linux very well.
        Maybe Microsoft is pushing it too fast, but then again, Secure Boot has existed for more than a decade at this point. You don't have the "freedom" to run a 64-bit OS on a 32-bit machine, how is this different?

        • Chloe [they/them,she/her]
          ·
          3 years ago

          I don't think that's a fair comparison. You don't have the "freedom" to run a 64-bit OS on a 32-bit machine because of unavoidable technical limitations. Secure Boot is something totally arbitrary that's added for the sake of security. It has nothing to do with hardware capabilities. It does not provide any more possibilities, it only locks things down further. UEFI is totally fine, by the way, and UEFI can exist in isolation from Secure Boot.

          Sounds like the main problem here is that those Linux distros aren’t catching up to new standards, no? Maybe on NVIDIA too for not supporting Linux very well.

          For starters, Secure Boot isn't just a matter of implementing it on your terms, you go through Microsoft. As taken from the FreeBSD wiki page on Secure Boot:

          Currently the only key that is guaranteed to be present in any given system is Microsoft's.

          There's a huge amount of trust and power being vested in a corporation, in that they'll graciously sign the kernel for your operating system so people can use it. I don't think that's healthy centralization.

          Additionally, regarding the NVIDIA driver, it's unavoidable. The nature of drivers on Linux is that, if they're modules which aren't part of the kernel itself, you have to build it from source for your kernel, and then because of the nature of SB, you'd have to sign it as well, otherwise it'll get rejected. Sure, the ideal would be if NVIDIA could act like the other manufacturers, make their driver free software, and integrate it into the kernel so it can be pre-signed by your distribution, but they're never gonna do that. And even if that wasn't an issue, you still can't trivially compile and load, e.g., a custom wireless driver for your card. There are security benefits to this but they're ones that are inconsequential for a casual home user, and they just serve to make Linux even more difficult. It deeply punishes anything that comes from a community rather than a corporation.

    • RussianEngineer [she/her]
      hexagon
      ·
      3 years ago

      you have any idea how much of a massive pain in the ass that would be? not to mention it causes you to lose some functionality (ie: suspend to memory) Chloe pretty much explains it perfectly but ill add on to it that every time you update your linux system, the bootloader is overwritten. meaning the entire process of making it secure boot compatible has to be re-done