Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Intel Open Source Hardware

Intel Skylake & Broxton Graphics Processors To Start Mandating Binary Blobs 193

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?
This discussion has been archived. No new comments can be posted.

Intel Skylake & Broxton Graphics Processors To Start Mandating Binary Blobs

Comments Filter:
  • rootkit? (Score:5, Insightful)

    by Anonymous Coward on Saturday June 06, 2015 @09:41AM (#49856197)

    Q: What guarantee do we have that these binary blobs don't contain root kits?
    A: None.

    This really isn't acceptable. :(

    • Re:rootkit? (Score:5, Funny)

      by BlueStrat ( 756137 ) on Saturday June 06, 2015 @10:00AM (#49856297)

      Q: What guarantee do we have that these binary blobs don't contain root kits?
      A: None.

      This really isn't acceptable. :(

      Aw, c'mon! It's not like the NSA would risk vital US infrastructure, foreign trade, and financial/military/corporate/individual security by deliberately compromising the security of widely used operating systems, software, and/or encryption!

      That's just crazy talk.

      Strat

    • Re:rootkit? (Score:5, Insightful)

      by CaptainJeff ( 731782 ) on Saturday June 06, 2015 @10:04AM (#49856325)
      The same guarantee that the microcode running in the GPU itself doesn't have any rootkits. Or that the microcode in the CPU itself doesn't. Or the rest of the chipset. etc.
    • Re:rootkit? (Score:5, Insightful)

      by WaffleMonster ( 969671 ) on Saturday June 06, 2015 @11:12AM (#49856637)

      Q: What guarantee do we have that these binary blobs don't contain root kits?
      A: None.

      This really isn't acceptable. :(

      This is madness. They own the hardware. If you don't trust the vendor they can still screw you in hardware. Your fucked either way.

      I don't recall people bitching about CPU microcode or any of a dozen subsystems in a typical computer which run on closed proprietary firmware.

      I actually think this is something we should be encouraging more of. What is dangerous is systems downloading firmware from onboard field upgradable roms because attackers have leveraged these vectors to destroy gear and persist ownage even after compromised systems have been completely wiped.

      • by CBravo ( 35450 )
        No, you mix two arguments. You can still publish a signed copy of a further perfectly open process. And only the signed copy will be accepted.
    • Q: What guarantee do we have that these binary blobs don't contain root kits? A: None.

      This really isn't acceptable. :(

      Would you feel better if the CPU/GPU came with the firmware preloaded? I agree that it's not ideal but the code is not loaded into the kernel, it's loaded into the hardware by the kernel.

      • Re:rootkit? (Score:5, Informative)

        by Copid ( 137416 ) on Saturday June 06, 2015 @06:00PM (#49858549)
        Exactly. I get a very strong feeling that a lot of people don't know what they're talking about here. There are "binary blobs" that are actually drivers or libraries used by drivers that get executed on your workstation's CPU and there are "binary blobs" that are just microcode that run on your graphics card / wifi NIC / sound card / whatever. I'm not in favor of the first type, but the second type is really not a big deal. Very few nontrivial chip designs exist these days without some sort of microcode.

        Nobody gets upset about the microcode that lives in ROM in the hardware, but if you have a driver that loads the microcode, suddenly everybody loses their shit. Microcode is *everywhere* and it's very rare that you ever get to see it.
    • Re:rootkit? (Score:5, Insightful)

      by Megol ( 3135005 ) on Saturday June 06, 2015 @01:01PM (#49857233)

      Are you aware that Intel (and AMD) have binary blobs combined with strong encryption and cryptographic signatures loaded into their processors? That those blobs can change execution behavior of individual instructions with essentially* no way to detect them? Those are called microcode updates and even if you disable loading new versions of microcode in the BIOS they are delivered with a standard one in onboard ROM.

      (* statistical analysis using several processors of the same stepping running in identical systems but with different microcode revisions may work, no guarantee though)

    • Re:rootkit? (Score:4, Insightful)

      by Pinky's Brain ( 1158667 ) on Saturday June 06, 2015 @01:34PM (#49857369)

      Between UEFI and SMM I consider x86 a rootkit, period.

      • Between UEFI and SMM I consider x86 a rootkit, period.

        Very much this, along with the microcode/hardware issues noted above.

        Pretty much, if you don't want it snoop-able, don't put that data on or connect it to/through a commercial consumer computer, especially if it/both is/are not air-gapped from the internet.

        The old ways are best. Sneakernets, dead-drops, OTPs for a few examples. The hugely increased reliance on the compromise of digital communications and computer system/network technology and the funding they've necessarily curtailed in other areas as a con

  • mandate? (Score:5, Insightful)

    by NostalgiaForInfinity ( 4001831 ) on Saturday June 06, 2015 @09:43AM (#49856205)

    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.

  • Choices (Score:2, Insightful)

    by OzPeter ( 195038 )

    What choices are left for those wanting a fully-free, de-blobbed system while having a usable desktop?

    How about don't use these new systems? And keep on using what you have used in the past?

  • I don't understand this presumption that you need 3D acceleration to have a usable desktop. There are plenty of older style cards that will work just fine with desktops that don't require 3D acceleration.

    You may want 3D acceleration and you may want to play games, but that isn't required for a "usable desktop."

    • by beelsebob ( 529313 ) on Saturday June 06, 2015 @10:08AM (#49856353)

      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.

      • I thought that people were using Linux to get rid of windows? /duck

    • by raxx7 ( 205260 )

      For such a short post, you've got plenty of wrong things.

      You assume that this is only about 3D.
      Now I don't know about Intel's plans but with the open source driver without the firmware blob, I can't even get my AMD card to work at more than 800x600.
      No mode settings (screen resolution), no power management, no video decoding, no accelerated anything: neither 3D nor 2D.
      Without the firmware blob, it's just an expensive power hungry 800x600 dumb frame buffer.

      And there are _not_ plenty of cards out there.
      Intel,

    • A compositing display server saves a lot of CPU, by just doing the rendering and rasterisation of windows once and then alpha blending the resulting windows. You don't need to redraw for expose events, you just composite the results. This saves even having to bring the background applications into the cache (or into RAM if they're swapped out). Within an application, you can get the same benefit, caching the rendered results of (for example) a complex data-driven view and not having to do a load of queri

    • Since when are we setting the bar so low? We had a usable desktop two decades ago, if you're willing to just toss out modern features. We also had "usable cars" and "usable airplanes" fifty years ago, but I'll bet you'd prefer to fly cross-country in a modern Boeing 777 than an old turboprop, right?

      Incidentally, there's really no such thing as "3D acceleration", with the possible exception of support for geometry-specific functions on the more modern cards. Much of the power of modern GPUs is dedicated t

  • by Greyfox ( 87712 )
    Has anyone kickstarted a completely open source video card yet?
    • http://en.wikipedia.org/wiki/Open_Graphics_Project [wikipedia.org]. My recollection is they eventually put out an overpriced, underperforming card, and in the following 5 years progress has passed them by.

      I think that the work required to make a competitive GPU company would cost far beyond $1e9, and just isn't going to happen until several years after semiconductor technology becomes stagnant, if ever.

  • Move To France (Score:2, Insightful)

    by Anonymous Coward

    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.

  • by iamacat ( 583406 ) on Saturday June 06, 2015 @10:19AM (#49856401)

    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.

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

      With the new approach, it looks easier to fold malwares in unexpected places

    • by jbn-o ( 555068 ) <mail@digitalcitizen.info> on Saturday June 06, 2015 @10:43PM (#49859583) Homepage

      If the same blob was included in chip's ROM, nobody would think it's different from before right?

      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 [gnu.org], newer essay on this topic [gnu.org]) 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.

  • by GNious ( 953874 ) on Saturday June 06, 2015 @10:43AM (#49856497)

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

  • by Anonymous Coward on Saturday June 06, 2015 @10:57AM (#49856561)

    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.

    • by Svartalf ( 2997 )
      So long as I'm using the blob and the device using it can still function in perpetuity, meaning that it's effectively firmware for the hardware and I can copy it ad-infinitum and expect each generation of the driver and code associated with the device to work with THAT particular blob, I'm am "fine" with it.

      It's still a problem, but it's so minor compared to closed drivers, etc., that I too question it being that much. Needs to be noted. Needs to have people aware of it. Then we move on.
  • Open Source GPUs (Score:5, Informative)

    by Theovon ( 109752 ) on Saturday June 06, 2015 @11:12AM (#49856629)

    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.

    • by AmiMoJo ( 196126 )

      Or maybe it's because building an open source GPU that is even remotely competitive is nearly impossible. Spinning your own silicon is very expensive and requires a lot of resources, like expensive closed source software. FPGAs and the like are not powerful enough. Even if you find a way to do it, the amount of research required to build something that even implements enough of OpenGL 2 in hardware to give half decent performance would prevent anything useful ever being released.

      It's the same reason why you

  • Yes. Mandating open firmware, awesome idea. Because we want to need X different compilers compiling code for Y different cpus/mcus running Z basic OSses just to compile our kernel and use our hardware. It will make our lives so much better. Why not just mandate that those embedded cpus must run Linux themselves?

    Perhaps it makes sense to differentiate between binary drivers for Linux (bad) and binary blobs running on the embedded hardware taking to opensource drivers (ok)?

  • OpenBSD has been pretty strict about using including binary blobs in their distributions. I would think this requirement by Intel would leave Open out. Sigh..
    • There are plenty of drivers in all "free" operating systems that are pretty much "binary blobs" for example the drivers for raid cards. they were written using a NDA documentation. joe blow does not have access to these documents (including errata) and has no ability to make any changes to the driver without potentially introducing terrible bugs.

      So whine all you want about "free software", the simple fact is that every "free" operating system is full of this type of unmaintainable "blob" code.

      Tell me ar

  • Has anyone found out *why* Intel is doing this?

    What springs to mind maybe they're using code from a third party (i.e. video codecs, HDMI/DRM management, etc.) and *that* third party is not open source (for whatever definition of 'open' you prefer.)

    If, (let me stress again, if) that's the case, then providing Intel with an open source solution that works better *might* resolve the issue.

    • 3-D hardware developers are very jealous of their high-paying jobs and they want to keep the "secret sauce" to themselves so they can maintain their stranglehold on the market. They will only allow their code to be released in binary form.

  • see what happens with intel when AMD is out of the way they jack up prices and cut back on stuff first's cutting back on pci-e lanes in $350-$400 cpus now open source what is next locked boot loaders? What to boot linux you need to buy a $250+ (1 cpu) $400-$600 (2 cpu) server boards or the top of line $300-500 gamer boards

  • Curse your sudden but inevitable betrayal!

  • While I feel the outrage over this move is probably overblown, it does vindicate the fairly extreme positions in regards to free software held by Richard Stallman. Basically the watered down idea of free software, called "open source", has taken off and really win the world over. Even Microsoft is embracing open source. Everyone sees the benefits. The problem is that they see that it can benefit their existing proprietary models quite well. So for example Microsoft, while being more open to open source and

    • by raxx7 ( 205260 )

      This isn't a step back for open source; it's just staying the same.

      Despite the great success of open source software, which I'm using to write this post, the underlying computers where this software runs have always been proprietary hardware implementations with some proprietary firmware blobs (eg, the BIOS) stored somewhere.

      The fact that some companies have moved from hardware to on-board firmware stored on EEPROMs to firmware which needs to be uploaded by the driver isn't a real change , as long as the li

  • well, so much for that experiment. Back to NVIDIA. I'll take performance/closed blob over crap performance/closed blob.
  • Yes, I tend to see things as black or white. And yes, I could use more exercise. But I'm working on it.

  • 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)

    • by ledow ( 319597 )

      Reverse-engineering is often allowed anyway if it's for the purposes of integration and compatibility.

      Hence Samba can happily reverse-engineer things, no matter what the Windows licence says. They can't TAKE CODE (i.e. you can have been tainted by seeing the Windows source) but reverse-engineering from a binary is another matter entirely.

      And just because a contract says something's not allowed, it doesn't mean anything unless a court agrees. 99.9% of the time, it would never even get that far. Yes, it's

6.023 x 10 to the 23rd power alligator pears = Avocado's number

Working...