Secure boot certificate rollover is real but probably won't hurt you

Concerns about obsolescence and lock-in

• Some expect vendors to use the new Secure Boot certificate to invalidate the old one quickly, effectively forcing OS and hardware upgrades and accelerating GPU and device obsolescence “for security.”
• Others object strongly to bricking otherwise-working GPUs and older OSes, seeing it as needless e-waste and planned obsolescence.

Ability to disable Secure Boot and device classes

• A recurring counterpoint: on PCs you can usually just disable Secure Boot in firmware, so even worst‑case you keep control.
• Skeptics argue this option is being eroded: many phones, tablets, IoT, routers, and some ARM devices already prevent bootloader unlocking or OS replacement.
• Historical examples (e.g. Surface RT) show that on some ARM “PC‑like” hardware Secure Boot has been used to fully lock out alternative OSes, but others note that this approach largely failed in the PC market.

Secure Boot’s security value

• Critics point to unenforced certificate expiry, LogoFAIL, and debug keys to claim Secure Boot delivers more friction than real security, especially for individual owners.
• Defenders say it still raises the bar: blocking bootkits and unauthorized OS replacement is materially harder, even if not impossible.
• Corporate scenarios where it helps: protecting BitLocker keys, ensuring laptops haven’t been tampered with, restricting field devices from booting arbitrary OSes, and satisfying auditors.
• Some note that anticheat and content services increasingly require Secure Boot, reducing practical freedom to turn it off.

Linux, Windows, and desktop security debate

• One thread argues desktop Linux users often undervalue security (e.g., curl | bash), while others counter that Linux offers strong layered defenses (MAC, containers, repos) and a different software-distribution model than “download random .exe.”
• The xz backdoor is cited both as evidence that repositories aren’t perfectly vetted and as proof that open ecosystems can detect and react quickly.

Certificate rollover mechanics and impact

• Technical discussion clarifies the PK/KEK/db/dbx hierarchy and that new Microsoft keys must be added by firmware vendors (for KEK) or users (for db) to ensure future-signed binaries boot and revocations can be applied.
• Manually importing new db keys is possible but nontrivial; some firmware doesn’t expose the necessary setup mode, forcing reliance on Microsoft’s shim path or vendor firmware updates.
• Several commenters conclude that for most Linux users, disabling Secure Boot altogether would not significantly reduce their real-world security.