The now-infamous Spectre and Meltdown vulnerabilities were first disclosed on January 4, 2018. The duo busted open the door on what is collectively known as “transient execution attacks,” which have proven difficult to patch. Fundamentally, as Spectre and Meltdown are hardware-level vulnerabilities, patching around them in software is an order of magnitude more difficult than software vulnerabilities. The first round of patches focused primarily on inhibiting the exploitation of a specific variant, rather than the design flaw which enables these attacks.
How has the vulnerability progressed?
Further work by some of the original researchers behind the first disclosure revealed additional variants. The researchers produced what they characterize as “a complete picture of the attack surface,” including theorized variants, which were unsuccessful in testing (green, dashed).
From the above, the researchers indicate that Spectre-PHT, Spectre-BTB, Spectre-STL, and Spectre-RSB are the only possible variants, each named for the component targeted. In practice, this is a substantial simplification, as attack variants can target multiple components at once. Likewise, the researchers indicate that SgxPectre and other related disclosures focus on how the vulnerabilities can be exploited, and are not included in this classification tree.
SEE: Spectre and Meltdown: An insider’s guide (Tech Pro Research)
For Meltdown, the researchers state “In the first level, we categorize attacks based on the exception that causes the transient execution. Second, for page faults, we further categorize based on page-table entry protection bits. We also categorize attacks based on which storage locations can be reached, and whether it crosses a privilege boundary.” All potential outcomes from those conditions are listed in the above classification tree.
How effective are patches?
Intel has issued some microcode patches to patch certain behaviors of the affected CPUs. The initial patches for the vulnerability caused system instability, prompting Microsoft to disable the initial updates prompting sudden reboots. New microcode was issued several times throughout 2018, as new variants are discovered and refinements to existing patches are developed.
Because of the closed-source nature of Windows, gaining an understanding of how this is mitigated at the kernel level is difficult to know. Microsoft’s increasingly opaque patch notes serve to further complicate the situation. Microsoft’s first round of patches in January caused crashes on AMD systems, and was halted initially due to clashes with third-party antivirus products. Security researcher Alex Ionescu developed SpecuCheck to list what patches are available and applied for Windows systems. Microsoft is planning to incorporate Google’s Retpoline patch in an update to Windows in 2019.
For Linux, performance regressions accompanied certain fixes. Early in the year, concerns about Kernel Page Table Isolation (KPTI) caused mass panic, with early reports estimating a performance regression of 30%, though these estimates relied on unequal comparisons. Linux kernel 4.20 enabled a mitigation called Single Thread Indirect Branch Predictors (STIBP) for Intel processors, which has demonstrated performance degradation of up to 50%.
SEE: How to disable simultaneous multithreading on Lenovo ThinkPads (TechRepublic)
This will be reverted in future versions. Security-minded users began disabling symmetric multithreading on critical systems outright, in light of the related TLBleed and PortSmash vulnerabilities. These vulnerabilities, also disclosed in 2018, demonstrate that it is technically feasible for a malicious program running in a single thread in a given physical core to extract data from the other thread in that physical core.
So, what’s the verdict?
Available mitigations are a work-in-progress. It is unclear if the vulnerabilities can be completely patched through microcode and software updates. The biggest hope for a definite fix to the issue is new hardware. Intel plans to ship hardware-level fixes to some of the variants as part of the Coffee Lake-S Refresh series of Workstation CPUs, as well as Xeon Cascade Lake CPUs for servers.
Best advice for the security conscious, of course, is to keep patching. Disabling SMT may be worth it-depending on your workload, the performance penalty may be negligible anyway. At least attempting a deployment for A/B testing to measure would give an indication of the potential impact.