
Intel firmware now unredistributable by OS vendors - rwmj
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158
======
floatingatoll
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.

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

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

~~~
oasisbob
Intel's spokesman isn't saying "ignore the license, distribution is fine, I
promise" \- he's pointing out the clause in the license which is intended to
allow redistribution.

~~~
manicdee
A single clause doesn't make a legal agreement. It only allows redistribution
given other conditions placed on it directly and indirectly by the rest of the
license and other documents that relate.

It's entirely possible that redistribution is allowed in very limited
circumstances that do not include Debian's distribution model. The Intel
spokesman's lack of understanding of Debian's context doesn't mean Debian's
mistaken.

------
jimrandomh
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.

------
kwantam
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.

------
walterbell
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-...](https://www.dell.com/en-us/work/shop/desktop-and-all-in-one-
pcs/optiplex-5055-tower-and-small-form-factor/spd/optiplex-5055-desktop)

~~~
simcop2387
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.

~~~
walterbell
Intel Optiplex can be configured and ordered online:

[https://www.dell.com/en-us/work/shop/desktop-and-all-in-
one-...](https://www.dell.com/en-us/work/shop/desktop-and-all-in-one-
pcs/sf/optiplex-desktops?appliedRefinements=1359)

~~~
kevin_thibedeau
The purpose of the AMD models is to keep Intel on their toes and get better
bulk discounts out of them. Dell doesn't actually want to sell AMD product and
complicate their production process.

~~~
gerdesj
RLY? Here's an example of a AMD powered server: [https://www.dell.com/en-
uk/work/shop/povw/poweredge-r7425](https://www.dell.com/en-
uk/work/shop/povw/poweredge-r7425) there are quite a few more examples.

There's this as well: [https://www.dell.com/learn/us/en/19/campaigns/enabling-
today...](https://www.dell.com/learn/us/en/19/campaigns/enabling-today-
inspiring-tomorrow?c=us&l=en&s=dhs) (I found that with "dell amd")

------
walterbell
Also prohibits performance benchmark publication.

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

~~~
dbcurtis
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.

~~~
zimbatm
There is always a well sounding rationale attached to censorship.

It also prevents meaningful benchmarks to be published.

~~~
kjeetgill
I'm on the fence about the benchmarks but I think this is a generic broad
brush to sweep away the parent's comment given the real concerns they've
presented and you've chose to not address.

Do you really thing any agreement that involves silence is censorship NDAs
included?

Sure, it's easy to simply say: sucks to be you! Especially to "community
bullies" like Oracle. Even just between semi-competing open source projects
benchmarks can be so bad they border on libelous.

~~~
harry8
Oracle has just enough budget to hire someone knowledgeable to engage in the
discussion, pointing out the issues and their fixes, possibly even linking the
benchmarks that were (in their view) properly performed. One good engineer.
Compare with the legal fees required to draft such an appalling, scared and
knowingly guilty clause as "you can't talk about how our product performs
despite having paid for it." This really needs to be treated with total
derision, and utter contempt. It's an approach that has earned that response
for it's sheer laziness before even beginning to measure it against any
ethical standards.

Oracle are just an awful company in every dimension. This, is just like most
everything else they do in that it reinforces the reputation they earned for
themselves.

------
hlandau
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
Unless that is you suddenly found a way to read the decrypted microcode -
perhaps out of the cache after a decode??

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

------
jmhain
POWER9 is looking more and more attractive by the day.

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

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

~~~
Symmetry
No, it also affects POWER 9 and the ARM A75.

------
CaliforniaKarl
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...](https://downloadmirror.intel.com/28039/eng/microcode-20180807.tgz)
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!

~~~
cmurf
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.

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

------
newnewpdro
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
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.

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

~~~
idoubtit
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.

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

~~~
cosmojg
Isn't consumer microcode distributed as part of the linux-firmware package?

------
patmcguire
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.

~~~
CaliforniaKarl
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...](https://www.debian.org/doc/debian-policy/ch-
archive.html#the-non-free-archive-area)

[2]:
[https://packages.debian.org/search?suite=all&arch=any&search...](https://packages.debian.org/search?suite=all&arch=any&searchon=names&keywords=firmware)

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

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

------
dooglius
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
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
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

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

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

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

------
Tomte
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.

~~~
michaelmrose
Did you bother to read the license?

~~~
Tomte
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.

~~~
michaelmrose
I both posted a link the entire license and the terms that are relevant.

------
ccnafr
This is not true. Here's an Intel spokesperson commenting on the issue:
[https://twitter.com/imadsousou/status/1030260566483496960](https://twitter.com/imadsousou/status/1030260566483496960)

