Actually, I would love for you to explain to me how Secure Boot alone would protect someone from any of that. If you want to protect files, you need full disk encryption, not Secure Boot.

Or are you seriously expecting a government-level threat actor to bother to:

1. Sneak into your home while you're away or asleep;
2. Overwrite your bootloader or UEFI with a rootkitted image of the same version so it's impossible to tell;
3. Wait for you to boot your computer and enter your disk encryption password, then:
4. Use the rootkit to read the decrypted files off your disk?

That's the great thing about fascist governments, is they have no need to be that sneaky. They can just change the laws to make whatever you're doing illegal and jail you until you agree to give up your documents, or simply hit you with a $5 wrench until you tell them the password.

Security

^xkcd

Secure Boot is a really contrived and, frankly, bad defense against an attack that is extremely difficult to execute in reality and does not happen often (are there any examples of a bootloader replacement against a home desktop in the wild?).

An actually good solution would be firmware support for LUKS-style FDE (with a password-encrypted key which then encrypts the rest of the disk), so that your bootloader is encrypted with the rest of your system and impossible to substitute without erasing the rest of the disk, until you enter the password. This way there's no need for key enrolment into firmware, and firmware manufacturers don't have to just trust MS. (the firmware of course needs to be protected too, by signing it with the manufacturer's key; if you flash something unsigned, a warning pops up Android-style before every boot).

If you are hiding something from the state (like your sexual orientation or something), your energy is much better spent encrypting your communications online and keeping your identities anonymous. If you are already suspicious enough to try and pull a bootloader replacement attack on you, any authoritarian state which would do that in the first place will just throw you in jail and fabricate evidence as needed.

Yeah, but the malware can just wait for a system upgrade where you sign a new boot image and slip itself in then.

It works for Windows because theoretically only Microsoft would have the signing key and it's not just sitting on disk somewhere. But then you're just trusting Microsoft, and also subject to vendor lock-in.

If secure boot is off, and you run malware on your pc, it can change the boot process to escalate privileges.

This is technically correct, but on a desktop system, malware executing in user space is normally already game over. It can exfiltrate and send your passwords or ssh private keys, change browser certificates or browser software, add user systemd sessions or crontab entries and can generally e.g. do everything a banking trojan would like to do.

I don't think you understand what "enrolling your own keys" means in the context of Secure Boot.

The key affected here is specifically for the Linux shim signed by Microsoft. It is used by GRUB and some distros to work with Secure Boot.

Enrolling your own key means you add a new certificate to the key store. This is completely separate from the one provided by Microsoft and controlled only by you. The common recommendation is to remove all built-in keys and only add your own, to make this system as secure as possible.

and you're being kind of a jerk?

Please don't troll and come back to the topic. GP was completely missing the topic, do you want to avoid it?

. If you disable Secure Boot, install a Linux distro, enrol that distro's keys and then reenable it, you're fine.

Um, given that Secure Boot prevents any modification of your computer's boot chain - including installing another boot loader or OS - that's not how it works.

I thought it was a Microsoft centric thing in that the certificate authority was either Microsoft or signed by Microsoft?

Maybe I need to read about it more? Can you direct me to the general area?

That's bullshit. ARM is an architecture and by itself does not specify secure boot any more than x86 does. Raspberry Pis don't have secure boot. You can unlock the bootloader on a Pixel, install GrapheneOS, and relock the bootloader just fine. Several other manufacturers allow bootloader unlocks no problem. The main reason you can't on some popular phones is US carriers, even international Samsungs you can unlock the bootloader and flash whatever you want on it.

I'm literally typing this comment on a phone running a custom OS (LineageOS on a OnePlus 8T). I'm literally 2 versions of Android ahead of the latest supported version. I also have a Galaxy S7 running Android 15, a phone that officially tops out at Android 8 and launched with Android 6. Both you literally just toggle the bootloader unlock option in the settings, no hacks no craziness, it's literally a feature.

At this point you're just straight up making shit up.

That's bullshit. ARM is an architecture and by itself does not specify secure boot any more than x86 does. Raspberry Pis don't have secure boot.

I mean Windows PCs with ARM CPUs which have Secure Boot, not Android smart phones or embedded devices.

Nope. Even Qualcomm themselves provide what's needed to run Linux on the Windows for ARM PCs.

The only one I can't find for sure is whether there's any lockdown on the firmware for the Microsoft Surface and Copilot+ laptops, but I'm also not finding any sources pointing that it would be. But at this point you're buying Microsoft hardware, what do you expect.

Qualcomm Snapdragon X Elite Benchmarks On Ubuntu Linux vs. AMD vs. Intel

June 2024 marked the launch of the Qualcomm Snapdragon X Elite to much initial fanfare for finally some compelling ARM laptop designs.

^{www.phoronix.com}