the FSF’s relationship with firmware is harmful to free software users

The FSF has an unfortunate relationship with firmware, resulting in policies that made sense in the late 1980s, but actively harm users today, through recommending obsolescent equipment, requiring increased complexity in RYF-certified hardware designs and discouraging both good security practices and the creation of free replacement firmware. As a result of these policies, deficient hardware often winds up in the hands of those who need software freedom the most, in the name of RYF-certification.

the FSF and microcode

The normal Linux kernel is not recommended by the FSF, because it allows for the use of proprietary firmware with devices. Instead, they recommend Linux-libre, which disables support for proprietary firmware by ripping out code which allows for the firmware to be loaded on to devices. Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems.

The end result is that users who deploy the FSF-recommended firmware and kernel wind up with varying degrees of broken configurations. Worse yet, the Linux-libre project removes warning messages which suggest a user may want to update their processor microcode to avoid Meltdown and Spectre security vulnerabilities.

While it is true that processor microcode is a proprietary blob, from a security and reliability point of view, there are two types of CPU: you can have a broken CPU, or a less broken CPU, and microcode updates are intended to give you a less broken CPU. This is particularly important because microcode updates fix real problems in the CPU, and Libreboot has patches which hack around problems caused by deficient microcode burned into the CPU at manufacturing time, since it’s not allowed to update the microcode at early boot time.

There is also a common misconception about the capabilities of processor microcode. Over the years, I have talked with numerous software freedom advocates about the microcode issue, and many of them believe that microcode is capable of reprogramming the processor as if it were an FPGA or something. In reality, the microcode is a series of hot patches to the instruction decode logic, which is largely part of a fixed function execution pipeline. In other words, you can’t microcode update a CPU to add or substantially change capabilities.

By discouraging (or outright inhibiting in the case of Linux-libre) end users to exercise their freedom (a key tenet of software freedom being that the user has agency to do whatever she wants with her computer) to update their processor microcode, the FSF pursues a policy which leaves users at risk for vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update.

Purism’s Librem 5: a case study

The FSF “Respects Your Freedom” certification has a loophole so large you could drive a truck through it called the “secondary processor exception”. This is because it knows that generally speaking, entirely libre devices do not presently exist that have the capabilities people want. Purism used this loophole to sell a phone that had proprietary software blobs while passing it off as entirely free. The relevant text of the exception that allowed them to do this was:

However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software.

Purism was able to accomplish this by making the Librem 5 have not one, but two processors: when the phone first boots, it uses a secondary CPU as a service processor, which loads all of the relevant blobs (such as those required to initialize the DDR4 memory) before starting the main CPU and shutting itself off. In this way, they could have all the blobs they needed to use, without having to worry about them being user visible from PureOS. Under the policy, that left them free and clear for certification.

The problem of course is that by hiding these blobs in the service processor, users are largely unaware of their existence, and are unable to leverage their freedom to study, reverse engineer and replace these blobs with libre firmware, a remedy that would typically be made available to them as part of the four freedoms.

This means that users of the Librem 5 phone are objectively harmed in three ways: first, they are unaware of the existence of the blobs to begin with, second they do not have the ability to study the blobs, and third, they do not have the ability to replace the blobs. By pursing RYF certification, Purism released a device that is objectively worse for the practical freedom of their customers.

The irony, of course, is that Purism failed to gain certification at the end of this effort, creating a device that harmed consumer freedoms, with increased complexity, just to attempt to satisfy the requirements of a certification program they ultimately failed to gain certification from.

The Novena laptop: a second case study

In 2012, Andrew “bunnie” Huang began a project to create a laptop with the most free components he could find, called the Novena open laptop. It was based on the Freescale (now NXP) i.MX 6 CPU, which has an integrated Vivante GPU and WiFi radio. Every single component in the design had data sheets freely available, and the schematic itself was published under a free license.

