This site may earn affiliate commissions from the links on this page. Terms of employ.

Ever since Intel introduced Hyper-Threading (known generically as Simultaneous Multi-Threading), debates almost whether or not to disable the feature have almost entirely revolved around its bear on on performance. Back when the feature debuted, information technology wasn't unusual for programs to misinterpret what information technology meant for a organisation to take a virtual CPU core as opposed to a second physical chip (dorsum then, information technology was one core to a socket, no exceptions, and programs didn't differentiate between a physical and a logical CPU cadre). As software and operating systems were updated, HT settled down and information technology's less common today to need to shut it off to preserve performance. But in the wake of Spectre, Meltdown, and Foreshadow, serious concerns have been raised about the security implications of Hyper-Threading.

Theo de Raadt, the founder of OpenBSD, argues that HT can no longer be trusted and should be disabled by default. ExtremeTech reached out to de Raadt to discuss the event and why he and other developers in the open-source software community are concerned about the security risks of Hyper-Threading.

Co-ordinate to de Raadt, every operating organization is either adding the ability to disable Simultaneous Multi-Threading (Intel's Hyper-Threading is a specific implementation of SMT) or modifying their schedulers "to avoid cotenancy on SMP cpus of dissimilar security domains." Symmetric Multi-Processing, or SMP, refers to the modern do of having multiple CPU cores on a single die, all with access to a combined pool of memory and devices. In contrast, Intel's Hyper-Threading shares certain resources between the physical core and its logical counterpart, including translation lookaside buffers (TLBs), the L1 data enshroud, and the branch target enshroud (BTC) without providing any power to differentiate betwixt security domains and isolate information between the two CPU cores.

Equally we've previously discussed, Spectre, Meltdown, and Foreshadow are all flaws that exploit certain behavior that Intel CPUs engage in when they speculatively execute instructions. While speculative execution is a longstanding and proven technique for improving overall CPU performance, de Raadt identifies three singled-out issues that have combined to create these bug. He writes:

1) Intel CPUs fetch and decode and execute instructions including their data loads without doing any security checks, and then unwind them if they were wrong subsequently the fact. CPUs from other vendors have experienced pocket-sized spectre issues, but Intel takes it to a whole new level.

ii) Since they don't exercise security checks up front, and necktie their L1D to their TLB, Intel has a really astounding "where did a cache line come from, we don't intendance" fault in their L1D cache, which results in data in a cache line from a different privilege domain condign visible to speculative instructions, which creates a further spectre problem.

3) The aforementioned speculation without security bank check applies to registers. Intel didn't even check if the FPU is enabled, before accessing FPU registers. Then they really don't do *any security checks* before running an instruction. ALL decisions are made at the end. That ways ALL teaching sequences take spectre side effects, and we are simply waiting for people to find worse consequences and publish them.

de Raadt as well criticized Intel's disclosure policies, noting that OpenBSD has had to report workarounds in other projects, like Xen and FreeBSD, to create their own solutions. He believes information technology's probable that we'll keep to see more than security flaws related to Spectre and that there's a possibility for black hats to combine different methods of exploiting these flaws to break security models. Foreshadow, it could be argued, is one such attack. While more complex than the starting time variants of Spectre, it tin as well be used to pause Intel'due south Software Guard eXtensions, or SGX — and SGX was supposed to be immune to this kind of attack. There's fifty-fifty a chance that these attacks could be used to leak address information, which means Spectre and Rowhammer could be combined. It's the gift that keeps on giving.

Image past XKCD. Flavor text: "In addition to rowhammer, it turns out lots of servers are vulnerable to regular hammers, too."

Thus far, OpenBSD is the get-go operating arrangement to call for disabling HT altogether — Intel's official guidance is that HT does not need to exist disabled if all other fixes and patches take been deployed. But it'south incredibly difficult to practically guarantee that all necessary security contexts volition be maintained and respected in the absenteeism of hardware restrictions that foreclose two dissimilar processes operating in different security domains from running at the same time. Fifty-fifty if you tin ensure that the processes running on a CPU are compatible from a security domain perspective, as soon equally the security domain of one of those processes shifts, yous'd have to evict it from the CPU core it's running on and put it somewhere else — flushing the caches and TLB in the process. Modern Bone schedulers regularly move workloads across CPU cores to optimize execution, only forcing a CPU to exercise this in the name of security tin carry a heavy functioning striking. We've already seen some evidence of this in Spectre, although the tests that exposed it tended to be worst-example scenarios.

Is AMD Affected?

Thus far, almost all the give-and-take around Spectre, Meltdown, and Foreshadow has focused on Intel. There's a practical reason for this. These attacks are believed to threaten the security of cloud and enterprise server providers and Intel dominates these markets. Prior to the launch of Epyc, Intel held 99% of the x86 server market and the overwhelming majority of servers sold per year are x86 machines. AMD has begun to scrap abroad at Intel'due south marketplace dominance, only CEO Lisa Su has stated her company is targeting mid single-digit percentages of the market place by the cease of 2022. Even if AMD and Intel were equally exposed technically, Intel would be shouldering virtually the entire effective exposure.

Merely while this could alter in the hereafter, current evidence suggests AMD CPUs aren't almost as vulnerable as their Intel counterparts. AMD has released a statement indicating that it isn't impacted past Foreshadow, which Intel calls the L1TF (L1 Terminal Fault). It recommends that its customers not implement Foreshadow protections at this time and states that its CPUs are protected by hardware paging compages protections congenital into Epyc CPUs.

AMD-SMT-Zen

One additional slice of show in AMD's favor is that the company's SMT implementation is known to exist unlike from Intel'due south. Nosotros've previously merely discussed these differences in terms of their affect on operation, simply the slide in a higher place does note that the L0/L1/L2 ITLBs and L1/L2 DTLBs are shared merely "SMT tagged," which means they tin merely be accessed by the thread that owns them. The devil is absolutely in the details on problems like this, and we don't want to imply that this unmarried slide establishes the caste to which AMD's SMT implementation is or is not secure, but AMD does announced to accept implemented protections in sure areas that Intel lacks. It's possible, for example, that time to come attacks could be based on enshroud evictions rather than speculative loads, and this type of tagging might not protect confronting such alternatives. In our chat, de Raadt notes that OpenBSD has also made changes to disable SMT and CMT (that's Bulldozer'southward core-sharing engineering science) on AMD CPUs out of an abundance of caution, despite not knowing if the CPUs will ultimately testify to exist vulnerable to this blazon of attack.

Equally of this writing, OpenBSD 6.four (expected in Oct / November) is the first OS to avoid all use of Hyper-Threading and disable information technology by default, merely other operating systems, like Red Hat, have appear that they will ship kernels with updated controls assuasive users to choose whether to disable the feature or not. Whether other vendors follow Theo de Raadt's lead may depend on what vulnerability disclosures driblet next and how serious the side by side round of exploits is. Intel has appear that its upcoming Cascade Lake platform will contain hardware fixes for some Spectre variants, while others will even so exist mitigated by software solutions or a combination of the two. That'due south one bespeak everyone in the security manufacture seems to hold on: There volition be new disclosures and security issues related to Spectre that haven't happened even so.

At present Read: What is Speculative Execution, Intel Details Pour Lake Hardware Mitigations for Meltdown, Spectre, and New Foreshadow Security Flaw Breaks Intel SGX