
GNU Assembler Patches For Optimizing The Intel Jump Conditional Code Erratum - chris_overseas
https://www.phoronix.com/scan.php?page=news_item&px=GNU-Assembler-Patches-JCC
======
atq2119
The headline feels a bit too click-baity, but this really is serious stuff.

One of the most fundamental instructions of x86, the Jcc conditional jump, can
apparently be executed incorrectly by most Intel CPUs out there.

What's worse, part of Intel's strategy for mitigation is to push compiler
toolchain changes that, if deployed as they desire, will punish the
performance of _everybody_ on x86, including those who are using unaffected
processors ( _cough_ AMD _cough_ ).

~~~
damageboy
OP from twitter here. I'll take the blame for the click-baity-ness, but I was
really shocked and this was in real-time in my defense.

I'm assuming it will get resolved, as the errata suggests by shoving lots of
0x2c segment overrides to re-align those jumps.

The price won't be 0, but will definitely less than the very extreme 20% edge
case I stumbled upon.

I'm more "worried" or annoyed by older binaries that will never get updated.
But hey... (；⌣̀_⌣́)

~~~
chris_overseas
For those not understanding the context of the parent's comment, this HN post
originally linked to @damageboy's
[https://twitter.com/damageboy/status/1194751035136450560](https://twitter.com/damageboy/status/1194751035136450560)
tweet showing a 20% performance hit, but was later changed by mods to link to
the phoronix.com article.

------
mmastrac
This was pretty terrible. I wouldn't be surprised if this was responsible for
a good number of heisenbugs on a few platforms.

Not only can you _not_ use a jump instruction ending or crossing a 32-byte
boundary, but you can't use a "macro-fused" pair of instructions like
cmp+jump! [1]

The fix is _relatively_ simple [2] on affected platforms as they will likely
be able to pad an appropriate level of NOPs to avoid that boundary before
emitting a problematic set of instructions, but you will be taking a perf hit
equivalent to losing a bunch of cache memory to useless NOPs and a (likely
small) amount of power/time to skip those NOPs in the instruction stream.

Where this gets ugly: people shipping binaries will have the choice of
mitigating this for everyone (padding out code+small perf impact on non-
affected platforms) or hitting a very slow code path on affected systems.

[1]
[https://www.intel.com/content/dam/support/us/en/documents/pr...](https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-
jump-conditional-code-erratum.pdf)

[2] Edit: the recommended fix from the whitepaper appears to be padding out
earlier instructions via a "benign" prefix rather than adding NOPs.

------
lousken
Intel is becoming a meme with those 30-50 page erratas in their documents.
When they can't improve IPC or nm tech why don't they at least focus on fixing
bugs?

~~~
raxxorrax
Well, if they fix this bug the hardware will become slower in any case.
Honestly I don't understand the issue and wonder why it didn't manifest
constantly.

> unpredictable behavior could happen when jump instructions cross cache lines

Under which kind of circumstances? What does it mean anyway? The jump-
instruction itself with arguments crossing cache lines? Wouldn't that happen
quite often?

------
giomasce
I am not really following the details, but it seems that Intel is taking a
blunder after the other. Will we ever able to trust their CPUs again?

~~~
orbital-decay
We have been able to, and pretty quickly, after the F00F and FDIV bugs.

~~~
giomasce
Yeah, but those two were two isolated issues in a decade. Now we're having a
continuous stream of microarchitectural bugs that require more and more
complicated fixes in toolchain, kernel and microcode. I am an outsider, but
the impression is that the thing is exploding.

~~~
mschuster91
> I am an outsider, but the impression is that the thing is exploding.

To be honest it's the entire architecture that's exploding. There's a reason
why ARM has all but taken over the smartphone market (and it's not just power
efficiency), the only thing keeping x86 alive is the _massive_ demand for
backwards compatibility. Good riddance to x86/x64 once someone makes an ARM
core capable of current Ryzen performance and attaches a runtime binary
translator to it.

~~~
Crinus
> Good riddance to x86/x64 once someone makes an ARM core capable of current
> Ryzen performance and attaches a runtime binary translator to it.

What you expect to happen: developers will target fastARM for new code and
users will use the x86/x64 translator for existing/old code.

What will really happen: outside of open source circles (where they do not
need the translator anyway) developers will keep targeting x86/x64 for new
code since their existing users will keep using their existing x86/x64
machines and anyone using the new fastARM machines will still be compatible
thanks to the translator.

This of course assumes that fastARM will be fast enough and the x86/x64
translator to provide _better_ performance than a real x86/x64 machine.
Otherwise users wont have much of an incentive to upgrade as all of their
existing software will become slower. At least unless they are forced to (see
Apple).

------
executesorder66
What is the purpose of "censoring" the word shitstorm, if it is undoubtedly
obvious which word you meant to the point that it makes no difference either
way?

Or to phrase my question differently:

    
    
      Wh*t is t*e pur**se of "cens*ring" th* w*rd sh**storm, *f *t is u*doub*edly ob*ious wh*ch wo*d y*u me*nt to t*e poin*t th*t i* mak*s n* di**erence ei*her w*y?

~~~
bil7
seems to me like you are questioning the whole concept of censoring expletives

~~~
chongli
I think the GP’s point is this: if you’re against the use of an expletive,
then don’t use it. Putting it behind a fig leaf is embarrassing and silly.

------
stefan_
Instead of another fucking Twitter thread, just read the article from Phoronix
from yesterday:

[https://www.phoronix.com/scan.php?page=news_item&px=GNU-
Asse...](https://www.phoronix.com/scan.php?page=news_item&px=GNU-Assembler-
Patches-JCC)

~~~
rwmj
Here's a cryptic Intel whitepaper:
[https://www.intel.com/content/dam/support/us/en/documents/pr...](https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-
jump-conditional-code-erratum.pdf)

------
platz
I don't appreciate the aggressiveness and clear attempt to induce outrage with
the title. This is the outrage algorithm working.

* Edit - the previous title referenced a Twitter thread, not phoronix. The new title is fine.

~~~
omnimus
I do appreciate it. Its quite serious.

