Why do I lose my Linux entries from UEFI boot?
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?
OpenRGB is an option.
I used a VM to adjust my Logitech Mouse LEDs, so yeah passing it through should be possible and assuming it saves the settings to the devices onboard firmware instead of the Windows software doing the configurations at launch.
I just don't bother trying. Someone probably has a solution for the proprietary garbage inside the laptop that is undocumented. I could go in and monitor the registers that are being changed. I've only ever used it once, and I was there to blacklist the Mac address in my router's outbound filter because the worst hackers are corporate stalkerware pirates that limit my access to information and sell my data to those that wish to manipulate me in healthcare, insurance, banking, and politics.
The proprietary code is running on a microcontroller and there is no telling what else it is doing or connected to. It is present in the UEFI memory space. So naturally, I want to be able to monitor its native behavior at any time as well. I have logged an unknown Mac trying to dial out occasionally that is not the windows Mac, but I whitelist everything I wish to connect to via a 3rd party device I fully control. That level of ownership certainly is peak Linux.
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.
I had to install Linux on a different drive because Windows will happily wreck your Linux boot on the same drive. It’s something Microsoft deliberately does.