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?
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.
"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.
Beta dribblers created the SYNTHETIC concern about so-called 'binary blobs' (or what Alphas call "drivers that work properly and efficiently"). It is a NON-ISSUE, especially when you remember that such software 'binary blobs' run of HARDWARE 'binary blobs'- hardware that contains the DIRECT MATHEMATICAL EQUIVALENT to software.
Intel has been building NSA back-doors into its chips for years, and YES, in theory, if their hardware were 'open' there might be a chance of someone discovering the extent of the compromise. BUT open-source projects across time have suffered the scandal time and time again of having malicious code buried within for YEARS without discovery. Open source notably does not fix this issue.
A software binary blob is considered by every Alpha as merely extending the proprietary CLOSED SOURCE hardware on which the software runs, and is thus of no issue at all. Intel has reached the point where it needs to extend BY LAW DRM functionality already present in the hardware, and also wishes its rapidly improving integrated graphics to at least compete with AMD and Nvidia. It no longer has an incentive to provide SH*TTY drivers in order to please beta dribblers.
Idealism, far from being an 'ideal' pursuit, is broken BY DESIGN- which is why it is always sold to Betas by people creating anything BUT an ideal society. Decent, rational PRAGMATISM is the best hope in any situation, which means UNDERSTANDING the compromises, and ensuring they do not go too far.
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.
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.
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