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

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 26, 2017 23:05 UTC (Mon) by antiphase (subscriber, #111993)
Parent article: Intel Skylake/Kaby Lake processors: broken hyper-threading

I don't doubt that there is a flaw here but given that the oldest of these processors are approaching 2 years old and have been manufactured and used in huge volumes since, and this is apparently the first warning of their DANGEROUS MISBEHAVIOUR, is this possibly not a bit sensationalist?

to post comments

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 26, 2017 23:12 UTC (Mon) by k8to (guest, #15413) [Link] (4 responses)

Hard to evaluate. Sometimes problems go undetected for some time even when affecting people, if the expression of the problem isn't obvious enough, or is scattered enough to not be tied to the hardware.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 1:48 UTC (Tue) by areilly (guest, #87829) [Link] (3 responses)

When you think about the nature of the issue (mixed byte and word access specifically involving the high byte of the four registers that have one, in a tight loop), it seems very unlikely that there will be much compiled code that has this particular pattern in it. Indeed, I couldn't find any on a quick scan over my system. On modern x86_64, compilers will be using the %[abcd]l registers if they ever want bytes, because those correspond to the only available byte-chunks of the %r[8-15]l registers. A write to one of the %...h bytes in a tight loop. Can't think of a use-case, myself. Makes me wonder what the OCaml folk were doing with it, to find the pattern.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 4:36 UTC (Tue) by eru (subscriber, #2753) [Link] (2 responses)

Would it not be a reasonable translation of char b = i >> 8? (with no other usage of the value i >> 8 nearby).

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 5:11 UTC (Tue) by areilly (guest, #87829) [Link]

Yes, and I've just verified that clang (at least) will generate movb %dh, 0(%rax) in at least one test case. Put it in a loop though and it'll happily vectorise it into shifts and shuffles.

That use doesn't feel like one that would upset a modern (threaded) pipeline though, because there is no chance of a write-after-read style problem. I think that the issue is much more likely to involve writing to one of the [abcd]h registers, which would need to be unpacked into a read-modify-update sequence of micro-ops. For "make an int from left-shifted bytes" style code, I've only seen the compiler generate byte loads followed by left-shifts, rather than loading byte values directly into high reg bytes.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 17:46 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

Yes, but the compiler likely would only generate it at -Os (optimize for size).

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 26, 2017 23:18 UTC (Mon) by jgg (subscriber, #55211) [Link] (3 responses)

Probably.. The remarkable thing here is that Intel's internal randomised testing wasn't able to uncover this in the last two years. Usually once a major CPU is produced in silicon there is extensive randomised A/B testing performed on instruction sequences to look for variations relative to the golden architectural model, so this must be a remarkably unlikely combination of things if testing of two generations of CPU failed to uncover it.. Often this kind of testing finds all kinds of crazy and unlikely stuff.

The truth is new CPU architectures are usually pretty buggy in the first couple of steppings. The are full of disable bits and configuration stuff that the CPU vendor recommends to the BIOS to setup..

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 6:35 UTC (Tue) by ncm (guest, #165) [Link] (2 responses)

This should not be surprising. All modern CPUs are filled with bugs, just as all useful programs (excepting DKK's and DJB's) are filled with bugs and security holes. You only worry about the ones causing problems right now, because there isn't enough worrying capacity in the world to cover them all. You are much more likely to die from a car accident or cancer than to suffer much from a CPU bug.

But wouldn't catch me depending on one, no sirree.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 30, 2017 8:44 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> You are much more likely to die from a car accident or cancer than to suffer much from a CPU bug.

Soon we'll die from a car accident *and* a CPU bug.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Dec 19, 2017 23:57 UTC (Tue) by immibis (subscriber, #105511) [Link]

And then a car accident *caused by* a CPU bug.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 1:58 UTC (Tue) by NightMonkey (subscriber, #23051) [Link] (1 responses)

My Dell Precision 5510 laptop has a matching signature. Don't laptops often lag behind servers and desktops in processor chipset deployments?

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jul 2, 2017 14:59 UTC (Sun) by anton (subscriber, #25547) [Link]

No, laptops are sometimes first (e.g., Kaby Lake, Broadwell, Carrizo).

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 3:45 UTC (Tue) by rsidd (guest, #2582) [Link]

Silent data corruption, even if unlikely but possible, would be seen by some of us as sufficiently dangerous to warrant this warning. Unfortunately, particularly in Windows-land, people are likely to attribute it to things other than a CPU bug, especially if it is rare.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 9:51 UTC (Tue) by edeloget (subscriber, #88392) [Link] (1 responses)

Considering that abnormal behaviors are likely to be exploited by malicious users (at least to perform some kind of DOS attack), and considering that many servers out there feature these processors, I would not call that "sensationalism".

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 12:11 UTC (Tue) by nix (subscriber, #2304) [Link]

Skylake and Kaby Lake are too new to appear in any but very expensive server-class processors until very recently (the last few months). v4 and even v3 (Broadwell and older) are still on sale in fairly expensive servers. Server users are fairly conservative, often because of, well, bugs like this...

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 14:32 UTC (Tue) by rahvin (guest, #16953) [Link]

It's not overblown if your computer is the one that keeps crashing.

Does it need immediate patching? That would depend I guess on whether you've experienced a bunch of unexplained crashes or corrupted data. From some of what I read it's a pretty difficult bug to trigger but if you're the guy with the code that's triggering it you probably want a solution. One thing I can say, it's pretty friggen cool that Linux saw the patch so fast, it'll be a month before windows gets it.

Intel Skylake/Kaby Lake processors: broken hyper-threading

Posted Jun 27, 2017 17:48 UTC (Tue) by dlang (guest, #313) [Link]

I remember the Pentium floating point bug. It took a while for it to be detected and tracked down as well.

Intel Skylake/Kaby Lake processors: broken hyper-threading

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

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.

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.