Benchmarks Of JCC Erratum: A New Intel CPU Bug With Performance Implications On Skylake Through Cascade Lake

[Slartifartblast]

Intel, meet Boeing as I'm sure you will get on very well as you have a lot in common.

[angrypie]

0 (zero) days without Intel's leaky CPUs in the news. Our record is 0 (zero) days.

[Hugh]

The LLVM toolchain includes an assembler. Is that being updated or do all x86-64 systems use gas (GCC's assembler)?

[archsway]

The LLVM toolchain includes an assembler. Is that being updated or do all x86-64 systems use gas (GCC's assembler)?

Anything that generates x86 code (not just position independent assembly) will need to be updated, which includes assemblers and JIT compilers.

LLVM defaults to using its own assembler, which it would have to do on BSD's etc. where GCC is outdated and its assembler missing more recent instructions.

[blargh4]

Considering that there's plenty of proprietary software out there that will never get recompiled to account for this issue, the patch is necessary. Try paying attention to what you're reading next time.

I'm aware of proprietary software. Where did you read anything more specific about the effects of this bug than "unpredictable behavior"?

If it's an exploitable security vulnerability (and I haven't seen it described as such), ok, I guess you gotta fix it. If it's just something that causes the computer or program to crash, I'm not sure a 5% slowdown is worth fixing an issue I'm not aware of being bitten by in all my years of using Skylake cores (despite it being a very fundamental instruction class that any real program will stress heavily).

[hotaru]

If it's an exploitable security vulnerability (and I haven't seen it described as such), ok, I guess you gotta fix it. If it's just something that causes the computer or program to crash, I'm not sure a 5% slowdown is worth fixing an issue I'm not aware of being bitten by in all my years of using Skylake cores (despite it being a very fundamental instruction class that any real program will stress heavily).

If it's just something that causes the computer or program to crash, that's still a security vulnerability.

[Hugh]

I am mystified by how a bug in conditional branch instructions could have been overlooked for 5 years in what has to be the most widely-deployed CPU design in the world. Surely that's among the most common classes of instructions in any program? I can't imagine how fixing something that seems to be astronomically improbable would be worth the performance hit, vs just patching the affected applications.

We do know that the bug doesn't manifest itself very often. JCC ending on or crossing a 32 byte boundary is very very common and yet few users have observed a problem with them.

Intel has not told us what conditions trigger the bug. Clearly one is the alignment of jcc instructions but there must more requirements for the bug to fire. I would guess that some of the other conditions are dynamic and not inherent in the program's static instruction stream.

The microcode patch is the way that Intel has chosen to ensure that the processor meets its specifications. We should all demand that a processor meets its specifications. Even at the cost of performance. There might be a better microcode patch to accomplish the same thing, but the processor isn't open source so we cannot know. Just be glad that Intel didn't have to turn off the whole Decoded I-Cache mechanism.

One thing we don't know is if any of the additional conditions are inherent in the program's instruction stream. But it doesn't matter at this point: Intel has detuned a very common sequence and machine code generators should now avoid that sequence for performance reasons (not correctness reasons).

Unfortunately changing machine code to avoid slowed down JCCs will have the side-effect of detuning unaffected processors (eg. AMD, Atom, pre-Skylake): most software isn't optimized for a particular variant of the x86-64 architecture. How much? Time for a Phoronix Test Report!

[Hugh]

The way that Intel has changed GAS is to add effectless prefix bytes to certain instructions, pushing the JCC past the 32B boundary. Perhaps a little trickier logic would be better.

For example, if the JCC is in a loop, pushing the loop might allow the body of the loop to remain tight.

For example, sometimes instructions can be moved across a loop; if that fixes the alignment, that would be better than adding effectless prefix bytes.

Intel suggests a certain effectless prefix byte. I presume that that prefix is very efficient on Intel's recent Core processors. Is it efficient on other implementations (eg. AMD)?

[Hugh]

I downloaded the latest Clear Linux live .iso to try it. I booted it on an HP Stream Mini. It could not get X going, probably because the box had only 2G of RAM, but somehow I got to a text console.

I was wondering how much had been recompiled with the assembler patch. But I don't know when the assembler was changed so the dates on the binaries are not conclusive.

Lots of /usr/bin was surely too old to have been recompiled.

I tried to figure out firefox, but that was confusing. When you try to run firefox for the first time, it runs a script to unpack a tarball. Into your home directory, I think!

The tarball is dated 2019 February 1, but many of the file it contains are dated 2019 Oct 30. Kind of funny. Oct 30 is surely after the assembler changes had been adopted by Intel. But the shipped GCC is even newer.

[runjet]

Isn't 0x2000064 an old microcode update from July not the recent November one?