GNU Assembler Patches Sent Out For Optimizing The Intel Jump Conditional Code Erratum

[phoronix]

Phoronix: GNU Assembler Patches Sent Out For Optimizing The Intel Jump Conditional Code Erratum

Now that Intel lifted its embargo on the "Jump Conditional Code" erratum affecting Skylake through Cascade Lake processors, while Intel's own Clear Linux was first to carry these patches they have now been sent out on the Binutils mailing list for trying to get the JCC optimization patches into the upstream Binutils/GAS code-base...

http://www.phoronix.com/scan.php?page=news_item&px=GNU-Assembler-Patches-JCC

[rene]

the level of Intel bugs and incompetence is hilarious, /me googling availability of AMD Ryzen 3950X ;-) https://www.youtube.com/watch?v=1mkf0O-f4hU

[tchiwam]

Is this fix going to affect all code generated from binutils or only with a specific target ?

Would be sad to make everyone slower just because...

[log0]

Is this fix going to affect all code generated from binutils or only with a specific target ?

Would be sad to make everyone slower just because...

The fix seems to be inserting nops(prefixes) to align branches/jumps.

I don't think it will have any performance impact in general.

[fintux]

The fix seems to be inserting nops(prefixes) to align branches/jumps.

I don't think it will have any performance impact in general.

Well it depends how big portion of the code is no-ops. If a significant portion is, then it will unnecessarily occupy room in the cache, slowing down execution.

[Isedonde]

I'd still like to see some AMD benchmarks (maybe for older CPU architectures that are still in use today, too?) just to make sure these patches have negligible impact on most use cases.

[L_A_G]

Back in 2014 I watched a presentation called "Untrusting the CPU" that had just been given at that year's Chaos Computer Communications-conference and thought to myself that the presenter was just being alarmist about how we should start designing software to assume we can't trust the CPU not to leak critical things like encryption keys. All this would do is add unnecessary complexity and lower performance.

Well... Turns out he was very much right and I was very much wrong as the issues he brought up were just the tip of the iceberg compared to what was actually out there.

On top of that further hardware-level exploits like this really do put additional onus on companies like Intel, AMD and ARM to put a lot more effort into thinking about security already on the design level. Intel is obviously the worst offender when it comes to security-related corner cutting by quite a bit, but neither AMD nor ARM are faultless and also need to do better in this regard.

[tchiwam]

Back in 2014 I watched a presentation called "Untrusting the CPU" that had just been given at that year's Chaos Computer Communications-conference and thought to myself that the presenter was just being alarmist about how we should start designing software to assume we can't trust the CPU not to leak critical things like encryption keys. All this would do is add unnecessary complexity and lower performance.

How does one convey the message to the intended recipient while not trusting interface BUS, RAM, CACHE and CPU... I have a few ideas Anyone interested ?

[L_A_G]

How does one convey the message to the intended recipient while not trusting interface BUS, RAM, CACHE and CPU... I have a few ideas Anyone interested ?

I mean you can go watch the talk as a video of it is available on their website...

[coder]

The fix seems to be inserting nops(prefixes) to align branches/jumps.

I don't think it will have any performance impact in general.

Branches, right? Not branch targets, then? If so, how can you say extra nops won't affect performance?

I read elsewhere that Intel estimates up to 4% performance drop.