←back to thread

Intel OEM Private Key Leak: A Blow to UEFI Secure Boot Security

(securityonline.info)
658 points transpute | 3 comments | 06 May 23 17:39 UTC | HN request time: 0.701s | source
Show context
TacticalCoder ◴[06 May 23 19:48 UTC] No.35844787[source]▶
To all those saying SecureBoot brings absolutely nothing security wise...

Why is a project like, say, Debian, even bothering signing kernels:

https://wiki.debian.org/SecureBoot

What's their rationale for supporting SecureBoot?

replies(5): >>35844795 #>>35844812 #>>35844902 #>>35844983 #>>35848520 #
1. cptskippy ◴[06 May 23 19:52 UTC] No.35844812[source]▶
Doesn't this enable them to be installed on systems with Secureboot enabled without having the user muck around in the BIOS? Smart for VMs?
replies(1): >>35844835 #
2. TacticalCoder ◴[06 May 23 19:56 UTC] No.35844835[source]▶
I can see your point but, geez, that's pretty depressing if it's the only reason it's supported!

As a sidenote for having installed Debian with SecureBoot on on several systems, I'd say I still had to muck around quite some in the BIOS/UEFI. Latest one I scratched my hair for a bit was an AMD 3700X on an Asrock mobo where I somehow had to turn "CSM" (Compatibility Support Module) off otherwise Debian would stubbornly start the non-UEFI (and hence no SecureBoot) installer. On my Asus / AMD 7700X things were a bit easier but I still had to toggle some SecureBoot setting (from "custom" to "default" or the contrary, don't remember). All this to say: it's still not totally streamlined and users still need to muck around anyway.

replies(1): >>35844968 #
3. Vogtinator ◴[06 May 23 20:12 UTC] No.35844968[source]▶
There's another reason but it's even worse: Some certifications require that secure boot is enabled.