Updated At least one Linux distribution is withholding security patches that mitigate the latest round of Intel CPU design flaws – due to a problematic license clash.
Specifically, the patch is Chipzilla's processor microcode update emitted this month to stop malware stealing sensitive data from memory by exploiting the L1 Terminal Fault vulnerability in Intel's silicon. The biz had released microcode in July that corrected the underlying problem mostly for server-grade CPUs; this latest fix now covers desktop processors.
Ideally, Intel's CPU microcode is updated by the motherboard firmware during boot. However, manufacturers may be slow to emit patches, so operating system kernels can also push updates to the chipset during startup. Since microcode updated in this way is discarded every time the power is cycled, it is up to the firmware and OS to reapply the update as early as it can during the boot process.
Some people prefer to install microcode updates via their OS as it's easy to do and avoids fiddling with firmware settings. Also, the patches are picked up during the usual monthly routine of fetching and stalling operating system software updates. And some motherboard makers are slow to release fixes, leaving it to OS developers to roll out patches.
While Intel hoses down the industry with fixes for its design blunders, it is up to the maintainers of the various Linux distributions to take a good look at what Chipzilla has given the world, and then ship the code to users.
It is with the latest set of CPU microcode updates that things have come unstuck somewhat, for Debian at least.
Three more data-leaking security holes found in Intel chips as designers swap security for speedREAD MORE
Debian developer and kernel driver engineer Henrique Holschuh argued in a posting in Debian’s bug tracker that yes, packages containing Intel's fixes are ready to go, but, no, they aren't about to be sent out to the world due to a new end-user license file added by Intel to the archive.
The license prohibits, among other things, users from using any portion of the software without agreeing to be legally bound by the terms of the license. Debian, which is famously proud of its open approach to licensing, has taken a look at those terms, and concluded: nope, not having that. Not until the wording is mitigated.
And Intel has plenty of experience in mitigating things.
Other distributions have found ways to work around the problem. Gentoo, for example, will likely restrict mirroring of the software and get users to accept Intel’s license before proceeding. SUSE, Arch, and Red Hat are said to be OK with the fine print.
Why Intel felt the need to update the license is unclear. In a statement to The Register, Imad Sousou, corporate vice president and general manager of the Intel Open Source Technology Center, said it's "not true" that Debian can't distribute the microcode package.
"The license section 2, subsection (iii) grants rights needed for redistribution," he said. "Specifically, '…distribute an object code representation of the Software, provided by Intel, through multiple levels of distribution.'”
El Reg has dropped Debian a line to find out if Intel's response deals with its licensing concerns. Holschuh was not entirely clear why the license is a problem. In any case, the packages are being held up for Debian users, and so they'll have to go down the firmware route to install the latest Intel CPU microcode.
Thanks to an annoyed Linux-using Reg reader for bringing the shenanigans to our attention. ®
Updated to add
Open-source pioneer Bruce Perens has weighed in with his take on the matter. "The license problem is a more global concern, in my opinion, as it may prevent any use of the CPU for benchmarking that is provided or published," he told The Register.
This is because the terms of the microcode license state you must not "publish or provide any software benchmark or comparison test results." Which is awkward.
Intel has rewritten its microcode license to make it much friendlier for benchmarkers and free-software distributions.