Security of BIOS/UEFI System Firmware from Attacker and Defender Perspectives
Seeing slides in BIOS-UEFI-Security.6-Mitigations.pdf that imply that there&#x27;s critical crypto being done in SMM mode makes me feel unfathomable hopelessness. The whole x86_64 platform security model (which includes all the privilege levels and the corresponding access control mechanisms) is one hell of an overgrown clusterfuck that could not be <i>more</i> hostile to formal verification.<p>There&#x27;s lots of wantonly convoluted stuff going on -- a random example is the access control mechanism for the PCH&#x27;s GPIOs (search &quot;GPIO registers lockdown&quot;, in quotes). This isn&#x27;t, of course, implemented with a register which contains bitfields determining which privilege level can write to which sets of registers. That would be too simple. The GPIO Lockdown-Enable bit <i>can</i> [sic] be changed by the same software that the lockdown mechanism is meant to deny access to! This seems like utter pointlessness -- what use is an access control mechanism if the agent being restricted can change the parameters of the mechanism willy-nilly -- but Intel has a solution! Changing the lockdown-enable bit triggers an SMI and shunts control to SMM mode, which is, naturally, expected to include code that figures out that this bit should not be disabled, and is to flip it back on (and return from the interrupt, having trashed the caches a bit).<p>This is, of course, a pathologically needless level of complexity -- in the ARM world, we have registers with silly names like &quot;NSACR&quot; that higher-privileged execution modes can set to restrict access to certain resources. There&#x27;s certainly no BIOS-OEM-provided code that needs to exist and be correct in order to implement such a basic task. In the end, this level of access-control is equivalent to a bloody Boolean operation or two, for heaven&#x27;s sake! All the CPU needs to do is to decode the instruction, realise it&#x27;s a potentially-privileged instruction, decode what the instruction tries to modify, look up in a table which register holds the relevant permissions bitfield, and do the relevant boolean operation between that register&#x27;s contents and an appropriate bitmask, and fault depending on the result. Since there&#x27;s an extremely close match between the properties that needs to hold (the truth table of all combinations of &quot;privilege level <i>x</i> can modify resource <i>y</i> iff bit <i>n</i> in register <i>z</i> is set&quot;) and the mechanism that enforces it, it&#x27;s easy to reason about this scheme and not difficult to either prove an implementation correct (or find counterexamples).<p>Meanwhile, the &quot;wake up SMM and hope it&#x27;ll countermands the illegal write&quot; scheme depends on a lot more machinery. How does it work on a multi-core&#x2F;multi-socket platform? How does this mechanism interact with the caches or the memory model? Is it possible to set up a race condition where the illegal write ends up going through uncountermanded because SMM mode can be made to not see the register in an illegal state? This is orders of magnitude of orders of magnitude more complex than analysing a lookup-table and a bitmask -- we need to understand the semantics of memory reads&#x2F;writes, of caching, of mode switches to SMM and the SMI interrupt, and how all of this clusterfuck is affected by the fact that there&#x27;s <i>multiple cores</i> in our system. LANGSEC people will call this a &quot;shotgun parser&quot; -- when input data checking &#x2F; recognition is interspersed with processing logic.<p>Even if all of this miraculously works and there&#x27;s literally no way that all the cores working together can send an illegal write that SMM code won&#x27;t countermand -- there&#x27;s still the issue of making sure that the specific SMM blob that our BIOS OEM wrote cooperates properly with this. Indeed, making BIOS OEMs implement these sorts of convoluted and critical mechanisms and expecting them to get all of them perfectly right requires a level of optimism that doesn&#x27;t yet exist. The situation has devolved to the point that there is literally a tool called &quot;chipsec&quot; that lets you test for the presence of a handful of well-known security-critical things (from time to time someone discovers a new one, of course, UEFI&#x2F;ACPI and the x86_64 privilege model is too complex for people to be sure that we found all the issues) that UEFI programmers are <i>notorious</i> for messing up. That this tool needs to exist is shameful. Of course, the security of the x86_64 platform doesn&#x27;t just depend on a bunch of magic access control registers being set right, there&#x27;s Turing-complete code that needs to be implemented by the BIOS OEM (and runs in the most privileged execution mode that isn&#x27;t Intel&#x27;s &quot;management processor&quot;) that is <i>security-critical</i>, and, well, it&#x27;s hard to prove that arbitrary Turing-complete code behaves correctly.<p>The auxiliary CPU mode (SMM) initially meant to hide APM and emulate PS&#x2F;2 mice in 90s-era computers is now <i>critical</i> to platform security, and does dangerous stuff like crypto and handling pointers from UEFI &#x2F; the OS. Every few months someone I follow on Twitter finds some new way to trick some widely-deployed SMM code into writing to a memory region it shouldn&#x27;t, it&#x27;s quite depressing. Great. Another pointless defender&#x2F;attacker arms race that the defenders could decisively win had Intel thrown away the spitefully complex intricacies of SMM and the x86 security model and replaced it with a clean, formal-verification-friendly set of privilege levels whose correct operation doesn&#x27;t depend on platform firmware code. Even AArch64 is less broken when it comes to this.