[RiverCrochet]

If an attacker gains root privileges on your system, an attacker can modify the bootloader on your boot device to load a different kernel than the one you have installed, possibly one that the attacker uploaded that may have backdoors, etc.

Secure boot requires that the bootloader match a hash derived from a TPM-stored key.

Of course, you get the same protection (and update hassle) by storing the bootloader in something that can't be written except when you specifically enable it.

A better scheme than the UEFI secure boot/TPM junk is simply a 2GB SD card (enough to hold a bootloader, kernel, and initrd) in an SD card reader with a physical read/write switch. When it's time to update your bootloader or kernel, flip the switch to write mode, then flip it back - heck the system could even refuse to boot if write mode was enabled on boot.

Honestly I don't know why the whole PC firmware shouldn't be on that SD card. Corrupt unbootable BIOSes can be fixed with a new SD card.

For remote updates, the physical switch could be replaced with a GPIO pin and a Raspberry Pi that you connect to and log into separately. It's less secure than the physical switch but oodles more secure than what's there now - maybe not oodles but at least the software on a Pi is much higher quality than UEFI vendors.

[mjg59]

> Secure boot requires that the bootloader match a hash derived from a TPM-stored key.

This isn't even slightly accurate. Secure boot does not rely on TPM keys on any way.

[RiverCrochet]

Huh, I don't know why I thought it did. Looking into the link below briefly I see it uses a PKI scheme with CAs.

https://learn.microsoft.com/en-us/windows-hardware/manufactu...

So I guess if you provide a key for the bootloader, the firmware will sign it when it's in setup mode? I guess that private key is embedded directly in the firmware then? I presume that's made invisible once control is handed to the bootloader somehow ...

[mjg59]

No, the firmware never has any private keys. You sign offline with a private key and provide the public key to the firmware. All further bootloader updates are signed with the same key and require no additional firmware configuration.

[xinayder]

If an attacker has root privileges to my Linux system, what's stopping them from overwriting my Linux kernel image in my boot partition with one that has backdoors?

[mjg59]

Secure boot.

[xinayder]

How is secure boot stopping them from overwriting my kernel image on the first place? Won't it just report that the kernel image was tampered and thus you cannot boot to the system?

It does nothing to prevent overwriting the kernel image.

[hollerith]

If secure boot is operating as designed, the boot loader will refuse to boot the replacement kernel (because its hash is not on a list).

Now if you ask, how is secure boot stopping an attacker from overwriting libc or some other important system library? the answer is nothing is stopping it on Linux, but on ChromeOS, MacOS, Windows and the two mobile OSes, the secure-boot machinery has been guarding against that for years.

[jrm4]

"If an attacker gains root privilieges.."

LOLOL lemme stop ya right there chief. I'm screwed anyway? This is ridiculous.