But because the SoC used required blobs to boot the GPU and WiFi functionality, the FSF required that these components be mechanically disabled in the product in order to receive certification, despite an ongoing effort to write replacement firmware for both components. This replacement firmware was eventually released, and people are using these chips with that free firmware today.

Had bunnie chosen to comply with the RYF certification requirements, customers which purchased the Novena laptop would have been unable to use the integrated GPU and WiFi functionality, as it was physically disabled on the board, despite the availability of free replacement firmware for those components. Thankfully, bunnie chose not to move forward on RYF certification, and thus the Novena laptop can be used with GPU acceleration and WiFi.

the hardware which remains

In practice, it is difficult to get anything much more freedom-respecting than the Novena laptop. From a right-to-repair perspective, the Framework laptop is very good, but it still uses proprietary firmware. It is, however, built on a modern x86 CPU, and could be a reasonable target for corebooting, especially now that the embedded controller firmware’s source code has been released under a free license.

However, because of the Intel ME, the Framework laptop will rightly never be RYF-certified. Instead, the FSF promotes buying old thinkpads from 2009 with Libreboot pre-installed. This is a total disservice to users, as a computer from 2009 is totally obsolete now, and as discussed above, Intel CPUs tend to be rather broken without their microcode updates.

My advice is to ignore the RYF certification program, as it is actively harmful to the practical adoption of free software, and just buy whatever you can afford that will run a free OS well. At this point, total blob-free computing is a fool’s errand, so there are a lot of AMD Ryzen-based machines that will give you decent performance and GPU acceleration without the need for proprietary drivers. Vendors which use coreboot for their systems and open the source code for their embedded controllers should be at the front of the line. But the FSF will never suggest this as an option, because they have chosen unattainable ideological purity over the pragmatism of recommending what the market can actually provide.

27 replies on “the FSF’s relationship with firmware is harmful to free software users”

