Skylake, Kaby Lake chips have a crash bug with hyperthreading enabled

A fix is available for Linux systems; Windows users will have to use firmware updates.

Under certain conditions, systems with Skylake or Kaby Lake processors can crash due to a bug that occurs when hyperthreading is enabled. Intel has fixed the bug in a microcode update, but until and unless you install the update, the recommendation is that hyperthreading be disabled in the system firmware.

All Skylake and Kaby Lake processors appear to be affected, with one exception. While the brand-new Skylake-X chips still contain the flaw, their Kaby Lake X counterparts are listed by Intel as being fixed and unaffected.

Systems with the bad hardware will need the microcode fix. The fix appears to have been published back in May, but, as is common with such fixes, there was little to no fanfare around the release. The nature of the flaw and the fact that it has been addressed only came to light this weekend courtesy of a notification from the Debian Linux distribution. This lack of publicity is in spite of all the bug reports pointing to the issue—albeit weird, hard-to-pin-down bug reports, with code that doesn't crash every single time.

Microcode updates can be sourced in two ways. The system firmware can include new microcode that gets installed each time the system boots, and operating systems can also update processor microcode through use of special (proprietary) drivers. For Linux, this typically means using packages from a distribution's "non-free" repository, as no source code for these updates is available. For Windows, this means letting Windows Update do its job; Windows contains drivers for both AMD and Intel microcode updates.

Updated microcode drivers for Linux are available. At the time of writing, the Windows microcode driver does not appear to contain the fix. On the system I'm using, at least, the driver was last updated in March. Insider builds of Windows have a newer driver, updated in June, but that, too, does not appear to include the updated microcode. Although Microsoft does not appear to document which updates are included in each driver version, the information is visible in a hex editor or similar tool; the Linux microcode updater includes four microcodes not found in the Windows driver, including the ones necessary to address this problem.

One would expect that Microsoft will update its microcode driver in due course, at least for Windows 10. Less likely, however, is that the microcode drivers in Windows 7 and 8.1 receive the update. This is one of the implications of the company's new policy of only supporting Skylake and Kaby Lake in Windows 10; there's no need for Redmond to add Kaby Lake updates to Windows 7 and 8.1 when Windows 7 and 8.1 aren't supported on Kaby Lake chips anyway.

In the meantime, a firmware fix—if available—is the best option, though again, availability may be spotty. Microsoft's Surface Book, for example, does not appear to have a system firmware that includes the fix. I don't mean to call out Microsoft specifically—I daresay many motherboard firmwares have similarly not been updated in the month and a half since Intel issued its patch—but rather to indicate that even systems that are still supported and do receive regular firmware updates may not have Intel's latest and greatest microcode yet.

On systems without either a firmware fix or updated driver, disabling hyperthreading is believed to be a robust solution. Most users, however, will probably just want to take their chances; the exact sequence of instructions and runtime conditions that cause problems seem to be rare (certainly rarer than Intel's description of the bug, "Short Loops Which Use AH/BH/CH/DH Registers May Cause Unpredictable System Behavior," might otherwise indicate), and, under most circumstances, affected systems appear to be stable anyway. More than 18 months passed before this bug was fixed, after all, and there haven't been too many reports of Skylake machines crashing left and right because of it.

Eying up AMD systems as an alternative might be tempting, but they're susceptible to comparable issues, too, in which certain sequences of instructions under certain system conditions can cause crashes or other misbehavior. The workaround in AMD's case is to disable the micro-op cache. Processors are certainly more reliable than software, but they all have bugs, no matter what chip you choose.