Intel firmware now unredistributable by OS vendors(bugs.debian.org)
bugs.debian.org
Intel firmware now unredistributable by OS vendors
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158
79 comments
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.
Intel has addressed the issue. It was a misunderstanding on Debian's part: https://news.ycombinator.com/item?id=17801931
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.
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.
The contents of legal documents is authoritative in this situation. Not tweets by spokespeople.
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.
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.
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.
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?
There even seems to be restrictions on commercial use, so making it illegal to make and sell Debian install media with firmware blobs?
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.
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.
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.
> 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.
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 <[email protected]> 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
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-...
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.
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.
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.
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-...
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.
RLY? Here's an example of a AMD powered server: 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... (I found that with "dell amd")
There's this as well: https://www.dell.com/learn/us/en/19/campaigns/enabling-today... (I found that with "dell amd")
Also prohibits performance benchmark publication.
This change should tip off everybody about recent releases by competitors...
Please elaborate and provide a source. Searching for "benchmark" on that link did not give any results. (EDIT: Thanks for the downstream comments)
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
"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
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.
> 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.
[deleted]
Oracle does the same thing. As a community, we need to punish companies that engage in these types of behaviors.
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.
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.
Except they started the practice in response to an academic researcher publishing, while simultaneously trying to get the researcher fired.
https://danluu.com/anon-benchmark/
https://danluu.com/anon-benchmark/
But this doesn't mean having the vendor control publication is going to get you any benchmarks that are better. We can predict pretty easily that the benchmarks they publish will be skewed in their favour.
On the other hand, we can't predict what solutions society comes up with for dealing with incompetent benchmarks. For example, you say professional bloggers would do lousy jobs, but this is exaclty the kind of things that neckbeard hobbyist bloggers would take upon themselves and do excellent jobs at.
That or other solutions could emerge, but the whole point of censorship is to prevent that.
On the other hand, we can't predict what solutions society comes up with for dealing with incompetent benchmarks. For example, you say professional bloggers would do lousy jobs, but this is exaclty the kind of things that neckbeard hobbyist bloggers would take upon themselves and do excellent jobs at.
That or other solutions could emerge, but the whole point of censorship is to prevent that.
> 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.
If these apparently incompetent people running the benchmarks are also the incompetent people creating the schema's and queries out in the wild then the benchmarks are still worthwhile.
I want to know what performance I can expect, not what I can expect when the environment is highly tuned by rare experts that will never touch any of the systems I have to deal with.
If these apparently incompetent people running the benchmarks are also the incompetent people creating the schema's and queries out in the wild then the benchmarks are still worthwhile.
I want to know what performance I can expect, not what I can expect when the environment is highly tuned by rare experts that will never touch any of the systems I have to deal with.
There is always a well sounding rationale attached to censorship.
It also prevents meaningful benchmarks to be published.
It also prevents meaningful benchmarks to be published.
And it's a self-fulfilling prophecy if we don't allow inexperienced benchmarkers to learn how to run meaningful tests.
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.
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.
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.
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.
Well, most times I'd like to know how a badly configured X compares with badly configured Y, on <random hardware> - because that's usually how things are run.
I believe Microsoft does the same with SQL Server.
https://www.reddit.com/r/programming/comments/2mhpwp/postgre...
https://www.reddit.com/r/programming/comments/2mhpwp/postgre...
Ta for the link. That is quite a discussion. The first thread is priceless (it turns out that grauenwolf isn't quite as authoritative as they first appear - fancy!)
Never underestimate how keen people can become about something they have paid £1,000s for. How on earth could a DBMS like MySQL/MariaDB or PostgreSQL possibly compare to the mighty Oracle money generator or MSSQL ... errrr ... money generator.
Just in case you wonder whether open source DBMSs should be taken seriously, try reading this: https://postgresweekly.com/ and this: https://mariadb.com/resources/blog
Never underestimate how keen people can become about something they have paid £1,000s for. How on earth could a DBMS like MySQL/MariaDB or PostgreSQL possibly compare to the mighty Oracle money generator or MSSQL ... errrr ... money generator.
Just in case you wonder whether open source DBMSs should be taken seriously, try reading this: https://postgresweekly.com/ and this: https://mariadb.com/resources/blog
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).
Is that even enforceable?
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.
Unless that is you suddenly found a way to read the decrypted microcode - perhaps out of the cache after a decode??
What makes you think the microcode patch is decrypted to cache at all? (Hint: it's not)
POWER9 is looking more and more attractive by the day.
What about Spectre and Meltdown? As far as I remember POWER9 was affected at least with one of those.
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.
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.
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-...
(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-...
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!
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!
Poor understanding of legales seems to affect even those drafting it.
Thanks for the detailed breakdown.
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.
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.
Intel CPUs without firmware updates because of redistribution limitations? How can Intel make that mistake? Intel, please, reconsider that, for your own good.
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?
Is this just an attempt to limit distribution during a teething period, in case there are bugs in the new microcode?
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.
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.
And does AMD allow it? If yes, than we have one more reason to......
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.
> 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.
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.
How about Ryzen Pro which is targeted at enterprise?
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.
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
[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
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.
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.
It's strange that Intel hasn't fixed this yet.
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?
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.
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.
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
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?
Has Intel been taken over by agents on the payroll of AMD?
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.
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.
Did you bother to read the license?
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.
An explanation that‘s more detailed than „read the license“ would be really nice. And the submission title remains pure clickbait.
I both posted a link the entire license and the terms that are relevant.
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"
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"
This is not true.
Here's an Intel spokesperson commenting on the issue: https://twitter.com/imadsousou/status/1030260566483496960