Intel ditches Linux patch benchmark 'gag', offers 'innocuous' new license

Intel's license for its microcode security fixes no longer prevents developers from publishing benchmark results.
Written by Liam Tung, Contributing Writer

Intel has ditched a controversial licensing agreement that appeared aimed at legally preventing developers from publishing benchmark results that could reveal performance slowdowns caused by its recent security patches.

As ZDNet reported yesterday, the chip maker was criticized by open-source champion Bruce Perens for slipping new restrictions into the software agreement for maintainers of Linux distributions such as Debian and Ubuntu.

The changes in license terms came with microcode updates to mitigate Spectre and Foreshadow, or L1 Terminal Fault (L1TF), speculative attacks.

The agreement stated: "You will not, and will not allow any third party to ... publish or provide any software benchmark or comparison test results."

The phrase suggested that someone at Intel, perhaps lawyers or marketing officials, really didn't want anyone to publish benchmark results that contradicted its own tests for L1TF mitigations.

SEE: Sensor'd enterprise: IoT, ML, and big data (ZDNet special report) | Download the report as a PDF (TechRepublic)

When Intel disclosed the L1TF vulnerability, it said it had observed "no meaningful performance impact" after its mitigations had been applied.

There have been concerns since Intel released its first microcode mitigations for Spectre that they do cause significant slowdowns in performance.

But even if they do, Perens thought gagging developers would undermine trust in Intel's components.

"Silencing free speech by those who would merely publish benchmarks? Bad business. Customers can't trust your components when you do that," wrote Perens.

Following Perens' complaint that Intel was trying to "gag anyone who would collect information for reporting about those penalties", the company backtracked on the new agreement and replaced it with a "simplified" and less restrictive one that's been posted to Intel's open-source projects website.

"We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version here," wrote Imad Sousou, corporate vice president and GM of Intel Open Source Technology Center.

"As an active member of the open-source community, we continue to welcome all feedback and thank the community."

Perens noted that the new license was "pretty innocuous" for proprietary software and that it should resolve the problem for Linux distributions.

The new license does not include any restrictions on publishing benchmark results and focuses solely on redistribution, an issue that reportedly caused Debian developers to withhold Intel's patch.

Previous and related coverage

Intel 'gags' Linux distros from revealing performance hit from Spectre patches

You can test performance after using our patches, but don't publish the results, say Intel's new license terms.

Beyond Spectre: Foreshadow, a new Intel security problem

Researchers have broken Intel's Software Guard Extensions, System Management Mode, and x86-based virtual machines.

Linux performance before and after Meltdown and Spectre fixes

The patches, as expected, brought Linux's performance down, but their impact has not been as bad as feared.

Oracle's latest Linux fixes: New Spectre, Lazy FPU patches beef up defenses

Oracle has new fixes available for Spectre flaws affecting Linux systems on Intel and AMD chips.

First Intel, now AMD also faces multiple class-action suits over Spectre attacks

Customers accuse the chip maker of charging premium prices for a faulty product.

Got an old PC? Find out whether you will get Intel's latest Spectre patch TechRepublic

Intel has listed a range of CPUs released between 2007 and 2011 that will not receive a firmware update to help guard against Spectre-related exploits.

Class-action suits over Intel Spectre, Meltdown flaws surge CNET

Since the beginning of 2018, the number of cases has risen from three to 32.

Editorial standards