[…] La FSF tiene una relación abatida con el firmware, lo que resultó en pólizas de seguro que tenían sentido en la aburrida década de 1980, pero dañan activamente a los usuarios hoy en día, al recomendar instrumentos obsoletos, que requieren una complejidad elevada en los diseños de hardware certificados por RYF y desaconsejan tanto las prácticas correctas de seguridad como la creación de firmware de reemplazo gratuito. Debido a estas pólizas de seguro, el hardware deficiente en general termina en manos de personas que necesitan básicamente más libertad de instrumentos, en nombre de la certificación RYF. la FSF y el microcódigo El kernel de Linux convencional ya no es realmente útil para la FSF, ya que permite el uso de firmware propietario con dispositivos. En su lugar, implican Linux-libre, que deshabilita la mejora del firmware patentado extrayendo el código que permite que el firmware se cargue en los dispositivos. Libreboot, siendo FSF realmente útil, también tiene esta política de no permitir blobs de firmware en el árbol de fuentes, a pesar de ser una fuente de nada más que consideraciones. El resultado de la pausa es que los usuarios que implementan el kernel y el firmware realmente útiles de FSF pausan indirectamente con diversos grados de configuraciones rotas. Peor aún, la misión Linux-libre elimina los mensajes de advertencia que implican que una persona probablemente también desee actualizar el microcódigo de su procesador para liberarse de las vulnerabilidades de seguridad de Meltdown y Spectre. Si bien es evidente que el microcódigo del procesador es un blob patentado, desde el punto de vista de la seguridad y la confiabilidad, hay dos tipos de CPU: probablemente debe tener una CPU dañada, o una CPU mucho menos dañada, y actualizaciones de microcódigo. se supone que le proporcionarán una CPU mucho menos rota. Esto es particularmente importante porque las actualizaciones de microcódigo reparan las consideraciones correctas en la CPU, y Libreboot tiene parches que piratean las consideraciones esféricas debido a un microcódigo deficiente grabado en la CPU en el momento de la fabricación, ya que no se permite actualizar el microcódigo en el momento del arranque temprano. Además, podría haber un concepto erróneo convencional relacionado con las capacidades del microcódigo del procesador. A lo largo de los años, he hablado con una gran variedad de defensores de la libertad de las herramientas en relación con el traste del microcódigo, y muchos de ellos creen que el microcódigo puede reprogramar el procesador como si fuera un FPGA o algo así. En realidad, el microcódigo es una serie de parches activos para el sentido común de decodificación de instrucciones, que es básicamente un segmento de una canalización de ejecución característica montada. En otras palabras, probablemente no debe microcodificar la actualización de una CPU para que solo tenga que agregar o comercializar significativamente capacidades. Al desalentar (o directamente inhibir en el caso de Linux-libre) pausar a los usuarios para que ejerzan su libertad (un principio clave de la libertad del instrumento es que la persona tiene la posibilidad de alcanzar cualquier tema que quiera con su computadora) para actualizar el microcódigo de su procesador, el FSF sigue una política que deja a los clientes en peligro por vulnerabilidades similares a Meltdown y Spectre, que se han mitigado en parte a través de una actualización de microcódigo. Purism’s Librem 5: una mirada al caso La certificación FSF “Respeta su libertad” tiene una laguna tan clara que probablemente debe conducir un camión a través de la llamada “excepción del procesador secundario”. Esto se debe a que es consciente de que, en términos generales, los dispositivos totalmente libres ya no existen si incluyen las capacidades que la gente desea. El purismo palideció esta escapatoria para vender un teléfono celular que tenía manchas de herramientas patentadas mientras lo hacía pasar por completamente gratuito. El texto conectado de la excepción que les permitió lograr esto se convirtió en: Alternativamente, podría haber una excepción para los procesadores integrados secundarios. La excepción se aplica a los procesadores y FPGA auxiliares y de bajo nivel del interior entregados por el instrumento, cuyo interior ya no se configura después de que la persona obtiene el producto. Esto también podría incluir, por ejemplo, microcódigo dentro de un procesador, firmware integrado en una herramienta de E/S o el patrón de puerta de un FPGA. El instrumento en tales procesadores secundarios no depende como instrumento del producto. El purismo se convirtió en una característica para lograr esto al hacer que el Librem 5 no tenga uno, sino dos procesadores: cuando el teléfono arranca por primera vez, usa una CPU secundaria como procesador de soporte, que inicializa la RAM usando un blob patentado, luego las masas Blobs propietarios diferentes en dispositivos diferentes como la banda base antes de iniciar la primera CPU y apagarse. En este formulario, también incluirán la totalidad de los blobs que querían usar, sin desanimarse por el hecho de que se trate de personas de PureOS. Según la política, eso los dejaba libres y posibles para la certificación. El tema que no tiene sentido entrenar es que al ocultar estos blobs en el procesador del operador, los usuarios ignoran en gran medida su existencia y no pueden aprovechar su libertad para mirar, aplicar ingeniería inversa y reemplazar estos blobs con firmware libre, una decisión que presumiblemente funcionará bien. así en general se les expondrá por ahí como segmento de las cuatro libertades. De esta manera, los usuarios del teléfono Librem 5 se ven perjudicados objetivamente de tres maneras: en primer lugar, están ciegos a la existencia de los blobs para abrir, en segundo lugar, Internet ya no tiene la capacidad de mirar los blobs, y en tercer lugar, ellos Internet ya no incluye la flexibilidad para cambiar los blobs. Al buscar la certificación RYF, Purism lanzó un instrumento que es objetivamente peor para la colorida libertad de sus potencialidades. La computadora Novena: una segunda mirada al caso En 2012, Andrew “bunnie” Huang comenzó una misión para crear una computadora en la web con básicamente los ingredientes más gratuitos que probablemente podría encontrar en la web, llamada la computadora abierta Novena. Se puso en sintonía con la CPU Freescale (ahora NXP) i.MX 6, que tiene una GPU Vivante y una radio WiFi integradas. Todos y cada uno de los componentes del mantenimiento tenían hojas de detalles disponibles libremente, y el esquema en sí se imprimió bajo una licencia gratuita. Pero debido a que el SoC pálido requería blobs además del rendimiento de GPU y WiFi, la FSF requirió que estos ingredientes se deshabilitaran automáticamente en el producto para recibir la certificación, a pesar de un esfuerzo continuo para escribir firmware de reemplazo para ambos ingredientes. Este firmware de actualización se lanzó indirectamente, y la gente está utilizando estos chips con ese firmware gratuito hoy. Si Bunnie hubiera decidido cumplir con los requisitos de certificación RYF, las personas que compraron la computadora Novena no habrían podido hacer uso de la GPU integrada y el rendimiento WiFi, ya que se deshabilitó físicamente en la placa, a pesar de la provisión de firmware de actualización gratuito. por esos ingredientes. Felizmente, Bunnie decidió no seguir adelante con la certificación RYF y, por lo tanto, la computadora Novena incluso se verá pálida con la aceleración de GPU y WiFi. El hardware que permanece en Filosofía, es complejo de web el resto un poco más respetuoso de la libertad que la computadora Novena. Desde el punto de vista de la reparación brillante, la computadora Framework tiene toda la razón, pero silenciosamente usa firmware propietario. Por otro lado, está construido en una CPU x86 más moderna y, presumiblemente, también podría ser una aplicación económica para el arranque, especialmente ahora que el código fuente del firmware del controlador integrado se ha lanzado bajo una licencia gratuita. Alternativamente, gracias a Intel ME, la computadora Framework no tendrá la certificación RYF. En cambio, la FSF promueve la compra de thinkpads obsoletos de 2009 con Libreboot preinstalado. Eso es un completo perjuicio para los clientes, ya que una PC de 2009 es completamente pálida ahora y, como se mencionó anteriormente, las CPU Intel tienden a estar bastante rotas sin sus actualizaciones de microcódigo. Mi consejo es ignorar el programa de certificación RYF, ya que es activamente execrable para la adopción colorida de la herramienta gratuita, y simplemente no elegir ningún tema que presumiblemente deba presumiblemente y presumiblemente también incluir los fondos para eso. romperá un sistema operativo gratuito perfectamente. En este punto, la computación completa sin manchas es una tarea tonta, por lo que hay una gran cantidad de máquinas basadas principalmente en AMD Ryzen que le brindarán un rendimiento decente y aceleración de GPU sin la necesidad de controladores propietarios. Los proveedores que ejecutan coreboot para sus sistemas y abren el código fuente de sus controladores integrados deben estar tranquilos en la entrada de la carretera. Pero es de suponer que la FSF también podría no implicar esto como una posibilidad, porque prefieren una pureza ideológica inconcebible elegida sobre el pragmatismo de recomendar lo que el mercado realmente puede ofrecer.Lee mas […]

