Secure Boot is broken on 200 models from 5 big device makers
A newly revealed flaw in UEFI Secure Boot affects around 200 PC models, after vendors shipped systems with an AMI “test” platform key that should never have been trusted in production. Commenters argue this exposes deeper problems: OEMs’ poor key management, over-reliance on Microsoft-controlled keys, and the lack of a true, user-controlled hardware root of trust on most PCs. While some see Secure Boot as valuable for preventing persistent boot‑level malware, others view it as fragile, hard to manage correctly, and easily co-opted to lock down general‑purpose computing rather than to protect end users.
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.