3 ms·

SecureBoot!? Hahahah, Linux Foundation marks this as critical? I am sorry to laugh, but thank God the LF and others fought tooth and nail for some way to have

by 616c 11y ago

SecureBoot!? Hahahah, Linux Foundation marks this as critical? 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?

crdoconnor 11y ago
I didn't laugh but I got a bit suspicious about their true motivations as soon as I saw that.
- mricon 11y ago
  Not everyone has an evil agenda. And, if you read the guide, it specifically mentions the downsides of SecureBoot and offers alternatives (AntiEvilMaid).
josteink 11y ago
Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Secure_Boot https://wiki.archlinux.org/index.php/Unified_Extensible_Firm... 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.
- roghummal 11y ago
  >On proper UEFI implementations ... You're going to have to qualify that.
  - josteink 11y ago
    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.
    - tytso 11y ago
      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....
      - josteink 11y ago
        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.
- 616c 11y ago
  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.
  - josteink 11y ago
    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.

by 616c 11y ago

crdoconnor 11y ago

I didn't laugh but I got a bit suspicious about their true motivations as soon as I saw that.

mricon 11y ago
Not everyone has an evil agenda. And, if you read the guide, it specifically mentions the downsides of SecureBoot and offers alternatives (AntiEvilMaid).

josteink 11y ago

Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Secure_Boot https://wiki.archlinux.org/index.php/Unified_Extensible_Firm... 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.

roghummal 11y ago
>On proper UEFI implementations ... You're going to have to qualify that.
- josteink 11y ago
  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.
  - tytso 11y ago
    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....
    - josteink 11y ago
      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.
616c 11y ago
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.
- josteink 11y ago
  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.