Este artículo de codon.org.uk explora la compleja decisión de actualizar o no los 'blobs' de código no libre que a menudo se encuentran en hardware moderno. Estos 'blobs' son esencialmente código (a menudo escrito en C y dirigido a arquitecturas como Arm o RISC-V) que controla el funcionamiento de dispositivos, diferenciándose del software que se ejecuta dentro del sistema operativo principal. El problema central es que la mayoría de este código es propietario, lo que dificulta la verificación de su seguridad y funcionalidad.
El artículo comienza explicando que, aunque a menudo se llama 'firmware', es simplemente código, y la principal preocupación es que este código suele ser no libre y, a veces, incluso inaccesible para su inspección debido a cifrado o firmas criptográficas. La decisión de actualizar estos 'blobs' presenta una serie de consideraciones. ¿Realmente el código hace lo que dice? ¿Introduce nuevas funcionalidades no deseadas, vulnerabilidades de seguridad o incluso puertas traseras? La imposibilidad de auditar el código fuente (a diferencia del código abierto) significa que la confianza se basa en una cadena de confianza a menudo opaca, donde el usuario confía en la empresa que creó el hardware y el código, incluso si no conoce a las personas involucradas.
Además, se plantea la preocupación de que el hardware pueda estar intencionadamente comprometido desde el principio, y que las actualizaciones podrían introducir nuevas vulnerabilidades. El artículo destaca un caso real de vulnerabilidades en SSDs que solo se pudieron solucionar mediante actualizaciones de firmware, y que la imposibilidad de reemplazar el código comprometido habría requerido el reemplazo del hardware. También se menciona que actualizar un 'blob' no libre simplemente reemplaza uno con otro, sin aumentar necesariamente el número de 'blobs' en ejecución.
Finalmente, el autor comparte su perspectiva personal: aunque desconfía de los proveedores de CPU, reconoce que las actualizaciones son a veces necesarias para corregir errores, mejorar el rendimiento o mitigar vulnerabilidades como los ataques de ejecución especulativa. La decisión de actualizar se reduce a un equilibrio entre el riesgo potencial de un código malicioso y los beneficios de las correcciones y mejoras. En última instancia, el artículo anima a los lectores a considerar cuidadosamente los riesgos y beneficios antes de decidir si actualizar o no estos 'blobs' de código.