Slashdot Mirror
Intel Skylake & Broxton Graphics Processors To Start Mandating Binary Blobs
An anonymous reader writes: Intel has often been portrayed as the golden child within the Linux community and by those desiring a fully-free system without tainting their kernel with binary blobs while wanting a fully-supported open-source driver. The Intel Linux graphics driver over the years hasn't required any firmware blobs for acceleration, compared to AMD's open-source driver having many binary-only microcode files and Nouveau also needing blobs — including firmware files that NVIDIA still hasn't released for their latest GPUs. However, beginning with Intel Skylake and Broxton CPUs, their open-source driver will now too require closed-source firmware. The required "GuC" and "DMC" firmware files are for handling the new hardware's display microcontroller and workload scheduling engine. These firmware files are explicitly closed-source licensed and forbid any reverse-engineering. What choices are left for those wanting a fully-free, de-blobbed system while having a usable desktop?
Q: What guarantee do we have that these binary blobs don't contain root kits?
A: None.
This really isn't acceptable. :(
They aren't "mandating" anything. You buy their product, and they provide some closed source software with it that you need to get some of the functions. It sucks, but it isn't a "mandate".
You might want to consider letting it not bother you too much, though. After all, these chips have been full of proprietary code in the equivalent of ROM for a long time. The fact that some of it is migrating into RAM doesn't really change things very much.
If you really don't like loading proprietary blobs from RAM, use embedded processors; they usually don't do that because it wouldn't work very well in their environment.
If you really want to run a "fully-free, de-blobbed system", you need to get an open source processor and an open source motherboard.
That would be because any modern operating system (including most linux distros) uses 3D acceleration on a graphics card to put windows on a screen.
Be a conehead. Use that telex machine thing. Be a pepper. Go for it. Be all you can be. Aim high. Jump in a lake. Just not a skylake. Partake of toe jam and jelly not found in any store. Worship his holiness.
If the same blob was included in chip's ROM, nobody would think it's different from before right? The only difference here is that Intel is saving some money by not having a flashable ROM in the chip and instead having host OS provide the same blob on each boot. It's not like Windows driver gets a better blob or accesses some secret features not given to Linux developers.
If you are interested in open source hardware this is not in. But open sourcing all code running on main CPU is a significant step in itself and has many practical advantages (like being able to run/write whatever OS you want).
If community has done more with existing open hardware contributions like OpenSparc, I think we would see many new ones.
Intel's latest gen APU hangs with AMDs, but it's also almost twice the price, and that's before you factor in that the AMD board is cheaper and they tend to have better combos on Newegg. I can get a 7850k with a good board and 8 gigs of ram for $236 bucks. The equivalent i5 setup is going to be $450.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
"These firmware files are explicitly closed-source licensed and forbid any reverse-engineering."
Forbidding any reverse-engineering? I guess Intel will not be released this in Europe then.
Maybe, but you'll have to have an awfully attractive proposal and back it with heavyweight talent that already had a good reputation for delivering the goods.
For example, if a major video card vendor went belly-up for reasons not related to their tech (i.e. for plain old poor business practices) and their best coders banded together and started a kickstarter with a goal of $5B above and beyond the $1B they were personally tossing into the pot, they'd get my attention. But then again, they probably would be looking for traditional venture capital funding rather than kickstarter-type funding.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If it weren't for the fact that these binary blobs are updateable, no one would care. For example, your hard disk certainly has a "binary blob" in the form of its firmware, but because the OS isn't able to update it, no one cares and happily ignores it. However, the moment someone releases a hard drive where the OS can supply the binary blob so that the hard disk firmware is easily updated, the open source community will immediately reject this new device even though the only difference between it and the old device is that the old one, in the event of a firmware bug, could not be updated and simply remained unreliable for the lifetime of the device.
Indeed, that's probably what is happening here. Intel likely had such code in their cards all along, but previously the code was in a non-reprogrammable ROM. Now they've decided to add a new feature to their cards to allow bugs that are discovered in this code to be corrected, and everyone is simply going to complain about it. They were happy when no one could access the code and fix the bugs, but now that Intel can do it, they're not willing to accept not being able to do it themselves as well.
It's rather silly. Just imagine if the card could accept a binary blob, but refused it if it didn't match cryptographic checksums in the hardware that cannot be updated. It would be effectively the same as if the firmware were stored in a ROM in the hardware itself in that no one would ever be able to modify that code, but you can still bet that the open source community would be up in arms over not having access to the source code simply becase, whenever they can touch binary code, they're unable to accept the fact that they don't have the source to that binary code.
You have exceeded the limits of my universal translator, and that's even after I installed the Yodaspeak and Tamarian-metaphor-interpretation modules (side-note: the latter is huge, it has to incorporate the entirety of the Tamarian race).
Then translator did make this out though:
"Mod parent post down"
"#UNCLEARCONTEXT# Operating System"
"#UNCLEARMEANING# Possible reference to poster making many recent repeated arguments related to either the current topic of discussion, BSDI, or both, and a possible relationship between the current topic of discussion and BSDI"
"#SPECULATIONCONTINGENTONPREVIOUSUNCLEARTRANSLATION# Possible insult related to the possible many recent repeated arguments mentioned above"
If you will kindly let me know what additional modules I need to install in my universal translator, I will be able to understand you better. Thank you.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
An open source GPU: https://github.com/jbush001/NyuziProcessor
And its wiki: https://github.com/jbush001/NyuziProcessor/wiki
And even some peer-review: http://www.cs.binghamton.edu/~millerti/nyami-ispass2015.pdf
We could have fixed this problem a decade ago if the FOSS community had gotten behind the Open Graphics Project, but they're not as interested in FOSS-friendly graphics as they say they are. This is because most FOSS enthusiasts are more interested in gratis than they are in freedom.
I did kernel hacking for 10 years. I've fixed bugs in Ethernet drivers and helped document (and work around) hardware errata. I've also had to deal with trying to rebuild Nvidia drivers when the binary blob was no longer compatible with the latest kernel source. Having open-source drivers is key for those of us that actually *do* work on this stuff.
While I'm inclined to dismiss binary blobs as largely innocuous in most scenarios, you are oversimplifying things considerably.
1) Just because *I* don't have the time or interest to modify display firmware, doesn't mean I'm not in a position to benefit from *other people* doing so. Witness the entire Linux infrastructure, which owes its existence to the fact that the software stack of the time was NOT locked down, and critical hardware was all reasonably well documented.
2) The binary blobs are themselves dangerous - driver software is typically running with very high security clearance, and you have absolutely NO idea what is going on inside those blobs. Couple that with the fact that we now KNOW the NSA (and presumably other organizations as well) have actively recruited several major companies to collaborate in compromising the security of commodity hardware, and we're in the position of being completely unable to trust ANY binary-blob software in a security-critical scenario. Since Intel was pretty much the go-to option for decent(ish) fully open-source display accelerators, that alone validates a subset of the original question: What are our options now if we want a modern desktop that can be be audited for security?
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Compromised hardware though is (potentially) far more limited in its invasiveness. The CPU and motherboard chipset has fairly unrestricted access to the entire system and must be trusted, but pretty much everything else must go through those, and generally through the OS as well, which limits the amount of nefarious activity it can get up to (or at least makes it considerably more difficult, one would hope). For example, the firmware on the video card itself will have a difficult time gaining unrestricted access to RAM, hard drives, user input, network traffic, etc. At least if the OS is even moderately restrictive about DMA activity. The CPU-hosted driver on the other hand will, in most current OSes, be running with such elevated privileges that it will be trivial for it to gain such access.
Or so I understand it. I'll freely admit it's been a long while since I paid much attention to such details.
And of course it also raises the question - if you can't trust Intel's binary blobs in the driver, how can you trust their CPUs and chipsets? In that context I'd say their fully open video drivers were more valuable as a good example to their competitors than as true security. Though I suppose it is much easier to retroactively compromise existing hardware at the driver level, and it would likely require far fewer people to be complicit than hardware/microcode compromises would.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Unless the system has an I/O MMU, the hardware devices and any firmware they may be running have unrestricted access to RAM.
I/O MMUs were almost exclusive to server chipsets until some time ago.
Nowadays they are more common (spurred mostly by virtualization needs) but not totally universal yet. Intel likes to disable the feature in the K CPU models (which have unlocked frequency multipliers for better overclocking options).
I don't keep track of the status of phone/tablet SoCs but if I had to hazzard a guess, I'd bet most of them don't have an I/O MMU.
Being technically correct is never a substitute for understanding that you're completely wrong when applied to the pragmatic normal solution.
What you say is bullshit. As someone who installed NetBSD in the 90s and have also used many different GNU/Linux versions in the past, my experience is simply that the opener a system is, the better. I've seen and had to fix countless problems with systems who have proprietary drivers and binary blobs. That just sucks. What is not open cannot be fixed by someone, and companies tend to not fix things properly.
If you haven't made this experience, then must be exceptionally lucky or are about 8 years old. The opener the better. My 2 cents.
My experience is that the most reliable systems are closed source proprietary systems, because the development teams are well paid and well motivated. For example look at the systems used by wall street traders, hospitals, etc These systems are really really mission critical and are almost all closed-source software packages that come with extensive support and cost big money.
But if you've never worked with large enterprise systems, you can be forgiven for your ignorance
Yes, we would think it's different because it is different. When the functionality of that blob is in a ROM chip or circuitry, nobody can update it, including the proprietor, without hardware modification or hardware replacement. When the functionality is in software or any kind of reprogrammable device, the question becomes who is allowed to run, inspect, share, and modify that code. This is an important ethical distinction that the developmental philosophy of the younger open source movement was designed to never raise as an issue because that movement wants to pitch a message of cheap labor to businesses.
All the questions of software freedom enter the picture because you're dealing with software now. All the issues that the open source movement was designed not to raise (older essay on this topic, newer essay on this topic) the older free software movement raised over a decade before the open source movement began.
If this code were distributed as Free Software to its users, this could be great news for all of us (even the majority of computer users who will never fully take advantage of these freedoms because they're never going to become programmers). Programmers can accomplish wonderful practical benefits like putting in interesting features, fixing bugs, learning from the code, all while being friendly with others by giving or selling services based on improving that code, and helping to keep users safe from malware all along the way.
If this code is distributed as non-free user-subjugating software (a.k.a. proprietary software), the proprietor (Intel in this case) is the only party who can inspect, share, and modify that code. And users (regardless of technical ability) are purposefully left out of controlling their own computers, which is unethical.
Digital Citizen
I consider reverse engineering EULAs to be non-binding. As there are no considerations in such a contract nor does it have a reasonable duration for the contract or any option to cancel the contract. (at least most reverse engineering clauses I've read, there may be exceptions out there)
“Common sense is not so common.” — Voltaire