Skip Navigation

Why do I lose my Linux entries from UEFI boot?

I dual boot Windows 10 and Linux. Whnever Windows freezes or boot gets interrupted etc. I lose access to Linux because UEFI offers only Windows as boot options. On checking EFI partition still has rEFInd and PCLinuxOS entries needed.

I wonder why it cannot see them?

  • It is because of Secure Boot. Windows is doing exactly what it is supposed to do. The UEFI Secure Boot keys are not part of Linux.

    Your bootloader is the biggest attack surface on most modern computers. You can foolishly turn off secure boot, but windows may require SB to work at all. I think W10 may have had an option to turn off the SB requirement, but I know W11 must have SB.

    You can manually sign your own keys and replace them. I'm not going to just explain it all rn, but you can ask if you really need the help.

    If you want the easy path, just run any Fedora or vanilla Ubuntu. They both have a special key that is signed by m$ called a shim. It can coexist with Windows easily without any problems. I have a w11 partition just for adjusting my RGB keyboard sitting beside Fedora all the time on the same drive.

    Secure boot is designed to delete all unsigned bootable code. If you run a signed OS with SB this will always happen regardless of what other software is present. Self signed Linux would delete unsigned Windows just the same.

    • A w11 partition to adjust your RGB is peak fucking Linux haha

      Sidenote: is it not possible to run a vm for that?

    • Related q:

      So I have a machine with fde, + just one os present, + uefi password protected, + only the internal drive as a boot option. I also have sb enabled, but it was off during install (ventoy doesn't play nice with it, at least for me) so there's no keys registered, and I've reset sb keys anyway (for windows) since installation. Sb on but dormant.

      How vulnerable am I to a theoretical attack? With the drive encrypted and no alternative boot options, an attacker would need to somehow get to /boot/efi from the machine itself, right? Maybe a exploit in uefi? Am I missing any big pieces to the puzzle?

      • I don't know hardware/systems like this. I'm an abstract thinker. I like to break down and distil complicated subjects to a level I intuitively understand.

        Secure boot uses a Trusted Protection Module (TPM) chip. It is usually a dedicated chip, although there is a sketchy way it can be implemented in software. The idea is that the TPM chip is not connected internally to your computer at all. The chip can issue a new key that is only hashed with an internal key on the chip. There is never a point where that internal key on the chip is present in your computer. If any key present in your computer is generated from a TPM module, there is no way for anyone to swap, modify, or access the private key pair inside the TPM.

        Secure Boot is using this key to check that the bootloader and all kernel code hashes against the TPM secret key. Running SB with a TPM keyset is essentially saying no part of the chain is trusted, so we're making an extra sandboxed place that we can trust and making it exist in a space with no possible connections in software. There are possible exploits in an electronics lab with physical access to the hardware, but that is well outside of the average person's reasonable security model.

        If anyone modifies the bootloader binary, it is extremely difficult to detect after it is compromised.