Intel is taking some of their firmware, and making it a mandatory binary blob. But it’s probably not what you’re fearing.

Intel announced about 90 days ago that Broxton and Skylake both will require graphics binary blobs – even in their fully-open-source drivers. I’m going to explain why this isn’t a big deal.

Today is Software Freedom Day. I’m growing a bit tired of people bashing Intel on this one in the FOSS community. Hence, this blog post.

Why do people hate binary blobs?

In general, FOSS (Free Open-Source Software) advocates hate binary blobs because they aren’t… FOSS. They aren’t open-source, so it’s difficult to peep inside the black box and figure out what they do.

In general, you do want to avoid binary blobs when possible. If you have a kernel driver that’s a binary blob, you’re giving software, you can’t examine and evaluate, power to interact with the kernel. Your only safeguard, at that point, are the rules of the kernel – which often trust drivers implicitly.

Needless to say, binary blob drivers are a good way for governments, hackers, corporate interests, and others to inject code that could be exploited later.

Another reason is that distribution rights are key. Projects like CyanogenMod were threatened, and to a degree, still are, because vendors like Qualcomm could shut them down by simply yanking redistribution rights to the driver blob files. As I’ll explain, Intel has promised not to do that.

What is binary blob firmware?

Binary blob firmware is a subset of a binary blob driver. Here the firmware is an enabling file that communicates with the driver. Think of it like a copy of your PC’s BIOS, in a file, that the driver needs to talk to in order to get the job done.

So why do companies use binary blobs?

Usually, when they have to. Typically, they licensed some code from somewhere – that they aren’t allowed to open-source.

Alternatively, it’s when a company is taking some of their firmware – and bringing it digitally into software, so that they can cut costs and save silicon space. What makes chips superior, at times, is the firmware. Big companies don’t always want to share those trade secrets with rivals.

There are technical gains from the latter step. For example, if you want to reduce touch screen lag, it may make sense to take some of the firmware from a controller, and virtualize that controller into the OS kernel. But, you may not want to share how you’re reducing that touch screen lag – so you keep the firmware a binary blob.

Why is Intel doing binary blob firmware?

First, it’s important to answer the what, then the why. Starting with 6th Generation Intel Core processors, and Broxton – the Atom compliment to Skylake, Intel will require binary blob firmware drivers to power its DRM subsystem.

By DRM, we mean Display Rendering Manager, not Digital Rights Management. There’s not really much of the latter involved here.

What this means is that the basic communications link between what picture is cobbled together by the GPU, and what shoots out to the monitor, is now governed in-part by this little binary blob.

The why is a little tougher to answer, because frankly, Intel hasn’t said why. Basically, it will either enhance functionality, or reduce cost – or both. I suspect it’s both (and I could write ten times as much about the reasons), but you’d have to ask Intel.

Is my system less secure with this?

No. DRM is a very secure subsystem. It has to be, otherwise someone could just use a kernel exploit to begin capturing frames of what’s on your screen. DRM goes upstream to the kernel, where it’s then governed to only access itself. Stuff goes in, not out, of DRM – except to a governed display output.

If you’re using a compiled, or closed-source Intel graphics driver (which over 90% of users are), then you already have a more potent binary blob that does much more. This only impacts the less-than-10% of people using Mesa as an open-source driver subsystem. They must include the binary blob firmware, or Mesa can’t push the rendered frames to the screen.

Intel is the last of the GPU makers to implement binary blob firmware. AMD, NVIDIA, PowerVR, and Qualcomm all employ binary blob firmware drivers for their GPUs.

And this is why you’re not trading security for freedom. DRM is developed anticipating a binary blob firmware – because everyone is already doing that. So Intel coming forward and doing the same, really doesn’t change DRM’s security. DRM is already watchdogging itself assuming that it can’t audit the firmware driver stack.

NVIDIA actually has held up using their latest GPUs with open-source drivers… because for some reason, they haven’t posted the required binary blobs.

In contrast, Intel has published their binary blobs, with free rights to redistribute, months before the chips launch. This means distributions of Linux that land when the chips do, will have these blobs built-in already.

In sum, Intel is doing what every other established graphics maker has already been doing. FOSS purists may not be happy about it, but Intel still leads the pack with the only first-party, fully open-source 2D and 3D OpenGL/VULKAN stack for Linux, and Android. That won’t change with this news.

As a user, do I need to do anything?

No. Open-source stacks are free to integrate these files. So when you update your OS, these files will download – but they’ll only run when you need them to do so. On non-Skylake/Broxton hardware, they won’t be able to do anything.

Full disclosure: I’m a distinguished developer by Intel. Mostly because I run a startup that works with Intel on a regular basis. Intel didn’t ask me to write this article.