Why I changed my mind on Firmware Blobs

Author: Jonathan Vasquez <jon@xyinn.org>
Last Updated: 2023-05-09-0830

Main

While engaging with some community members in the Framework Forum regarding Framework possibly using more friendly chips, that aren't just Windows and Linux compatible (FreeBSD in our case), a community member shared this video from Defcon Wireless Village 2014, that was done by Adrian Chadd, one of the main developers of the Atheros driver on FreeBSD, and also a previous (maybe still current?) employee, that worked on Atheros before and after it was bought by Qualcomm.

This talk gives a brief history of the Atheros 9k series and their internals. Adrian was only able to speak about publicly available portions of the chip, since he is under an NDA. Regardless, it was a very informative talk and I enjoyed it. Due to his talk, I've actually changed my stance on firmware blobs and am now in favor of them in a limited capacity. As a strong supporter of Open Source (not Free Software), I want as much of the code as possible to be open. However, I do acknowledge that there are particular aspects of the hardware that may need to be a little locked down in order to protect the society from negative consequences. While watching the talk, I was definitely reflecting on whether or not Firmware Blobs are as bad a thing as what some people in the Open Source community say it is, but I came to the opposite conclusion after finishing this talk.

In the talk, Adrian gives an example (18:46-20:03) where if you have full access to a wireless chip, you can just send some random tones out into the airwaves which will cause the wifi in your area to shutdown. This example alone convinced me that yes, we need to make sure these particular sections of the chip are locked down, and ensure that this type of behavior is not possible (or extremely difficult without significant amounts of reverse engineering done) in every day society. This scenario is scary because it's not just someone playing at home affecting their own equipment, but it's actually affecting entire communities, which could also have catastrophic consequences depending on what's happening in that area. This is not even getting into the types of things that I can't even imagine that could be done with manipulating frequencies, and transmitting purposefully malicious signals out into the public airwaves. Besides that, part of the regulatory requirements is to ensure that the chip is broadcasting at the frequency it says it's doing so, and that it isn't drifting over time. These would all be part of the FCC requirements, (and any other government agencies regulating wireless communication in other parts of the world).

With that said, I still ideally want to have as much transparency as possible, and as much open code as possible. I think perhaps the community and wireless manufacturers (and other manufacturers of other hardware components) could potentially come to a compromise where everything in a driver is open, except for the specific and limited sections of code that need to be under governatory regulation, or could potentially harm the society. Overall, I think there are two methods we could go down: either release all of the driver code as open source, and have a small firmware blob for those pieces, or they could release all the driver code as open source with no firmware blobs, but the hardware component itself is already pre-programmed to contain the information that the firmware blobs would have had. I'm not an electrical engineer, so I would assume that doing the latter would increase the price of production, and thus the firmware blob approach would allow for cheaper manufacturing. I'm fine with either as long as most of the code is open with exceptions to said regulatory bits being in the firmware blob.

Realistically speaking, I think corporations are not going to limit themselves to just putting the bare essential regulatory bits into a firmware blob, but will instead want to protect other types of IP, which is problematic when talking about an Open Source environment with full transparency (or as much as possible). I suppose we'll see what happens. But overall, thinking about this issue a bit more with the new information presented in Adrian's presentation, I'm definitely no longer against firmware blobs to the extent that I probably was before. From a values perspective, I'm definitely prioritizing community and society safety over Open Source code, which I think most people would agree with. I also believe that most people would agree that just because something is Open Source, doesn't mean it's good or that it's beneficial for society (let's say an Open Source Virus?).