Do you have an Intel Skylake and Kaby Lake processor under your computer’s hood? Have you experienced unexplained application and system hiccups, data corruption, or data loss? It could be because your chipset has hyper-threading enabled and the chips are malfunctioning.
Henrique de Moraes Holschuh, a Debian Linux developer, revealed the Intel chip problem on the Debian developer list. Officially, Intel hasn’t acknowledged the problem, but engineers at Dell and Intel have told me that the problem, and its fix, exists.
This processor/microcode defect has been found on Intel Skylake and Intel Kaby Lake processors with hyper-threading enabled. Besides these 6th and 7th generation Intel Core processors, its also found on its related server processors, such as Xeon v5 and Xeon v6, and some select Intel Pentium processor models.
While the Debian community revealed the problem, it’s not Linux-specific. Any operating system — Windows, macOS,FreeBSD, you name it — can run into the problem.
According to Intel chip errata, “Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active.”
This will lead to the computer experiencing “unpredictable system behavior.” What programs will cause a computer to act up? That’s a good question, and we don’t have a good answer. As Holschuh wrote, “We do not have enough information at this time to know how much software out there will trigger this specific defect.”
The problem was first uncovered by Ocaml developers when they encountered it while testing a new compiler in January 2017. The problem, however, was traced back to Intel processors that arrived on the market in 2016’s second quarter.
Others may have run into the problem many times and not known it. That’s because it shows up erratically and people are used to looking for problems in programs and not processors.
Intel, the major commercial Linux distributions, and computer original equipment manufacturers (OEMS) are working on delivering a microcode update for these processors that will fix this problem. I am certain that Apple and Microsoft are also addressing this issue.
In the meantime, Linux users can see if their computers have been acting flaky because of this problem by running the following shell commands.
First, to see if you have a potentially vulnerable CPU run:
$ grep name /proc/cpuinfo | sort -u
Once you know your processor model name, check the following sites to see if it’s listed: Skylake and Kaby Lake. If it is, then run the following shell program:
$ grep -q ‘^flags.*[[:space:]]ht[[:space:]]’ /proc/cpuinfo && \ echo “Hyper-threading is supported”
If you get the result,”Hyper-threading is supported” you have a problem; otherwise, you’re fine.
If you do get the bad-news message on a Kaby Lake processor, you should disable hyper-threading in your PC’s BIOS/UEFI configuration. There is a fix for this, but it’s not been released — to the best of my knowledge — to end-users or operating system vendors yet. OEMs do have access to it, but they’re still testing the microcode patch to make sure it works with their computers.
You can patch the problem on some Skylake processors. If your processor model (listed in /proc/cpuinfo) is 78 or 94, a stepping of 3, Linux users can install the “intel-microcode” package version 3.20170511.1. This is the most recent, June 17th, 2017, Intel microcode release. To do this on Debian, follow Debian’s microcode update instructions. Canonical is also working on fixing the problem for Ubuntu Linux. Sources at Red Hat tell me a fix will soon be on its way for its Linux distributions as well.
If your processor isn’t patchable then you will want to disable your Skylake’s system’s hyper-threading.
To date, no one has found a way to exploit this for a malware attack, but it seems likely that it’s only a matter of time before someone uses it for a denial of service attack. Before that happens, I have every hope that the microcode update to all users via their hardware vendors and/or their operating system distributors.