Intel firmware now unredistributable by OS vendors

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158

by rwmj • 8 years ago

218 78 8 years ago

bugs.debian.org

Tomte2• 8 years ago

The title seems... ambitious.

I read in the bug that other vendors don't have a problem with the license, and I see nothing in detail why Debian might feel otherwise.

lordgilman• 8 years ago

The license file is new and the other distributions probably aren't as scrupulous as Debian is about licensing. The license itself seems pretty clear:

3. "You will not, and will not allow any third party to" (iii) "use or make the Software available for the use or benefit of third parties"

michaelmrose3• 8 years ago

Did you bother to read the license?

Tomte2• 8 years ago

Did you notice that there is some tension between „vendors cannot distribute“ and „pretty much everyone except us distributes, including vendors with real legal teams“?

An explanation that‘s more detailed than „read the license“ would be really nice. And the submission title remains pure clickbait.

mijoharas• 8 years ago

Does anyone have any information on what is wrong with the newly added intel microcode license from debian's perspective??

loeg3• 8 years ago

Yeah. The new license explicitly says the microcode cannot be redistributed.

walterbell6• 8 years ago

Also prohibits performance benchmark publication.

ssivark• 8 years ago

Please elaborate and provide a source. Searching for "benchmark" on that link did not give any results. (EDIT: Thanks for the downstream comments)

precurse• 8 years ago

In the license file provided in the .tgz microcode file, under 3. Licensing Restictions section:

All right, title and interest in and to the Software
and associated documentation are and will remain the exclusive property of
Intel and its licensors or suppliers. Unless expressly permitted under the
Agreement, You will not, and will not allow any third party to
(v) publish or provide
any Software benchmark or comparison test results.

michaelmrose3• 8 years ago

From the license included with the archive

"Unless expressly permitted under the Agreement, You will not, and will not allow any third party to

(i) use, copy, distribute, sell or offer to sell the Software or associated documentation;

(ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software;

(iii) use or make the Software available for the use or benefit of third parties; or

(iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or

(v) publish or provide any Software benchmark or comparison test results."

Full license

https://gist.github.com/fa7012d13ceb0b82521bfac10213ecc6

0x8BADF00D• 8 years ago

Oracle does the same thing. As a community, we need to punish companies that engage in these types of behaviors.

brightball• 8 years ago

I believe Microsoft does the same with SQL Server.

https://www.reddit.com/r/programming/comments/2mhpwp/postgre...

dbcurtis• 8 years ago

Here is the thing, at least in the case of database software, the people that are competent to set up a benchmark correctly are fairly rare. The people that have the budget for the hardware are even more rare. The last thing the world needs is for the web to be polluted by so many incompetent "benchmarks" performed by the clueless that you can't find the authoritative information that you need to do your job.

Take a wild guess about how much memory and how many disk spindles it takes to get a TPC benchmark on a modern server to be CPU limited. Take a guess as to how many weeks of engineering time it takes to perform and validate the benchmark after getting a pile of hardware delivered to your lab. The average blogger writing 3 posts a week ain't gonna do it.

kevarh• 8 years ago

I worked for a competitor and we had similar verbiage. It's there to prevent "XXX is a 10 million times faster than YYY." We actually gave everyone permission if they both asked and allowed us to review their methodology to make sure they weren't doing anything horrifically wrong (benchmarking is hard).

vasili1112• 8 years ago

Benchmark is a software just as other software. Does it mean that I cannot run software and measure and publish results of working of software?

kjeetgill2• 8 years ago

Yes. You agree to that when you license use of that software.

nightcracker• 8 years ago

Is that even enforceable?

miga3• 8 years ago

This change should tip off everybody about recent releases by competitors...

api• 8 years ago

Has Intel been taken over by agents on the payroll of AMD?

ramshanker• 8 years ago

And does AMD allow it? If yes, than we have one more reason to......

idoubtit• 8 years ago

Debian's package amd64-microcode contains the non-free AMD CPU firmware with its license. Extract from /usr/share/doc/amd64-microcode/copyright:

If You redistribute this Software, You must reproduce the above copyright notice and this license with the Software.
You may not reverse engineer, decompile, or disassemble this Software or any portion thereof.

Like Intel, they forbid, as much as possible, any reverse engineering. But unlike Intel, they allow redistribution and benchmarking.

loeg3• 8 years ago

The family 17h microcode blobs only apply to Epyc (server segment) models, not consumer Ryzen, which is a bit unfortunate.

loeg3• 8 years ago

AMD doesn't distribute microcode updates for consumer processors, only Epyc, so it's kind of a mixed bag. They expect consumer processors to get microcode updates via BIOS vendors.

walterbell6• 8 years ago

How about Ryzen Pro which is targeted at enterprise?

jmhain• 8 years ago

POWER9 is looking more and more attractive by the day.

vasili1112• 8 years ago

What about Spectre and Meltdown? As far as I remember POWER9 was affected at least with one of those.

rst• 8 years ago

Pretty much all high-performance processor designs are affected by some Spectre variant or other, as speculative execution is pretty near universal. IBM is making firmware patches for POWER9 available, with at least some level of mitigation (though not for some older POWER models, which they've desupported).

(Besides, it's not as if Intel is uniquely good at dealing with these sorts of vulnerabilities. The reverse, if anything -- meltdown was a particularly nasty variant which seems to have primarily affected Intel processors, and not even other manufacturers' x86 variants.)

See https://www.ibm.com/blogs/psirt/potential-impact-processors-...

notriddle• 8 years ago

Meltdown is completely Intel-specific, and Spectre is ubiquitous.

hlandau2• 8 years ago

Only preproduction firmware was affected. Mitigations were implemented in firmware/Linux prior to shipping, and are actually superior to "mitigated" x86.

Before POWER9 shipped (but after the last silicon respin), the processor was vulnerable to both Meltdown and Spectre. IBM determined that this could be mitigated via firmware and kernel changes without another respin.

AIUI, it was determined that for intra-process Spectre mitigation in userspace, recompiling everything to use retpolines and modifying firmware to knacker the branch predictor, etc. in a way that mitigated Spectre had equivalent performance losses. So rather than make people recompile everything with retpolines, the firmware modification option was chosen. This yields a highly conservative Spectre mitigation erring on the side of security rather than performance.

By comparison, Intel/AMD have chosen not to mitigate intraprocess Spectre by default; it has been made the responsibility of application developers to mitigate intraprocess Spectre via retpolines if desired... it essentially shifts the spotlight for performance losses from the vendors to the developers, giving the vendors an escape from having their patches show huge performance losses. But of course, most people aren't shipping software with retpolines, so in practice, the x86 vendors have basically chosen not to mitigate intraprocess Spectre.

POWER9's firmware-based intraprocess mitigations can be disabled at boot if desired (leaving kernel and interprocess Spectre mitigations and Meltdown mitigations in place), providing a level of protection and performance comparable to "mitigated" x86.

jimrandomh• 8 years ago

Henrique de Moraes Holschuh wrote:

Unfortunately, that release is undistributable (refer to the new "license" file that was added by Intel to the microcode data file pack version 20180807).
"Intel has been made aware of the issue and pestered by just about everyone, and should get it straightened up soon."

Sounds like someone in the legal department screwed up, and are being slow to respond to the issue (it's been ~2 weeks). This is unfortunate, but, well, legal departments aren't used to being on the critical path to time-sensitive distribution of security vulnerability mitigations, and the time sensitivity may not have been adequately explained to them.

ccnafr2• 8 years ago

This is not true. Here's an Intel spokesperson commenting on the issue: https://twitter.com/imadsousou/status/1030260566483496960

walterbell6• 8 years ago

While looking for AMD desktops, found Dell Optiplex 5055 barebone enterprise desktop with Ryzen (1) Pro 1700X CPU 8 core / 16 threads for about $700 with Ubuntu Linux. Requires a phone call to order for some reason?

https://www.dell.com/en-us/work/shop/desktop-and-all-in-one-...

simcop2387• 8 years ago

That's likely going to be the case with any Optiplex system from Dell. The Optiplex line is intended for large organizations (commerical, government, educational, etc.) that are going to order many systems so they want you to go through their sales platform rather than sell directly.

walterbell6• 8 years ago

Intel Optiplex can be configured and ordered online:

https://www.dell.com/en-us/work/shop/desktop-and-all-in-one-...

miga3• 8 years ago

I worked in several large organizations before, and it was always: give me WWW order printout, and send to organization wide email.

One might have thought they will streamline the process after so many years. After all ordering is as much choosing, as it is making it to fit the budget.

CaliforniaKarl2• 8 years ago

I have been subbed to this bug since the beginning, and when I saw it come up, I was hoping that it _wouldn't_ hit the HN front page, because right now the bug does not have very much information in it. I'm not saying that details and discussion don't exist, just that they're not in the bug.

Because there's not much info in the bug, there isn't much to have a discussion about, unless someone is able to provide information that isn't already in the bug. And, given the audience of HN, saying "License terms are getting in the way" isn't really detailed enough.

I encourage you to go to the microcode download at https://downloadmirror.intel.com/28039/eng/microcode-2018080... and actually read the license file. You'll laugh or groan at the first part of the first paragraph:

DO NOT DOWNLOAD, …

What I think is interesting about the license is, it's actually two licenses. Or, a license and a license framework. You'll see what I mean in a moment.

Reading through the license, it seems to me (although I am not a lawyer) that Intel tried to carve out distribution permission. Specifically in Section 2:

2. LIMITED LICENSE. … Intel grants to You a … license …, under Intel's copyrights (subject to any third party licensing requirements), to…

(So much preamble…)

… (i) reproduce the Software only for Your own internal evaluation, testing, validation, and development of Intel-based products and any associated maintenance thereof; …

Sounds good to me. It seems like this (particularly the "associated maintenance" part) covers the necessary testing/packaging work.

… (ii) reproduce, display, and publicly perform an object code representation of the Software, only when integrated with and executed by an Intel-based product, subject to any third party licensing requirements; …

Reading this, I started to think "Wait, does this mean that the microcode could only be packaged up, distributed to, and mirrored by systems running Intel chips? But no, that's not true, because of the next point.

… (iii) distribute an object code representation of the Software, provided by Intel, through multiple levels of distribution, …

OK, the files in the tarball are either text, or object code, so that's good.

… solely as embedded in or for execution on an Intel-based product and subject to these license terms, …

Hmmmmm, well, the "or for execution on an Intel-based product" would seem to give us permission to distribute, regardless of the hardware used to do the distribution, since the microcode will only be executing on Intel CPUs.

"Subject to these license terms" could be a problem, but the `intel-microcode` package is already in the non-free part of the Debian repo.

… and if to an end user, pursuant to a license agreement with terms and conditions at least as restrictive as those contained in the Intel End User Software License Agreement in Appendix A hereto.

Hmmmmmmmmmmmm. Does this mean that the `intel-microcode` installer would have to pop-up a license acceptance during package installation?

A quick note here: Section 3 ("LICENSE RESTRICTIONS") does have a distribution restriction, but that restriction is loosened by the caveat "Unless expressly permitted under the Agreement…".

There is one more restriction, which @walterbell mentioned:

… (v) publish or provide any Software benchmark or comparison test results;

This is interesting, though. This restriction does not appear in Appendix A, the terms that end users should agree to. So, does that mean that this restriction only applies to the Debian project, as they are the ones who downloaded the software from Intel's site for repackaging? Or, does the phrase "and subject to these license terms" mean this license applies to the end user, who is installing the Debian package?

So, that is why this license is so interesting to me! There seems to be an attempt to allow distribution, but there are so many niggles that I imagine the Debian Project's legal representation will need a fair amount of time to clear the license, or to build a list of issues to be worked through.

My hope is that this is already happening in the background!

walterbell6• 8 years ago

Thanks for the detailed breakdown.

cmurf• 8 years ago

My confusion is who is a 3rd party under this agreement? Are users not 3rd parties? How can a distribution be responsible for and have any power over users, if the first two parties are Intel + distribution, and the 3rd party is the user?

I do find hilarious the "don't download this until you've downloaded and read and agreed to the agreement!" (paraphrased) clause at the top.

miga3• 8 years ago

Poor understanding of legales seems to affect even those drafting it.

floatingatoll2• 8 years ago

As a reminder to everyone discovering here that Debian is very careful about licensing, please honor the request they made in the linked discussion to give Intel time to address their concerns without swarm-attacking Intel with direct contact attempts over this. Debian explicitly is asking the crowd not to source here.

ccnafr2• 8 years ago

Intel has addressed the issue. It was a misunderstanding on Debian's part: https://news.ycombinator.com/item?id=17801931

e12e• 8 years ago

That thread seems to highlight a number of issues remaining.

There even seems to be restrictions on commercial use, so making it illegal to make and sell Debian install media with firmware blobs?

benchaney• 8 years ago

The contents of legal documents is authoritative in this situation. Not tweets by spokespeople.

floatingatoll2• 8 years ago

Your second sentence is inappropriate — as an outsider to Debian and its legal evaluations, you have no standing to make a statement on behalf of Debian based solely on Intel’s public comment on Twitter.

If and when Debian Legal concurs with the interpretation Intel asserts, then it is fine to say it is “addressed”. Until then, it is not okay for you to cite a statement from Intel as relevant in any way whatsoever to Debian and their position. That’s for Debian to judge and provide.

alxlaz• 8 years ago

Have you read the rest of the document? That clause does allow redistribution, but according to Appendix A, redistribution is allowed (in unmodified, binary form) only for personal use.

JdeBP• 8 years ago

Actually, that's Imad Sousou of Intel making 1 Twitter comment, followed up by several people making the same points as made elsewhere in this very discussion (q.v.), all of which have gone unanswered by Imad Sousou so far.

patmcguire• 8 years ago

The unmentioned context here is that Debian is stricter in how they handle binary firmware than most distributions. I believe they refuse to distribute any not under a free software license, most others will ship binary blob firmware.

CaliforniaKarl2• 8 years ago

That's not completely true. Debian does allow what they call "non-free" software, with limitations (see [1]). In particular, searching for Debian packages with "firmware" in the name[2] will show alot of non-free. This does cause consternation in at least some free-software groups[3].

[1] https://www.debian.org/doc/debian-policy/ch-archive.html#the...

[2] https://packages.debian.org/search?suite=all&arch=any&search...

[3] https://www.gnu.org/distros/common-distros.en.html

blihp• 8 years ago

Yes, Debian is stricter in how they handle everything, including binary blobs. No, they do not refuse to distribute 'any not under a free software license' (there are contrib and non-free repos which allow for this) Where other distros often say 'whatever, we'll include it', Debian acts as a very useful canary when things like this occur.

I don't agree that it's unmentioned context: Debian is currently distributing prior releases of the firmware, Intel released new firmware and changed something in the terms, and the Debian packagers have a problem with the new terms. If anything the unmentioned context is that all too often distros/people just blindly accept changes in license terms where the Debian packagers actually read and evaluate license terms and don't just rubber stamp them. It's useful to everyone that someone is paying attention, even if one disagrees with the Debian position on a given issue.

emilfihlman• 8 years ago

It's strange that Intel hasn't fixed this yet.

faragon• 8 years ago

Intel CPUs without firmware updates because of redistribution limitations? How can Intel make that mistake? Intel, please, reconsider that, for your own good.

newnewpdro• 8 years ago

In what world does it actually make sense for Intel to use such a license with microcode firmware applicable to improving the security of desktop computers?

Is this just an attempt to limit distribution during a teething period, in case there are bugs in the new microcode?

sowbug• 8 years ago

I wish that security updates consisted only of "Hi there, if you're [GUID] running [VERSION], then you should be apply update [SHA-256 SUM], which hopefully will get you to [LATER_VERSION]. [Cryptographically] Signed, [SOMEONE YOU TRUST]." That assertion could easily live in a kilobyte of data. Then if you cared about that message, you could go anywhere -- vendor site, Bittorrent, IPFS, your classmate's computer via your local network, even the attacker trying to own you -- to get the multi-megabyte/gigabyte update. If the hash matches, apply it. Otherwise, ignore it.

The (slightly contrived) relevance to this post is whether Intel should get to decide whether its updates are redistributable. They should definitely get to declare which updates are authentic. But it seems reasonable that the remaining decisions should be up to the owner of the hardware, who has to deal with the consequences of its software/firmware not being up to date.

kwantam• 8 years ago

As a stopgap measure until the licensing issues are straightened out, you can build an updated version of the package yourself rather easily. What's below should more or less work to generate an updated intel-microcode package starting from Debian's intel-microcode-3.20180703.2 source:

    mkdir microcode_src
    cd microcode_src
    sudo apt-get build-dep intel-microcode
    apt-get source intel-microcode
    # download microcode-20180807.tgz from Intel
    mkdir microcode_new
    cd microcode_new
    tar xf ../microcode-20180807.tgz
    cp intel-ucode/* ../intel-microcode-3.20180703.2/intel-ucode
    cd ../intel-microcode-3.20180703.2/debian
    cat >> changelog <<EOF
    intel-microcode (3.20180807.1manual) unstable; urgency=medium

      * manually update to latest Intel microcode package

     -- me <my@email.address> Mon, 20 Aug 2018 00:00:00 -0000
    EOF
    cd ../
    debuild -b -uc -us
    cd ../
    sudo dpkg -i intel-microcode-3.20180807.1manual_amd64.deb

YMMV, use the above at your own risk, understand what you're doing before you do it, etc.

dooglius• 8 years ago

Is there a distro out there that will just ignore legal issues and publish any packages they can get their hands on, like a Sci-Hub for distros?

nine_k• 8 years ago

They would exist until the first C&D letter.

I would rather have Intel redistribute their firmware in easy-to-install packages, trusted and verifiable, if they, for some reason, cannot trust distros package it.

Doing a firmware update from a random untrusted source is an invitation to have a hard-to-detect exploit added to your system.

dmitrygr• 8 years ago

If your random untrusted source has a way to properly digitally sign an intel microcode update, I know a lot of people who would like to speak to him

xyproto• 8 years ago

Full out Pirate Linux currently does not exist, as far as I know. I guess just adding package repositories with dubious licenses would do the same job?

hlandau2• 8 years ago

What's truly hilarious about this is that this EULA can't possibly serve any purpose... since Intel microcode blobs are RSA encrypted and signed. Only Intel CPUs can decrypt and consume them, and they can't be modified. It's not like it can be reverse engineered. I have to wonder what exactly Intel is worried people will do with these blobs.

trebligdivad• 8 years ago

Unless that is you suddenly found a way to read the decrypted microcode - perhaps out of the cache after a decode??

craftyguy• 8 years ago

What makes you think the microcode patch is decrypted to cache at all? (Hint: it's not)

Intel firmware now unredistributable by OS vendors

Related Stories