Language Selection

English French German Italian Portuguese Spanish

Intel cripples programs on AMD chips

Filed under
Hardware
Legal

Intel's compilers recognise when they're running on an AMD processor, and generates code that either degrades performance or causes it to crash. That's one of the many accusations in AMD's lengthy document of complaints against Intel in its recent lawsuit against the chip giant.

The paragraph in question, number 123, reads:

"Intel has designed its compiler purposely to degrade performance when a program is run on an AMD platform. To achieve this, Intel designed the compiler to compile code along several alternate code paths. Some paths are executed when the program runs on an Intel platform and others are executed when the program is operated on a computer with an AMD microprocessor. (The choice of code path is determined when the program is started, using a feature known as "CPUID" which identifies the computer's microprocessor.) By design, the code paths were not created equally. If the program detects a "Genuine Intel" microprocessor, it executes a fully optimized code path and operates with the maximum efficiency. However, if the program detects an "Authentic AMD" microprocessor, it executes a different code path that will degrade the program's performance or cause it to crash."

Among the other issues raised by AMD were:

- That Intel used illegal subsidies to win sales and, in some cases, threatened companies with "severe consequences" for using or selling AMD products.

- That Intel has allegedly abused its dominate market position by forcing major customers into exclusive deals in return for outright cash payments, discriminatory pricing or marketing subsidies.

Following AMD's accusations, representatives of the European Commission and of national competition authorities carried out on-site inspections of several Intel offices and of the offices of an undisclosed number of PC manufacturers, as part of "an ongoing competition investigation", according to an EC spokeswoman.

By Manek Dubash
Techworld

More in Tux Machines

Leftovers: Ubuntu

Kernel Space/Linux

  • Why Is Microsoft Showing So Much Interest In Linux? [Ed: Someone needs to explain to Mathew Lodge what EEE is and how it works. Is the Linux Foundation (including Rorvalds as well) still permitted to criticise Microsoft or is it frowned upon internally?]
  • Linux on the Mac — state of the union
    The MacBook Pro introduction in October caused unusually negative reactions among professional users due to the realization that Apple no longer caters equally to casual and professional customers as it had in the past [YouTube video]. Instead, the company appears to be following an iOS-focused, margin-driven strategy that essentially relegates professionals to a fringe group. This has well-known developers such as Salvatore Sanfilippo (of the Redis project) consider a move back to Linux. Perhaps that's a good moment to look at the current state of Mac hardware support in the kernel. While Macs are x86 systems, they possess various custom chips and undocumented quirks that the community needs to painstakingly reverse-engineer.
  • How well does the Linux kernel support Mac hardware?
    There is an interesting subset of Linux users that prefer to run it on a Mac. Yes, a Mac. That might seem odd given how Apple is known for its closed ecosystems and high cost hardware, but the Linux on Mac folks really do exist out there. But how well does the Linux kernel support Mac hardware? LWN.net has a “state of the union” article for Linux on the Mac that could be quite helpful if you are thinking about installing Linux on your Mac.
  • New Kernel Vulnerability Allows Local Root For Unprivileged Processes
    There is yet another new Linux kernel vulnerability being disclosed today that allows for unprivileged processes to gain kernel code execution abilities. This new vulnerability is CVE-2016-8655 but it doesn't seem to be getting too much attention yet. CVE-2016-8655 comes down to a race condition within the af_packet.c code for gaining local root access. The researcher that found it was able to write an exploit to gain root shell on an Ubuntu 16.04 LTS system and defeats SMEP/SMAP protection too.
  • Avoiding CVE-2016-8655 with systemd
    Just a quick note: on recent versions of systemd it is relatively easy to block the vulnerability described in CVE-2016-8655 for individual services. Since systemd release v211 there's an option RestrictAddressFamilies= for service unit files which takes away the right to create sockets of specific address families for processes of the service. In your unit file, add RestrictAddressFamilies=~AF_PACKET to the [Service] section to make AF_PACKET unavailable to it (i.e. a blacklist), which is sufficient to close the attack path. Safer of course is a whitelist of address families whch you can define by dropping the ~ character from the assignment. Here's a trivial example:
  • The Best Features Of The Linux 4.9 Kernel

today's howtos

Red Hat Financial News