> While it is true that processor microcode is a proprietary blob, from a security and reliability point of view, there are two types of CPU: you can have a broken CPU, or a less broken CPU, and microcode updates are intended to give you a less broken CPU.

Isn’t it the case that the *vendor* has the choice of leaving users with broken CPUs, or deciding that they can make their firmware code FOSS and thereby provide users with less broken CPUs *and* the ability to inspect them and fix them in future?

In other words: why is the user the victim and yet also expected to accept proprietary blobs from the vendor?

If a security vulnerability on someone’s computer is exploited because the CPU was buggy, then I think that much of the fault lies with the exploiter and the vendor.

The RYF certificate has no concern for security or pragmatism. It is freedom first, everything else second. It wants to achieve the goal of freedom first and only then worry about how to improve the situation.

As of right now I would not recommend RYF certified computers to the average computer user, but I wouldn’t consider it harmful. I agree it is currently only fit for the true software freedom hardliners like myself, the small minority of computer users that puts freedom above anything else including security and convenience.

And yes that does mean that currently the best options are Intel Thinkpads from 2009 and AMD motherboards from 2011, which I am both using at the moment for this exact reason.

The “secondary processor exception” exists for a reason. It exists so that devices that have onboard microcode like disk devices or network adapter can actually be used.

The most important part of this exception is “within which software installation is not intended after the user obtains the product”. This means that the user as well as the vendor can not update the microcode in this processor after purchase. It must be practically read-only.

