UEFI boot: how does that actually work, then? (2014)
&gt; <i>And no, Secure Boot itself is not evil. I am entirely comfortable stating this as a fact, and you should be too, unless you think GPG is evil</i><p>Actually no, secure boot <i>is</i> evil, and comparing it to GPG is fallacious. The objection isn&#x27;t to code signatures in general, but the inevitability of baked-in privileged keys inherent in its design. Calling it just an impartial mechanism is flat out naive, and the author even goes on to describe why:<p>&gt; <i>But it’s worth noting it’s no more bad or wrong than most other major ARM platforms. Apple locks down the bootloader on all iDevices, and most Android devices also ship with locked bootloaders.</i><p>While Microsoft exempts x64 hardware because they&#x27;re concerned about further anti-trust action, the ARM ecosystem actually demonstrates the end result. By providing these companies the <i>capability</i> to lock things down, they inevitably <i>will</i> use it to enforce their inherent authoritarianism onto their customers. The majority of their customers will not care, accepting the age-old excuses for authoritarianism like &quot;security&quot;. But capturing a pragmatic majority does not make something <i>right</i>, as apparent to anybody who struggled due to Microsoft&#x27;s monopoly in its heyday.<p>A freedom-preserving boot verification specification is definitely possible. In such, there must be no privileged key that cannot be disabled or augmented. Microsoft&#x27;s x64 requirements do fulfill this, but as a result cause the system to fall to evil maid attacks. However, evil maid attacks can be prevented by incorporating an open-to-all proof-of-work &#x2F; timed-lockout scheme. The core specification must incorporate this type of non-privileging scheme as a <i>required</i> element, to preempt any contractual requirements like Microsoft&#x27;s.