3 ms·
> Most vendors are wary about automatically applying updates which revoke keys used for Secure Boot. Existing SB-enabled software installations may suddenly ref
by cesarb 6y ago
> Most vendors are wary about automatically applying updates which revoke keys used for Secure Boot. Existing SB-enabled software installations may suddenly refuse to boot altogether, unless the user is careful to also install all the needed software updates as well. Dual-boot Windows/Linux systems may suddenly stop booting Linux. Old installation and live media will of course also fail to boot, potentially making it harder to recover systems.
That means: with Secure Boot enabled, once the machine's firmware is updated, all currrently existing Linux install media will stop working. Users have to either wait for new install media to be released, or disable Secure Boot. At least it's still possible to disable Secure Boot, or enroll your own keys; will that still be the case once x86 CPUs start being replaced with ARM CPUs? IIRC, Microsoft requires that systems with ARM CPUs not allow disabling Secure Boot or enrolling your own keys (https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/ https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-c...).
- cmurf 6y agoThe requirement to disallow users disabling UEFI Secure Boot on ARM, applies to the Windows hardware certification spec. There's no requirement that a vendor must follow that spec in order for the hardware to run Windows. It is a spec designed to tie co-marketing of Windows and your product, e.g. "made for Windows" with minimum compatibility standards (or at least Microsoft's idea of minimums). For example it also requires a TPM 2.0 be present and enabled.
- floatboth 6y agoNo, that was the case for the old Windows RT devices (see that 2012 in the URL…). With the modern ARM devices like the Surface Pro X, the Microsoft requirement is like with x86: required to allow disabling Secure Boot.