It may not provide 100% security (what does?), but using this still provides much more security than just booting whatever lies on disk without any sort of verification.
So yeah. Laughing at this advice is at best uninformed.
A nice bonus-effect from using secure boot is that most UEFI implementations secure-boot faster. Why? Because when in "insecure" mode it keeps up a splash-screen saying "Booting insecure" for a few seconds before moving on.
I laugh, and get downvoted, because SecureBoot was a noble concept, and rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic.
I deal with computer deployment for a living. I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to, and no one is trusting my self-signed certs unless it is not seriously work-related stuff. The majority of people, and I have a few budding Linux enthusiast friends, just turn off Secure Boot. Not to mention the numerous IT contractors I meet. It is embarassing.
UEFI is also a mess. I have recently read some good UEFI attack papers, and it scares me to no end, as the firmware extension capabilities make the B in BIOS increasingly seem more ironic. And the potential of having a FAT16/32 parttion of exploitable garbage from system vendors puts just back where we started.
I think this shit is great in theory, but in implementation I do not trust corporations with TPM devices, let alone SecureBoot. It works in principal, but only as long as you trust the US corporate and federal government interests.
For reasons long since expounded on HN and elsewhere, I do not.
rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic.
And that was a good thing. It put pressure on getting the capability to add your own keys.
I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to, and no one is trusting my self-signed certs
Agreed. I guess it all depends on what you refer to as "security".
For me general internet security is about making it harder to get impacted by drive-by malware, portscans and similar.
I set as a general rule that I don't believe there exists practical security-measures which can counter-act malicious activity if anyone has local access to my hardware. I don't try to guard against that.
If your definition of "security" involves guarding against possible systematic attacks from US government agencies using pre-installed (Microsoft) keys, obviously secure boot is not going to provide that for you.
My point was that laughing at secure boot as a measure of increased security because "lulz Microsoft" is a knee jerk reaction which is factually wrong.
The majority of people, and I have a few budding Linux enthusiast friends, just turn off Secure Boot
And are you really going to tell me they are not more vulnerable than if they had been using secure boot?
Secure boot can be used to increase security and I don't think that is debatable. I think the reason you're getting downvoted is because you seemingly dismiss this point.
UEFI is also a mess
I think I'll have to agree with this one. With BIOS being clearly insufficient for modern hardware and software needs, UEFI was a pendulum move gone too far the other direction.
It's over-engineered, supports too many crazy things, and coupled with other "messy" features like Intel System Management mode (which also allows code outside the OS), the possible attack vectors (coupled with physical access) are getting increasingly crazy.
I thought there was a significant gap between our views, but I think you and I are of very similar viewpoints. Thanks for teasing something more detailed out of me, so I do not feel like so much of a troll.
I agree with you. I had to design some concepts for securing a boot process or replacing BIOS. My first inspirations were Open Firmware, Coreboot, and U-Boot, already doing much of the job. However, all too complicated, incomplete, or Forthy. So, I saw it from three basic angles drawing on what was done in past:
1. Replaceable ROM or read-only, flash chip that the system booted from with open-spec for user customization. You can trust their bootloader, yours, etc. Modifications require physical replacement to avoid software attacks. You can know what it's doing because you can flash it yourself or use your own if it's physically compatible. Can be cheap. Simple.
2. Combination of anti-fuse ROM and flash. The ROM has a highly robust firmware that test chip, initializes some stuff, pulls firmware out of flash, does crypto checks on it, and then runs it. In a maintenance or update mode, the ROM + flash combo can pull up an upgrade into memory, disable all I/O that can affect it, check it, flash it into storage, and reboot. ROM can't be modified without physical replacement, so always a root of trust to start with. Can be combined with No 1 if necessary.
3. Software-only protection necessitates combating 0-days. This means gotta use an EAL6+ development process. Abstract away hardware details into functions with interface types and checks. Code in safe subset with static analysis, testing, and simulation. Make different device handling pluggable modules to run that interact with safe interface. Extract implementation from that. Examples include using SPARK Ada, MISRA C w/ ASTREE checker, or Java via BootSafe technology. Optionally auto-gen tech like Termite for drivers.
Personally, I think we could go with No 1 on everything down to laptops and some tablets. Ultra-compact things such as smartphones can use No 2. No 3 is only for the most stubborn, cost-sensitive companies and those are unfortunately least likely to go the extra mile lol.
It's no secret that the full UEFI spec is quite complex. Some parts are mandatory while others are optional.
It's also no secret that lots of hardware vendors are terrible at implementing software. The usual rule is that the less software they write, the better.
The result is that different vendors and OEMs have a different quality UEFI firmware implementations and different feature-set available in them. Some are clearly less proper and less complete than others.
Well, that's really the question, isn't it? Is there more security added by enabling UEFI, or keeping it disabled? I managed to brick four Lenovo Thinkpad T540p mainboards due to a UEFI bug. Fortunately I had the on-site corporate maintenance contract (that time it paid for itself), because neither I nor Lenovo could figure out why the system would end up getting so badly bricked it couldn't be booted at all. Turns out there was a bug in the UEFI implementation where if it was enabled at all (regardless of whether it was enforcing secure boot or not), and you had a Samsung SSD installed, the UEFI implementation would write garbage into its non-volatile flash storage, that would completely brick the mainboard, and nothing would fix it except for a complete mainboard replacement.
Sure, it was a bug, but if you've read the UEFI spec, it's scary how complex the thing is. It reminds me of all of the complexity NSA employees managed to insert into the IPSEC and TLS stnadards. Complexity kills, especially when security is concerned. You really want to keep the Trusted Code Base small and simple. And UEFI is not simple. Combine that with the competence traditionally associated with BIOS programmers, and the results are very sad....
Good questions all together. But if I were to make one technical nitpick...
> Is there more security added by enabling UEFI, or keeping it disabled?
You're not really disabling the UEFI firmware at a technical level. You're just telling the UEFI firmware to load a UEFI BIOS compatibility shim, which then proceeds to load a unverified bootloader instead.
How much security do you expect to gain from that? I don't think there's any evidence this will help make your machine more secure against software based attack Of course there are no absolute answers, or otherwise we wouldn't be having this discussion.
Well, the question is kind of moot, because I haven't dared to re-enable UEFI boot since. Supposedly newer BIOS's have the bug fixed, but the value to me in risky another range of motherboard replacements is just not worth it. I suppose if I cared about UEFI it might be a good idea to try it before the maintenance contract runs out, but as a kernel developer, I'm constantly replacing the kernel, so using UEFI is a PITA anyway.
Not everyone has an evil agenda. And, if you read the guide, it specifically mentions the downsides of SecureBoot and offers alternatives (AntiEvilMaid).
I am sorry to laugh, but thank God the LF and others fought tooth and nail for some way to have someone other than Microsoft have the key.
But seriously, did anyone else laugh?