An open letter to Andrew Tanenbaum
medium.com
medium.com
He's criticising Minix for exactly the reason he cites Minix being great -- it's open and free.
If someone wishes to use FOSS for negative purposes -- it certainly isn't within the FOSS community to stop them.
The first sentence doesn't have much to do with the second. You can use a free license that doesn't allow Intel to do what they have done.
"If someone wishes to use FOSS for negative purposes -- it certainly isn't within the FOSS community to stop them."
That's an odd statement. If I write software, I can do whatever I want with it. If I want to prevent something I view as evil or want to prevent corporate freeloading, that's not for the "FOSS community" to decide.
Would Linux's GPLv2 have prevented this circumstance? The kernel community has refused to adopt GPLv3 which would have prevented any "tivoization" [0].
[0] https://en.wikipedia.org/wiki/GNU_General_Public_License#Ver...
The creator had the option to choose a license that could have prevented this exact situation. The fact that he didn't, and is perfectly happy with Intel's usage (since he helped them) seems like enough reason to assign blame.
Lets pretend we've rewound the clock and MINIX is GPL licensed. Intel decides they want to write a low-level system that controls their hardware that the user can't modify.
They decide to base it on MINIX, so they start from MINIX, and at various points lets assume they customize MINIX's code to make it do what they want (this is questionable, since it seems like many of the things they wanted got published upstream when they asked Tanenbaum to make those changes). At some point, they think "let's also add a backdoor for ourselves/NSA/whatever", so they write a separate daemon to run on their little embedded system to do that.
Per the GPL, they publish sources for their modified MINIX, and every person who runs Intel hardware gets a copy of the source for MINIX, but not for the separate daemon, which Intel doesn't need to GPL. The chip doesn't need to allow users to replace or change the install Intel is baking onto it.
Now users know they're running MINIX, where they didn't before. They still can't see what custom code runs in the daemon Intel wrote, nor can they change or disable the running MINIX install.
What has been improved in this case by Tanenbaum hypothetically changing his licensing choice?
Actually, there is still controversy surrounding this since there has never been a GPL court case about what exactly counts as a derivative work. There are similiar concerns around proprietary Linux modules that interface with GPL'd kernel interfaces.
> What license could he have used that would have prevented the thing Intel did?
He could have chosen the JSON approach to licensing [0].
That is, the "separate daemon" really is separate from the kernel.
I'd say if one day the courts decided that Apache running on Linux had to be GPL'd by nature of being a derivative work, we'd experience so many fundamental issues with so many projects that Intel ME would barely register on the list.
GPLv3: https://www.gnu.org/licenses/rms-why-gplv3.en.html
Specifically: "One major danger that GPLv3 will block is tivoization. Tivoization means certain “appliances” (which have computers inside) contain GPL-covered software that you can't effectively change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer knows people will want to change, and aims to stop people from changing them. The manufacturers of these computers take advantage of the freedom that free software provides, but they don't let you do likewise."
In our hypothetical (and I suspect in reality), the code doing scary/concerning things sits in userspace on top of MINIX, so they'd just have to constrain their updates to that system.
So, since any piece of code can potentially end up in a monitoring, surveillance system, the only logical conclusion is we must kill BSD licensing.
> and is perfectly happy with Intel's usage
Not really:
> Many people (including me) don't like the idea of an all-powerful management engine in there at all (since it is a possible security hole and a dangerous idea in the first place), but that is Intel's business decision and a separate issue from the code it runs.
Actually, the license debate is the full extent of the debate over end-user freedom. It's the only tool someone writing software has to guarantee end-user freedom.
I would phrase it differently.
"Intel has developed a product, which they sell (to anyone), to allow companies to manage their computers so that you can do things like re-image machines remotely, change BIOS settings, etc"
I honestly can't understand the mass hysteria around this. As a 'de-facto' sys-admin in a small company, I find this immensely useful.
I understand the needs of IT, but many ´helpful’ IT tools I’ve seen installed over the years on corporate computers have been making things less secure and not more
Edit: fixed spellings
Fortunately, most of the security vulnerabilities that have been abused in this sort of way in the past are patched quickly. But what if it was impossible to patch systems because the vulnerability is baked into firmware? That's the horrifying case that we have here. If exploiting this software (and exploits HAVE ALREADY been published, so it's really just a matter of weaponisation at this point) becomes common, then many sysadmins will be in the unenviable position where someone who can download instructions from the Internet can cause immense damage to their systems and network on any given day.
And that's just the tip of the iceberg. Imagining how these systems are very, very likely already being used to conduct digital espionage is similarly disturbing. It's easy to think that "no one would want to conduct espionage against my tiny company in ${small town}", but unfortunately the reality is quite different. https://www.fbi.gov/news/stories/economic-espionage has some reasonably interesting information about the sort of shenanigans that are routinely undertaken - unfortunately this is just a small example as many instances are not publically discussed.
Computer security requires you to model the threat first, before proposing mitigations/solutions/tradeoffs/etc. Has this been done here? I'm merely asking since I don't know. Questions by themselves might lead us to an interesting path of inquiry, but we should also occasionally ground ourselves so we know what actually happens when the rubber meets the road.
https://nvd.nist.gov/vuln/detail/CVE-2017-5689 is the CVE in question and existed for ~7 years, permitting exactly the scenarios I postulated to occur given unprivileged access to the network on which the servers reside.
There's been some rapid threat modeling done already: for example, for datacenter environments, the impact of this issue is largely mitigated by reducing physical access to this network behind the firewall - https://software.intel.com/en-us/documentation/amt-reference... indicates that we can firewall traffic so that only known management computers can access it from outside. (However, one compromised computer in the datacenter can be used as a source to trigger this exploit, so whole-datacenter monitoring/alerting for traffic on these ports is required).
The overall risk involved is still fairly high, because this security posture is effectively "remote root-level access for anyone with unprivileged access to the local network".
"Mass hysteria?" Consumers thought they were just buying a CPU running what they put on it. Instead, it has a second CPU that can watch or control what they're doing. That CPU has a network stack, web server, and what seems to be hackable software. Intel also won't remove it. There wasn't demand among most individual buyers but this risky setup was forced on them anyway. Being forced to run a backdoored CPU on a hostile Internet just to continue to use x86 applications should create a strong, well-deserved backlash.
Business sector is different where there was lots of demand for management capabilities. That means there should be two tiers of products with and without the built-in backdoors. That responds to the expectations of each. The businesses probably also prefer the remote administration itself to be secure. Intel had things available but didn't use them to save about $50k from what I can tell on something that generates billions in revenue. There's a segment of business needing management capabilities that would prefer to buy from a third party offering quality software in event Intel is going to slap some stuff together. Their interests aren't served even though there are such solutions in the PPC and ARM markets esp for embedded.
One other thing worth mentioning is that Intel and Microsoft were part of the Trusted Computing Group that were trying to use both CPU and OS modifications to force DRM on consumers for movie and music industry. Lots of their presentations bragged about how Intel's chips, esp with TPM's, might do that. So, it's probably also a conspiracy against consumers by tech companies who must have taken bribes from those who wanted DRM or have some other incentive (eg NSA's BULLRUN or FISA courts). Again, at least on DRM, there was backlash that watered it down a bit where it ended up fragmented such as protected media path in Windows, encryption for HDMI, etc.
Do note that there's nothing stopping Intel from setting it up as a general-purpose core that can run user-supplied code which can be a firmware package like ME, a third party alternative which might be FOSS, or nothing at all. Intel forcing it is almost certainly about benefiting them and their scheming partners at everyone's expense instead of a fair, mutually-beneficial offering. People should be mad. They should also boycott any company doing that if they can. In the past, the solution was PowerPC or SPARC since they supported Open Firmware standard. Leon3, a SPARC for embedded, was GPL'd entirely. For high-end, OpenPOWER has open firmware with Raptor Computing Systems planning to deploy them in their Talos line when IBM puts POWER9 on the market.
You can run the drivers in a locked down virtual machine. You can theoretically reverse engineer a driver if required.
None of this is possible with Intel ME. Similar with SMM blobs, but these are optional. Firmware is replaceable in at least theory with something like coreboot, and if not, you still have multiple options on various mainboards.
Nah, the stuff is already there, running, listening, and able to do things. Your tools enable you to see it doing it or extra functionality on top of the base software. Here's a nice presentation by a team working to replace as much of it as possible to show all the horrors:
https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit...
The difference between this and all those peripherals you brought up is that we wanted the peripherals because they were useful to us. They were even publicly advertised in the store or online description of the computer. We neither asked for nor were sold on a pile of software running things like web servers that we couldn't turn off, see, or secure. As in, we already buy security and monitoring products since that matters to us. Yet, we can't even see that software much less secure it.
An intentional, unwanted backdoor and hidden OS is different concept from accidental flaws in firmware on peripherals we found useful. Also, we have options with those ranging from not buying the peripheral to using one with little programmability to isolating it with IO/MMU. Not for CPU backdoors. And again, there's other vendors using open firmware showing all this secrecy and lack of user control was totally unnecessary. It's like Intel and AMD have an ulterior motive in not letting us turn off features that were built to support DRM and/or spying.
I didn't see anything in the presentation that corroborates with what you said. Do you have any other links that show that ME is automatically provisioned/enabled?
>The difference between this and all those peripherals you brought up is that we wanted the peripherals because they were useful to us.
They were advertised for their features, not for their internal components. No person buying a GPU imagines that malware can reside inside their GPU. Similarly no person buying a USB drive imagines that the USB drive's controller can be reprogrammed to do nefarious things.
>Also, we have options with those ranging from not buying the peripheral to using one with little programmability to isolating it with IO/MMU.
The point is that you are not aware of all of the places microcrontrollers are hiding currently, which are therefore easier to conceal because nobody (well, almost) is paying attention to them. Intel created a product which they announced to the world, and have released a lot of technical information on. You are insisting that Intel has an ulterior motive without providing any evidence, when far simpler explanations exist that make sense. I'm going to withhold judgement till I see such evidence.
I think you are confusing Intel's AMT with the ME. AMT is a ME application, and has to be enabled/provisioned. The ME, in general, can do other things, such as crytographically verifying boot firmware is correctly signed (aka BootGuard/Secure Boot/Verified Boot, and probably other names). Some vendors even allow you to add your own signing keys.
Some more info here: https://libreboot.org/faq.html#intelme
But I think the AMT technology is what the parent poster was referring to in their original and subsequent comments.
>That CPU has a network stack, web server, and what seems to be hackable software.
>Nah, the stuff is already there, running, listening, and able to do things.
From what I have read, the AMT portion is required to do all of the above. Its the AMT portion that handles the KVM over IP (VNC), Serial over IP, etc.
That some people use OSS for nefarious purposes does not mean that we should stop OSS.
On the other hand, Intel might have selected this implementation process specifically to accelerate delivery of enterprise and OEM requested features at a time when Intel was dominant and firmware-level security was less of an issue.
Given the competitive state of the modern volume processor market (mobile and cloud), it's a safe assumption that Intel will be open to changing their ways. And if not, AMD or some other company certainly will.
However, as the creator of Minix, I think going beyond having an amoral stance, to having an advocacy stance, would be nice.
I guess we need laws to prevent this from happening, just like you cannot hide ingredients on a food packaging, you shouldnt be able to 'hide' software (but still be able to protect IP rights.) FDA equivalent for silicon chips - Silicon Valley Administration edit - removed a poor analogy and added ()
The original (4-clause) BSD license includes that.
That’s not somebody to look up to.
He's actually done more for open source than almost anyone, now we have the temerity to say he hasn't done enough in the way we'd like?
That reeks of entitlement mentality from people who don't actually produce things of value, but have infinite electrons to criticize a giant in the field.
Funny how completely jerk behavior is cool from some people whole mere wish to get recognition is one step too far from others.