En el contexto del software libre y de código abierto , el software propietario que solo está disponible como ejecutable binario se denomina blob o blob binario . El término generalmente se refiere a un módulo de controlador de dispositivo cargado en el núcleo de un sistema operativo de código abierto y, a veces, también se aplica al código que se ejecuta fuera del núcleo, como imágenes de firmware del sistema, actualizaciones de microcódigo o programas de espacio de usuario . [1] [2] [3] [4] [5] [6] El término blob se utilizó por primera vez en sistemas de gestión de bases de datos para describir una colección de datos binarios almacenados como una sola entidad.
Cuando los proveedores de hardware informático proporcionan documentación técnica completa para sus productos, los desarrolladores de sistemas operativos pueden escribir controladores de dispositivos de hardware para que se incluyan en los núcleos del sistema operativo. Sin embargo, algunos proveedores, como Nvidia , no proporcionan documentación completa para algunos de sus productos y, en su lugar, proporcionan controladores solo binarios. Esta práctica es más común para los controladores de gráficos acelerados , dispositivos de red inalámbrica y controladores RAID de hardware . [7] En particular, los controladores de código cerrado son muy poco comunes para los controladores de interfaz de red no inalámbricos , que casi siempre se pueden configurar a través de utilidades estándar (como ifconfig ) de forma inmediata; Theo de Raadt de OpenBSD atribuye esto al trabajo realizado por un solo desarrollador de FreeBSD . [8] [9]
Algunos proyectos aprobados por la FSF se esfuerzan por proporcionar un sistema operativo libre y eliminarán todos los blobs binarios cuando no haya documentación disponible para el hardware o el código fuente para los controladores de dispositivos y todo el firmware aplicable; dichos proyectos incluyen el empaquetado del kernel Linux-libre de FSFLA , Parabola , Devuan , Trisquel y LibreCMC . [10] Sin embargo, la gran mayoría de los proyectos de código abierto hacen una distinción entre controladores de dispositivos solo binarios (blobs) y firmware solo binario (no se consideran blobs [11] : ... ), lo que permite que cierto firmware propietario se distribuya libremente como parte de sus núcleos y, para desacuerdo de algunos contribuyentes principales, también admiten el uso de controladores de dispositivos propietarios que se distribuyen externamente, proporcionando interfaces de compatibilidad interna para que dichos controladores propietarios y componentes del espacio de usuario funcionen con su sistema. [12] [13] Los proyectos que siguen esta política incluyen el propio kernel de Linux , NetBSD , FreeBSD , DragonFly BSD y la mayoría de las distribuciones de Linux . [14] Algunos de estos proyectos ofrecen opciones para construir el sistema sin firmware propietario, excluyendo así el microcódigo sin fuente a pedido. [15]
El proyecto OpenBSD tiene una política notable de no sólo no aceptar ningún controlador de dispositivo binario en su árbol de fuentes, sino también oficialmente no soportar ningún componente de controlador de dispositivo propietario de terceros en su plataforma, tampoco; [16] : 38... citando no sólo el potencial de fallas de seguridad indetectables o irreparables, sino también la invasión de la apertura y libertad de su software. [17] La Free Software Foundation (FSF) está haciendo campaña activamente contra los blobs binarios. [18] La FSF también considera que la política de OpenBSD está redactada de manera confusa, ya que los "blobs" en la comunidad BSD se refieren sólo a lo que considera controladores no libres, y no se aplican al firmware propietario y al microcódigo sin fuente. [19] : BSD El proyecto Debian incluía tanto firmware binario libre como no libre del núcleo Linux , marcando y separando claramente los paquetes no libres [20] de acuerdo con el Contrato Social de Debian . A partir de Debian 6.0 esos blobs fueron eliminados. [19] : Debian
En el caso de OpenBSD, el líder del proyecto Theo de Raadt defiende la política de pedir derechos de distribución sólo para el firmware de microcódigo. "Una vez distribuidos... al menos el dispositivo funciona". Implicando que la alternativa sería que los miembros de su pequeño proyecto codificaran ellos mismos el firmware libre en el lenguaje ensamblador de muchos chipsets, pide "no nos carguen con más tareas". A pesar de ello, favorece los chipsets que funcionan sin firmware y habla con entusiasmo de los diseños asiáticos, que describe como más lentos de comercializar pero más maduros. [17]
En la comunidad de desarrollo del kernel de Linux , Linus Torvalds ha hecho fuertes declaraciones sobre el tema de los módulos binarios solamente, afirmando: "Me niego a siquiera considerar atarme las manos sobre algún módulo binario solamente", y continuó: "Quiero que la gente sepa que cuando usan módulos binarios solamente, es SU problema". [21] En 2008, 176 desarrolladores del kernel de Linux firmaron una Declaración de Posición sobre los Módulos del Kernel de Linux que decía: "Nosotros, los desarrolladores del kernel de Linux abajo firmantes, consideramos que cualquier módulo o controlador del kernel de Linux de código cerrado es dañino e indeseable... Hemos encontrado repetidamente que son perjudiciales para los usuarios de Linux, las empresas y el ecosistema Linux en general". [22] El mantenedor del kernel de Linux Greg Kroah-Hartman ha declarado que es ilegal redistribuir módulos de código cerrado para el kernel de Linux con licencia de Licencia Pública General GNU . [23]
Sin embargo, el núcleo Linux contiene firmware de código cerrado requerido por varios controladores de dispositivos. [24] [19] Alexandre Oliva , el mantenedor de Linux-libre , una versión del núcleo Linux que intenta eliminar todos los blobs binarios, incluido el microcódigo sin código fuente, escribió en 2011: "Linux no ha sido software libre desde 1996, cuando el Sr. Torvalds aceptó las primeras piezas de software no libre en las distribuciones de Linux que ha publicado desde 1991. Durante estos años, mientras que este núcleo creció en un factor de 14, la cantidad de firmware no libre requerido por los controladores de Linux creció en un alarmante factor de 83". [25]
La mayoría de los controladores para dispositivos móviles que ejecutan el sistema operativo Android se entregan en formato binario y están vinculados a una versión específica del núcleo Linux. Esto hace que sea muy difícil actualizar una versión del núcleo porque puede requerir ingeniería inversa , reimplementar los controladores de dispositivos propietarios como software libre, crear y depurar contenedores, aplicar parches binarios o una combinación de estos pasos, todo lo cual implica que los dispositivos antiguos nunca obtendrán la última versión de Android. [ cita requerida ]
Hay varias razones por las que los blobs binarios pueden ser problemáticos. [11]
En primer lugar, no se puede conocer su funcionamiento preciso y no es posible detectar errores auditando el código fuente; los errores suelen diagnosticarse solo mediante una investigación minuciosa cuando un sistema comienza a comportarse de manera inesperada. Estos errores no detectados también pueden exponer silenciosamente a los usuarios y los sistemas a riesgos de seguridad. Por lo tanto, no se puede verificar la idoneidad del controlador para el propósito previsto e incluso si se encuentra un error, no hay una manera fácil de solucionarlo.
En segundo lugar, como el código fuente no está disponible, el controlador no puede ser mejorado fácilmente por sus usuarios, no puede ser portado a arquitecturas no soportadas originalmente, ni adaptado para operar con ligeras variantes del hardware o actualizado para que funcione en nuevos kernels que tengan la API y la arquitectura modificadas.
En tercer lugar, el uso de este software obligaría a los usuarios a confiar en que los proveedores o terceros no introducirían puertas traseras, programas espía o códigos maliciosos en el blob. Además, el proveedor de hardware puede decidir no dar soporte a un determinado sistema operativo, abandonar el mantenimiento de controladores en cualquier momento o, en caso de que la empresa quiebre, dejar el controlador completamente sin soporte.
Por último, los blobs binarios pueden considerarse como una línea divisoria entre la parte de la comunidad que cree en los ideales del software libre y rechaza el software propietario, y la parte que considera que el código abierto es deseable por razones puramente técnicas, y que a menudo carece de una fuerte oposición a los blobs binarios "siempre que funcionen". Esta fragmentación y la aceptación de un número creciente de componentes propietarios en Linux se considera un debilitamiento de la capacidad de la comunidad para resistir la tendencia de los fabricantes a negarse cada vez más a proporcionar documentación para sus binarios.
Un contenedor es un software que permite a un sistema operativo utilizar un controlador de dispositivo propietario binario escrito para otro sistema operativo. Algunos ejemplos de contenedores son NDISwrapper para Linux y Project Evil para FreeBSD y NetBSD . Estos contenedores permiten a estos sistemas operativos utilizar controladores de red escritos para Microsoft Windows mediante la implementación de la API NDIS de Microsoft .
Otro ejemplo es proporcionar capas de compatibilidad para que se puedan usar utilidades externas para dar servicio al hardware. Algunos ejemplos incluyen algunos controladores de controlador RAID en FreeBSD , donde el administrador del sistema tendría que habilitar la capa de compatibilidad de Linux en FreeBSD y obtener de forma independiente blobs binarios específicos de Linux directamente del fabricante del hardware para monitorear y dar servicio al hardware. [12] [13] [26] Alrededor de 2005, esta situación impulsó a OpenBSD a crear y popularizar sus conceptos de unidad bio(4) , bioctl y sensor como una solución alternativa para la monitorización RAID , [27] [16] ambos conceptos han encontrado posteriormente su camino también en NetBSD .
El firmware es el software requerido por los microcontroladores integrados que acompañan a algún hardware, generalmente no se considera un blob binario. [28] [19] : BSD [11] : ... En muchos dispositivos, el firmware se almacena en la memoria flash integrada no volátil , pero para reducir los costos y facilitar las actualizaciones, algunos dispositivos contienen solo RAM estática y requieren que el sistema operativo host cargue el firmware cada vez que se conectan (especialmente los dispositivos USB ). Aunque el firmware está presente en el controlador del sistema operativo, simplemente se copia al dispositivo y no lo ejecuta la CPU, lo que elimina las preocupaciones sobre fallas de seguridad adicionales en comparación con lo que ya es posible con un ataque DMA incluso si el firmware ya estaba almacenado dentro del dispositivo en todo momento. El proyecto OpenBSD acepta imágenes binarias de firmware/ microcódigo y redistribuirá estas imágenes si la licencia lo permite; [28] [29] Si el proveedor no permite la redistribución libre e incondicional, las instrucciones de la máquina para obtener estas imágenes se pueden proporcionar en el árbol de puertos (lo que impide que algunos dispositivos inalámbricos obstaculizados (por ejemplo, Intel Wireless) estén disponibles durante la instalación inicial). [30] En las implementaciones de Microsoft Windows, el binario de microcódigo se puede integrar directamente en el controlador de dispositivo SYS/DLL/VXD, en lugar de en un archivo de microcódigo separado.
El BIOS , que funciona como un gestor de arranque y admite aplicaciones de modo real heredadas , es un componente crucial de muchas computadoras compatibles con IBM . A fines de la década de 1990, se comenzó a trabajar en EFI (Interfaz de firmware extensible) con el objetivo de trasladar el BIOS heredado a una interfaz moderna con un modelo de controlador modular. EFI es de código cerrado y finalmente fue adoptado por muchos fabricantes de hardware líderes de la industria como UEFI (Interfaz de firmware extensible unificada). El EDK (Kit de desarrollo EFI) se desarrolló para ayudar a los proyectos de desarrollo de firmware EFI. [31]
También a finales de los años 1990, se inició el proyecto coreboot para crear una alternativa de código abierto a la BIOS heredada desde cero. [31] La comunidad de desarrolladores de coreboot se organiza alrededor de Stefan Reinauer y está liderada por desarrolladores de firmware con derechos de confirmación. [32] A pesar de que el firmware binario de código cerrado ha estado en el corazón de la arquitectura x86 , coreboot solo incorpora los pocos binarios propietarios que son necesarios para proporcionar a los usuarios un soporte de hardware de nivel básico. [33] Una alternativa completamente de código abierto a BIOS y UEFI es libreboot , que fue promovida por la Free Software Foundation (FSF). [34]
Los blobs son controladores binarios compilados por el proveedor sin ningún código fuente.
Solo unos pocos proveedores recalcitrantes permanecen cerrados. / Ethernet 95 % documentado 99 % funcionando / Documentación abierta en gran parte debido al esfuerzo de un hombre: Bill Paul
Si el núcleo se compila con la opción COMPAT_LINUX, o se cargan los módulos aac_linux.ko y linux.ko...
Si el núcleo se compila con la opción COMPAT_LINUX o se cargan los módulos aacraid_linux.ko y linux.ko...
Controladores diseñados solo para herramientas de administración RAID de Linux con binarios
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}