You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: About/Heads-threat-model.md
+20Lines changed: 20 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -505,3 +505,23 @@ Heads is not designed for "Cover" or "Concealment"
505
505
best tradeoff: Heads can help protect your system against a business
506
506
competitor, but there is no "NSA proof toolkit" that can stop a nation state
507
507
from making you have a very bad day.
508
+
509
+
Binary blobs, microcode updates and transient execution vulnerabilities
510
+
===
511
+
With the disclosure of the Spectre and Meltdown vulnerabilities in January 2018, it became apparent that most processors manufactured since the late 1990s can potentially be compromised by attacks made possible because of [transient execution CPU vulnerabilities](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability). Modern CPUs utilize speculative execution in order to increase performance. A branch misprediction may leave observable side effects that may reveal private data to attackers using a timing attack. Future not-yet-identified vulnerabilities of this kind is likely. For users of Qubes OS, this class of vulnerabilities can additionally compromise the enforced isolation of virtual machines, and it is prudent to take the risks associated with these vulnerabilities into account when deciding on a platform on which to run Heads and Qubes OS.
512
+
513
+
Mitigation of these vulnerabilities is achieved through a combination of microcode updates for the CPU and software mitigation techniques. For linux systems, software mitigation includes the implementation of retpolines and kernel page-table isolation. However, some of the vulnerabilities of this class cannot be effectively mitigated without updated CPU microcode.
514
+
515
+
Heads is built as a payload for Coreboot, which includes the latest available microcode updates for CPUs on supported platforms. However, Intel has stated publicly they will not release further microcode updates for products they consider discontinued and unsupported. This includes processors from the Sandy Bridge and Ivy Bridge line of CPUs. Notably this means all ThinkPad models supported by Heads will most likely not receive further microcode updates to protect against future vulnerabilities of this class. A list of current vulnerabilities and whether microcode updates are available is provided by [Intel](https://software.intel.com/content/www/us/en/develop/topics/software-security-guidance/processors-affected-consolidated-product-cpu-model.html). AMD is less affected by these vulnerabilities because speculative execution is implemented differently.
516
+
517
+
Operating systems (e.g. Qubes OS) can mitigate some of these vulnerabilities by other means. An example is the SRBDS vulnerability, where the Xen hypervisor can apply a [workaround](https://seclists.org/oss-sec/2020/q2/182) to mitigate the vulnerability for Ivy Bridge CPUs, which will not receive any microcode update. It is uncertain whether such mitigations are possible in the future without microcode updates supplied from the CPU manufacturer.
518
+
519
+
The impact on performance as a result of software and microcode mitigations vary between systems and the type of workloads involved. Compared to a system not applying any mitigation measures, a conservative estimate is that the percentage of lost performance is in the low double digit range. Furthermore, as part of mitigating the L1TF vulnerability, Qubes OS [disables](https://www.qubes-os.org/news/2018/09/02/qsb-43/) HyperThreading by default. This has a notable impact on performance in itself, effectively halving the number of cores visible to the system, but is implemented to minimize vulnerability.
520
+
521
+
The ThinkPad boards supported by Heads are mostly free of binary blobs, with the exception of the Intel Management Engine (which can be "neutered" or minimized) and the ethernet blob (which can be generated). CPU microcode can also technically be considered a binary blob.
522
+
523
+
The Embedded Controller chip (EC) also uses its own firmare. The chip is responsible for certain system tasks not handled by the operating system, such as keyboard hotkeys, thermals, hardware toggle switches etc. It should be noted that the EC can only be updated as part of the propietary Lenovo BIOS update. It is therefore advisable to flash the latest Lenovo BIOS prior to flashing Heads, in order to have an up-to-date EC. It is possible to make certain changes to the EC by [modifying](https://github.com/hamishcoleman/thinkpad-ec) the official Lenovo BIOS update before flashing, e.g. to allow for a classic 7-row keyboard in the X230. Coreboot/Heads will not touch the EC.
524
+
525
+
Newer hardware platforms like the Librem line of computers, while great care has been taken by Purism to minimize blobs, still contain the closed-source Intel FSP (Firmware Support Package, needed to initialise memory/silicon). However, the CPUs used in these computers are newer, and thus will perceivably receive microcode updates for some time. They generally also allow for more RAM and arguably more modern hardware in general.
526
+
527
+
When choosing a platform for Heads/Qubes OS, the user must make an informed decision on whether the presence of binary blobs and potential security benefits in future microcode updates outweigh the desirability of maximum control over the firmware on the hardware platform. In addition, the user must take into account the limitations on hardware performance by the various supported boards, and whether the potential increase in performance afforded by a more recent CPU and additional RAM is desirable to compensate for performance reductions as a result of mitigating these vulnerabilities.
0 commit comments