LLVM Developers Are Still Debating How To Handle The Intel JCC Erratum Mitigation

[phoronix]

Phoronix: LLVM Developers Are Still Debating How To Handle The Intel JCC Erratum Mitigation

Disclosed back in mid-November was the Intel JCC Erratum that required a CPU microcode update to mitigate and that in turn had broad performance hits. But via toolchain updates, some of that overhead can be offset. The GNU Assembler patches were quickly merged and new options exposed for helping to decrease that performance hit but on the LLVM side the developers are still working on their mitigation with some design decisions still to be made...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-JCC-Mitigation-LLVM-TODO

[eydee]

At this point all open source projects (including the Linux kernel) should just turn all these Intel-specific mitigations off, and officially announce all current Intel hardware to be officially unsupported and being a security risk. Let Intel handle the rest by actually fixing bugs and making decent hardware.

They had the chance of this right after Meltdown, yet they keep selling the same CPU still, for more than a decade. This can't be stopped in software, force them to behave.

[skeevy420]

At this point all open source projects (including the Linux kernel) should just turn all these Intel-specific mitigations off, and officially announce all current Intel hardware to be officially unsupported and being a security risk. Let Intel handle the rest by actually fixing bugs and making decent hardware.

They had the chance of this right after Meltdown, yet they keep selling the same CPU still, for more than a decade. This can't be stopped in software, force them to behave.

Only it can be stopped in software, to an extent, which is why I wish there was an OS that contained both mitigated and unmitigated repositories. Use the mitigated repos to run the core OS and anything security-critical and use the unmitigated repos to run performance-critical code...ideally in containers, but bare metal would work if one was willing to risk it. Yeah, there is still the possibility of kernel mitigations play, but clearly there'd be options for both mitigated and unmitigated kernels -- just reboot and use the unsafe kernel.

[c117152]

This can't be stopped in software, force them to behave.

It can be stopped by software but it means running everything in a very slow emulation.

Regardless, this endless cycle of finding vulnerabilities, patching them partially and eventually deprecating the hardware under 2-3 years is Intel's new business model now that Moore's law run dry. If you or your customers don't like it, feel free to start migrating to something portable so you'll be able to switch to ARM, RISC-V, OpenPOWER or whatever like many of the cloud providers are already doing. Plenty of fish in the sea.

[KaoDome]

Since Intel also worked with Microsoft to include mitigations in their compiler (available out of preview as of 16.5.0) I wonder if they're going at it in a similar manner or differently, and which would be most interesting regarding the end user and mixed usages.

This is a link to an article about it written by an Intel employee regarding MSVC: https://devblogs.microsoft.com/cppbl...ation-in-msvc/

TL;DR just in case, the microcode update results in a 0-3% performance drop (with outliers at 10%) and the compiler mitigations make them negligible, but do increase code size up to 3%.

[Jabberwocky]

At this point all open source projects (including the Linux kernel) should just turn all these Intel-specific mitigations off, and officially announce all current Intel hardware to be officially unsupported and being a security risk. Let Intel handle the rest by actually fixing bugs and making decent hardware.

They had the chance of this right after Meltdown, yet they keep selling the same CPU still, for more than a decade. This can't be stopped in software, force them to behave.

This is the problem if one company has so much influence and market share. Unless large companies make a class action law suit against Intel nothing will change.

Intel simply bribes vendors[1] and forces staff to buy back shares to prevent stock from dropping[2]. The average person or small company can't do anything. There are similarities to Illinois Brick Co. v. Illinois where cloud providers and basically all companies that use Intel CPUs to provide their service are going to increase prices or lower performance. The hierarchy looks like this: Intel -> Provider -> Consumer. The consumer can't sue Intel and just like the brick-case it is up to the provider or supplier to do that. Intel just need(ed) to bribe a single person and everyone using that provider has to pay for it.

Almost all companies break the law, but at this point in time no other CPU company has broken so many laws as Intel did the past ~5 years. Unfortunately due to extreme bias in public opinion there is no accountability or investigations being done (that I know of) despite the reports in the media. The same could happen if it was AMD, ARM, or IBM etc... was at the top. Monopolies are bad.

1. Intel reportedly reserved $ 3 billion in 2019 to competitively block AMD -- guru3d.com

2. Intel Stock Will Rise from Dividend Hike and Huge Stock Buybacks -- nasdaq.com

I would like to know how the cognitive dissonance is processed by Intel's managers and directors.

[CochainComplex]

Jabberwocky dont forget to mention the lawsuite Intel vs. EU [1] in my opinion the Market still suffers because of intels actions. There are almost no middleclass to premium AMD Notebooks 10 years later. Even with the upcomming Ryzen 4000 it seems that some Premium features are not included in the high tier models [2] e.g. No touchscreen for AMD Lenovo Yogas - sry article is german only. There is no physical explanation to justify the lack of this feature.

1. https://ec.europa.eu/competition/sectors/ICT/intel.html
2. https://www.pcgameshardware.de/Noteb...Intel-1344332/