Intel Skylake/Kaby Lake processors: broken hyper-threading [LWN.net]

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 29, 2017 9:03 UTC (Thu) by Sesse (subscriber, #53779)
In reply to: Intel Skylake/Kaby Lake processors: broken hyper-threading by antiphase
Parent article: Intel Skylake/Kaby Lake processors: broken hyper-threading

Yes, it's completely overblown. There are hundreds of similar CPU bugs in any given modern CPU, so there's no reason why this specific one (triggered only by code written in a niche programming language) should be specially publicized.

to post comments

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 29, 2017 9:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Hundreds?!? Can you name a few?

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 29, 2017 10:03 UTC (Thu) by Sesse (subscriber, #53779) [Link]

https://www.intel.com/content/dam/www/public/us/en/docume... lists 173 issues in Haswell alone. Of things that can be hit by an unprivileged user:

HSD45. Certain Combinations of AVX Instructions May Cause Unpredictable System Behavior (sounds familiar?)
HSD136. Software Using Intel(R) TSX May Result In Unpredictable System Behavior (widely published, eventually was so bad that Intel had to rip out TSX from all of Haswell)
HSD142. Interactions Between Multiple Unaligned Memory Accesses And Locked Instructions May Lead to a Machine Check (try to write lock-free code? expect a crash)
HSD145. Operand-Size Override Prefix Causes 64-bit Operand Form of MOVBE Instruction to Cause a #UD (try to load big-endian data? expect a crash)
HSD162. MOVNTDQA From WC Memory May Pass Earlier Locked Instructions (try to use non-temporal loads from GPU memory? your serialization guarantees are off)

This isn't unique to Intel. See e.g. the case a while back where Ryzen would overheat and die if you ran a bunch of AVX muladds in parallel without ever touching memory.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 29, 2017 9:28 UTC (Thu) by jem (subscriber, #24231) [Link] (1 responses)

Hundreds of similar bugs? Do you have a source for this? Yes, CPUs are buggy, but the bugs are often shortcomings in supervisor level units (like the MMU or cache handling), that can be worked around in the operating system code. This time we are talking about "unpredictable behaviour" that can be triggered by a simple sequence of user level instructions.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 29, 2017 11:09 UTC (Thu) by excors (subscriber, #95769) [Link]

Depends what you mean by "similar", and "hundreds" might be an exaggeration if you only count a particular type of bug, though I think it's still slightly worrying to see what a fragile foundation our software is running on (and amazing that in practice it works as well as it does).

ARM seems to avoid publishing errata publicly itself, but e.g. http://www.nxp.com/docs/pcn_attachments/15997_IMX6DQCE.pdf lists about 130 errata for an SoC, including many CPU bugs (Cortex-A9 in this case), of which several sound like they can be triggered by userspace code, including:

"ARM: 743622 - Faulty logic in the Store Buffer may lead to data corruption", triggered by a particular sequence of writes. (Workaround is to disable some Store Buffer optimisation.)

"ARM: 751473 - Under very rare circumstances, Automatic Data prefetcher can lead to deadlock or data corruption". (Workaround is to disable automatic data prefetcher (with minimal effect on performance).)

"ARM: 743623 - Bad interaction between a minimum of seven PLDs and one Non-Cacheable LDM can lead to a deadlock". (Workaround is to not do that, or to globally disable PLD instructions (with significant effect on performance).)

There are also things like https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00906.html (Cortex-A53 multiply-accumulate can give incorrect result) and https://sourceware.org/ml/binutils/2015-03/msg00446.html (Cortex-A53 can get incorrect result from an ADRP instruction near the end of a 4KB page), where the workarounds involve patching the toolchain and rebuilding all the software in the entire world (which is still much cheaper than recalling all the chips).

That's not hundreds, but it seems unsurprising to find several user-triggerable bugs like this in each new CPU. This Intel one seems relatively mild since it can be fixed with a microcode update, no rebuilding or recalling needed.