En el contexto del software gratuito y de código abierto , el software propietario que sólo 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 kernel de un sistema operativo de código abierto y, a veces, también se aplica al código que se ejecuta fuera del kernel, como imágenes de firmware del sistema, actualizaciones de microcódigo o programas de usuario . [1] [2] [3] [4] [5] [6] El término blob se utilizó por primera vez en los 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 incluirlos 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 sólo binarios. Esta práctica es más común para controladores de gráficos acelerados , dispositivos de red inalámbrica y controladores RAID de hardware . [7] En particular, los blobs binarios son muy poco comunes para los controladores de interfaz de red no inalámbrica , que casi siempre se pueden configurar mediante utilidades estándar (como ifconfig ) listas para usar; Theo de Raadt de OpenBSD atribuye esto al trabajo realizado por un único desarrollador de FreeBSD . [8] [9]
Algunos proyectos aprobados por la FSF se esfuerzan por proporcionar un sistema operativo gratuito y eliminarán todos los blobs binarios cuando no esté disponible la documentación del hardware o el código fuente de los controladores de dispositivos y todo el firmware aplicable; Dichos proyectos incluyen paquetes de kernel Linux-libre de FSFLA , Parabola , Devuan , Trisquel y LibreCMC . [10] Sin embargo, la gran mayoría de proyectos de código abierto hacen una distinción entre controladores de dispositivos solo binarios (blobs) y firmware solo binario (no considerados blobs [11] : ... ), lo que permite que cierto firmware propietario sea se distribuyen libremente como parte de sus núcleos y, ante el 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 bajo demanda. [15]
El proyecto OpenBSD tiene una política notable de no sólo no aceptar ningún controlador de dispositivo binario en su árbol fuente, sino que tampoco admite oficialmente ningún componente de controlador de dispositivo propietario de terceros en su plataforma; [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 forma 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 ni al microcódigo sin fuente. [19] : BSD El proyecto Debian incluía firmware binario libre y no libre del kernel de 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
Para OpenBSD, el líder del proyecto Theo de Raadt defiende la política de solicitar derechos de distribución sólo para firmware de microcódigo. "Una vez distribuidos... al menos el dispositivo funciona". Insinuando que la alternativa sería que los miembros de su pequeño proyecto codificaran ellos mismos firmware libre en el lenguaje ensamblador de muchos conjuntos de chips, suplica "no nos carguen con más tareas". A pesar de esto, prefiere los conjuntos de chips que funcionan sin firmware y habla con entusiasmo de los diseños asiáticos, que describe como más lentos en el mercado pero más maduros. [17]
En la comunidad de desarrollo del kernel de Linux , Linus Torvalds ha hecho fuertes declaraciones sobre la cuestión de los módulos sólo binarios, afirmando: "Me niego siquiera a considerar la posibilidad de atarme las manos sobre algún módulo sólo binario", y continúa: "Quiero que la gente sepa que cuando usan módulos sólo binarios, 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 repetido repetidamente Consideró que eran 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 pública general GNU . [23]
Sin embargo, el kernel de 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 kernel de Linux que intenta eliminar todos los blobs binarios, incluido el microcódigo sin fuente, escribió en 2011: "Linux no ha sido software libre desde 1996, cuando El señor Torvalds aceptó las primeras piezas de software no libre en las distribuciones de Linux que ha publicado desde 1991. A lo largo de estos años, mientras este núcleo creció en un factor de 14, la cantidad de firmware no libre requerido por los controladores de Linux creció en un factor alarmante de 83." [25]
La mayoría de los controladores para dispositivos móviles que ejecutan el sistema operativo Android se envían en binario y están vinculados a una versión específica del kernel de Linux. Esto hace que sea muy difícil actualizar una versión del kernel porque puede requerir ingeniería inversa , reimplementar los controladores de dispositivo propietarios como software libre, crear y depurar envoltorios, aplicar parches binarios o una combinación de estos pasos, todo lo cual implica que los dispositivos heredados nunca funcionarán. Obtenga la última versión de Android. [ cita necesaria ]
Hay varias razones por las que los blobs binarios pueden resultar problemáticos. [11]
En primer lugar, no se puede conocer su funcionamiento preciso y no se pueden detectar errores auditando el código fuente; Con frecuencia, los errores sólo se diagnostican mediante una investigación minuciosa cuando un sistema comienza a comportarse inesperadamente. Estos errores no detectados también pueden exponer silenciosamente a los usuarios y sistemas a riesgos de seguridad. Por lo tanto, no se puede verificar la idoneidad del conductor para el propósito, 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, los usuarios no pueden mejorar fácilmente el controlador, ni adaptarlo a arquitecturas que no eran compatibles originalmente, ni adaptarlo para funcionar con ligeras variantes del hardware ni actualizarlo para que funcione en nuevos núcleos que tengan la API y arquitectura modificadas.
En tercer lugar, el uso de este software obligaría a los usuarios a confiar en que los proveedores o terceros no colocarán puertas traseras, software espía o códigos maliciosos en el blob. Además, el proveedor de hardware puede decidir no dar soporte a un sistema operativo determinado, abandonar el mantenimiento del controlador en cualquier momento o, en caso de que la empresa cierre, dejar el controlador completamente sin soporte.
Finalmente, se puede considerar que los blobs binarios trazan una línea entre la parte de la comunidad que cree en los ideales del software libre, rechazando el software propietario, y la parte que ve el código abierto como deseable por razones puramente técnicas, a menudo careciendo de una fuerte oposición a los blobs binarios. "siempre que funcionen". Se considera que esta fragmentación y la aceptación de un número creciente de componentes propietarios en Linux debilitan 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 que un sistema operativo utilice un controlador de dispositivo propietario binario escrito para otro sistema operativo. Ejemplos de contenedores son NDISwrapper para Linux y Project Evil para FreeBSD y NetBSD . Estos contenedores permiten que estos sistemas operativos utilicen 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 utilizar servicios públicos externos para dar servicio al hardware. Los 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 adquirir de forma independiente blobs binarios específicos de Linux directamente del fabricante del hardware para monitorear y reparar el hardware. [12] [13] [26] Alrededor de 2005, esta situación impulsó a OpenBSD a crear y popularizar sus conceptos bio(4) , bioctl y unidad de sensor como una solución alternativa para el monitoreo RAID , [27] [16] los cuales Posteriormente, estos conceptos también llegaron a 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 una memoria flash integrada no volátil , pero para disminuir costos y facilitar las actualizaciones, algunos dispositivos contienen solo RAM estática y requieren el sistema operativo host. para cargar firmware cada vez que se conectan (especialmente dispositivos USB ). Aunque el firmware está presente en el controlador del sistema operativo, simplemente se copia en el dispositivo y no lo ejecuta la CPU, lo que elimina 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 en el controlador del sistema operativo. 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 gratuita e incondicional, las instrucciones de la máquina sobre cómo recuperar estas imágenes pueden proporcionarse en el árbol de puertos (lo que impide que algunos dispositivos inalámbricos gravados (por ejemplo, Intel Wireless) estén disponibles durante el instalación inicial). [30] En implementaciones de Microsoft Windows, el microcódigo binario puede estar incrustado directamente en el controlador del dispositivo SYS/DLL/VXD, en lugar de un archivo de microcódigo separado.
El BIOS , que funciona como un gestor de arranque y admite aplicaciones heredadas en modo real , es un componente crucial de muchas computadoras compatibles con IBM . A finales de la década de 1990 se empezó a trabajar en EFI (Interfaz de firmware extensible) con el objetivo de trasladar la BIOS heredada 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 en la industria como UEFI (Interfaz de firmware extensible unificada). El EDK (EFI Development Kit) fue desarrollado para ayudar en los proyectos de desarrollo de firmware EFI. [31]
También a finales de la década de 1990, se inició el proyecto coreboot para crear una alternativa de código abierto al BIOS heredado desde cero. [31] La comunidad de desarrolladores de coreboot se organiza en torno a Stefan Reinauer y está dirigida por desarrolladores de firmware con derechos de compromiso. [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 de código completamente abierto a BIOS y UEFI es libreboot , que fue promovido por la Free Software Foundation (FSF). [34]
Los blobs son controladores binarios compilados por proveedores sin ningún código fuente.
Sólo unos pocos vendedores recalcitrantes permanecen cerrados. / ethernet 95% documentado 99% funcionando / Documentación abierta en gran parte gracias al esfuerzo de un hombre: Bill Paul
Si el kernel está compilado con la opción COMPAT_LINUX, o están cargados los módulos aac_linux.ko y linux.ko...
Si el kernel está compilado con la opción COMPAT_LINUX, o están cargados los módulos aacraid_linux.ko y linux.ko...
controladores diseñados para herramientas de administración RAID de Linux solo binarias
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}