Hot Topics

Home » Cybersecurity » SBN News » A bug found in Glibc limits modern SIMD instructions to only Intel, inhibiting performance of AMD and other CPUs

A bug found in Glibc limits modern SIMD instructions to only Intel, inhibiting performance of AMD and other CPUs

by Amrata Joshi on September 9, 2019

Yesterday, Mingye Wang reported a bug in the Glibc, GNU C Library. According to him, the dl_platform detection performs “cripple AMD” in the sysdeps in Glibc. The dl_platform check is used for dispatching SIMD (Single instruction, multiple data) libraries.

Explaining the bug in detail, Wang writes, that in 2017, Glibc got the capability to transparently load libraries for specific CPU families with some SIMD extensions combinations to benefit the x86 users. However, this implementation limits two “good” sets of modern SIMD instructions to only Intel processors that prevent competitor CPUs with equivalent capabilities to fully perform, something that should not work in any free software package.

He further added that this bug seemed like an implementation of Intel’s ‘cripple AMD’ bug which was reported in 2009, and hence the name. According to the author, Agner Fog, “software compiled with the Intel compiler or the Intel function libraries has inferior performance on AMD and VIA processors. The Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says “GenuineIntel” then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.”

A user commented on HackerNews, “Hm, is this really “crippling” AMD? Seems more like Intel submitted a performance patch that is only enabled for Intel processors, but could be extended to support AMD too. There’s a moral difference. It is wrong to intentionally degrade the performance of your competitors. It is not wrong to not do something that benefits others.”

Mingye Wang writes, “The crux of the problem lies in the `(cpu_features->kind == arch_kind_intel)` (LHS now renamed cpu_features->basic.kind) comparison that surrounds the entire x86_64 case. Although AMD has not yet made any processors with AVX512, their newer processors (Zen — Epyc, Ryzen) should at least satisfy the haswell test case.”

Sponsorships Available

According to Wang, glibc should remove the dl platform check and the processors should use their feature flags.

At 07:15:15 UTC, the page updated that the bug has been resolved and it is a duplicate of 2018, bug 23249, where Epyc and other current AMD CPUs couldn’t select the “haswell” platform subdirectory. This bug was reported by Allan Jensen, who wrote, “Recently a “haswell” sub-arch was introduced to be similar to the old i686 subarch for x86. It is documented as requiring BMI1, BMI2, LZCNT, MOVBE, POPCNT, AVX2 and FMA, but undocumented also checks the CPU is an Intel CPU before using the faster paths. I would suggest glibc fixes that before it becomes public knowledge.”

Florian Weimer, author at Red Hat, writes, “We really need feedback from AMD for this change, and it has been difficult for us to talk to engineers there. If you have contacts there, please encourage them to reach out to Red Hat Engineer Partner Management via their own channels (or contact me directly). I agree that this situation is unfortunate, and that AMD customers may not get the best possible performance as the result.”

Weimer further added, “The “haswell” platform subdirectory is somewhat ill-defined, see bug 24080. I don’t think current AMD CPUs implement the ERMS feature, which Intel assumes is part of the “haswell” definition. This bug has been marked as a duplicate of bug 23249.”

Few users are sceptical about this news and think that there might be a planned conspiracy behind this bug. A user commented on HackerNews, “Could this be a legitimate unintended consequence of the pull request or some new dirty pool tactic? Either way I agree with Mingye Wang’s assessment, this kind of thing cannot be allowed to get into the source tree. Hopefully AMD will increase their Linux activities with their new bigger market share and income.”

To know more about this news, check out the post by Sourceware Bugzilla.