Secure Boot is broken on 200 models from 5 big device makers

Original Article ↗ Hacker News Discussion ↗

Secure Boot’s Purpose and Limits

  • Many describe Secure Boot as part of a verified boot chain: firmware → bootloader → kernel → drivers → user space, protecting against modified bootloaders and persistent bootkits.
  • It does not protect against all attacks: a compromised running kernel can still exfiltrate data, and a true firmware/flash rootkit can often bypass it.
  • Some argue the main practical benefit is being able to wipe/reinstall an OS and have confidence no boot-level malware persists.
  • Others question why so much complexity is added instead of hardening kernels/firmware update paths directly.

User-Hostility and Lockdown Concerns

  • Strong sentiment that Secure Boot, TPM, and similar mechanisms are used to protect vendors’ interests and enforce walled gardens, not primarily to protect users.
  • Comparisons to phones, consoles, smart TVs, where users can’t control keys or disable lock-down.
  • Specific worry that ARM PC platforms forbid disabling Secure Boot or enrolling user keys, unlike x86.

Key Management Failures

  • Central issue: a widely used “DO NOT TRUST / TEST” platform key ended up in production firmware across many devices.
  • Commenters blame both AMI (for shipping such a key in dev kits) and OEMs (for not replacing it), calling it “idiots all the way down.”
  • Revoking bad keys is hard: vendors must ensure all affected systems have updated bootloaders that trust new keys before revocation.

User Control, Custom Keys, and Alternatives

  • Several participants use Secure Boot with their own platform keys and like the ability to ensure only self-approved binaries boot.
  • Frustration that OEM-provided keys (notably Microsoft’s) are effectively “baked in” and often non-removable in practice.
  • Some argue Secure Boot should have been designed around per-device or user-controlled trust anchors, not global roots of trust.

Usability, Adoption, and Real-World Value

  • Multiple reports of Secure Boot causing boot issues, especially with non-Windows OSes, leading users to distrust any Secure Boot error as “just broken config.”
  • Disagreement on threat model: some see bootkits and “evil maid” attacks as rare for typical users; others note enterprises and governments do worry about physical-access attacks.

Proposed Improvements and Accountability

  • Ideas include: physical write-protect switches for firmware, manual confirmation flows for BIOS updates, hardware read-only toggles for storage, visual tamper indicators, and simpler, auditable firmware (FOSS, minimal ROM code).
  • A few suggest stronger legal liability or professional certification for firmware/boot-chain engineers, though others warn this could harm open-source and shift blame to individuals.