This exception is also in line with earlier GNU philosophy, like how Richard Stallman states on his website “if updating software is not a normal part of use of the device, then it is not a computer.”. So software freedom does not apply here.

What Purism tried to do with the design of the Librem 5 is a very interesting hack, but it ultimately failed. I think you should mention in the article that the Librem 5 is not a RYF certified device, to avoid confusion to the reader. You seem to suggest that Purism successfully used this “loophole”, which is simply incorrect, they are were not successful in obtaining RYF certification.

Also the FSF’s reasoning on your second case study makes sense. An “ongoing effort” is not good enough for RYF. The device needs to be free at the moment the user receives the device, not potentially years later. It’s great that Novena users are able to use these chips with free software today, but they weren’t at first. If they tried to reapply to RYF certification again today they would become certified I assume. So they definitely should try it again now that these issues are fixed.

However, What I would like to see is a free hardware verification program that rates devices on a scale, instead of it completely binary like having a RYF certificate or not. According to the RYF program computers that come very close such as the Novena project, MNT Reform, System76, Pine64 etc. are just as bad as getting the latest Apple Macintosh. Both are considered nonfree, one not better than the other.

I would like to someone to make a hardware freedom index that rates devices on a scale, for example, 1 to 10. So these computers that come very close to RYF standards can get 9 or 8 out of 10. While computers that do not even try or actively make the software freedom situation worse can get a 1 out of 10.

I think this would be a lot more helpful to the average computer user shopping for new hardware than RYF currently is

I can understand Novena not being eligible for RYF at the time when they *shipped* with a non free driver. What I don’t understand is the request to permanently disable the GPU (by blowing fuses) in order to be certified.

If they had done that then people who had purchased devices back then would not have been able to update their existing devices to use the free driver that is now available.

This policy effectively discourages incremental development and improvement which is really required for progress, especially in a distributed, colaborative mode.

But totally agree with your point that it should be a scale of values not just a binary yes/no.

This reminds me of the position of OpenBSD on blobs, were if I remember correctly freely-redistributable blobs are tolerated (quite also what happens on normal distros).

The Librem5 example is a pretty good one, it is also rather frequent on other devices that are more or less RYF-certified, you end up with a difficult to access and replace chip containing the firmware rather than simply having the CPU pushing the firmware to the device on initialisation.

I wish GNU/FSF would stop having their very strong mix of a very conservative and delusional-utopia position and rather try to improve and protect IT rights like what a lot of other organisations dedicated to Libre Software, Internet Freedom, Right to Repair, … are doing.

FSF does not at any point delusional.
They protecting basic human right for God sake.

Its just so happen that protecting basic human rights is “not mainstream” in 21 century, to “conservative”, “delusional” and “utopian”.

– “protect IT rights like”

There is no such thing in nature as “IT rights”.
If this “IT rights” does not respect basic human rights – than this is not rights at all, this is something quite opposite.
Than this is a false political category that leading peoples attention from real problems of worse.

I don’t understand how the two devices mentioned are related to FSF

And I do not understand how you’re being “limited” from choice by using Linux-Libre. It was your choice in the first place to use a kernel that is completely open source.

You do not clearly understand what for FSF stands for and what user freedoms is.

Your problem does not cost time for article writing.
Just create you own (Somehow Respect Your Freedom in Commercially Beneficial Way) certification.

This was rude. I dint mean it.
But my point stands. This certification is given to hardware that can run free-libre software.
It is basically what it is.
Complaining that water is wet is counterproductive.

But I also agree that there is a lot room for popularizing free/libre technologies as such.
By my knowledge of FSF I don’t believe that they a particularly interested or even have resources for such work.

So we must talk about what can be achieved outside FSF in this regard.

Comments are closed.