I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again. Those are the people driving the concerns of Microsoft and computer vendors.
Secure Boot protects against boot kits, malware that replaces the bootloader and backdoors the OS as it boots and before any other security protections kick in. Real world bootkits have been found in the wild, and we've even seen them use vulnerabilities in signed (now revoked) bootloaders, so we know secure boot has forced their developers to work harder. You may not be worried about that as a risk (well, until you are) but there are real people who this has genuinely protected.
Is it worth it by default? Completely reasonable separate discussion to have. But is there a reason it exists? Absolutely.
Apart from way nicer boot menus and bootloader setup?
In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression.
> Out there, there is software, which I have to figure out how I'm going to trust,
Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc.
You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered.
Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run.
This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.
Ordinary disk encryption would protect me too here, wouldn't it?
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
UEFI supports the latter if you want and configure it, but it's not a requirement of UEFI, and technically a BIOS could also implement signature verification of the boot sector.
It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other potential bad actors.
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.
This isn't even slightly accurate. Secure boot does not rely on TPM keys on any way.
LOLOL lemme stop ya right there chief. I'm screwed anyway? This is ridiculous.
Sheer incompetence, in other words.
Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
Meanwhile you look at a company like Oxide that is a software company at heart, and their equivalents are so much better. Like someone actually designed it so that when humans write the software it will still be secure.
Lemon market: https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf
Buyers can't distinguish good work from bad, so they pay only average price and thereby drive out the high-quality sellers.
It seems like the immediate problem here is that most people will never enroll their own keys, and if every vendor's crappy EFI binary gets signed by Microsoft, there will be a huge library of garbage vendor code which is all an attack surface.
Excellent.
https://blog.invisiblethings.org/papers/2015/state_harmful.p... https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably...
... granted, effectively removing Microsoft keys is a pain on some consumer devices, but still easier than this
For that, any SSDs/HDDs included in the computer should be non-bootable and fully-encrypted.
Then the BIOS will happily run whatever an intruder will attempt to run, but nonetheless the intruder will not have any access, neither for reading nor for writing, to the data hosted by the computer.
The owner can boot from a removable USB memory, used as a computer key, whose content cannot be modified by someone else as long as the owner keeps it.
All Intel/AMD CPUs have backdoors in the form of the System Management Mode and of various hardware management engines, which can be exploited by a malicious BIOS or UEFI firmware to monitor what the operating system that is controlled by the user does, but SecureBoot also offers no protection against such backdoors. ARM CPUs are no better, because many of them have copied Intel, so they have the equivalent of the SMM: EL3.
If you run yourself a hostile application after booting, then SecureBoot also does not offer any protection against that.
