Bloque binario

En el contexto del software libre y de código abierto , el software propietario disponible solo como un 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 ofrecen 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 ofrecen documentación completa para algunos de sus productos y, en su lugar, proporcionan controladores binarios únicamente. Esta práctica es más común para los controladores de gráficos acelerados , los dispositivos de red inalámbrica y los controladores RAID de hardware . ^{[ 7 ]} Cabe destacar que los controladores de código cerrado son muy poco comunes para los controladores de interfaz de red que no son inalámbricos , los cuales casi siempre se pueden configurar mediante utilidades estándar (como ifconfig ) de forma inmediata; 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 libre y eliminarán todos los blobs binarios cuando no haya documentación para el hardware o el código fuente para los controladores de dispositivos y todo el firmware aplicable; tales 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 considerado blobs ^{[ 11 ]} ), lo que permite que cierto firmware propietario se distribuya libremente como parte de sus kernels y, para 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 de 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 solo no aceptar ningún controlador de dispositivo binario en su árbol de código fuente, sino que tampoco admite oficialmente ningún componente de controlador de dispositivo propietario de terceros en su plataforma; ^{[ 16 ] : 38...} citando no solo 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 "blobs" en la comunidad BSD se refiere solo a lo que considera controladores no libres, y no se aplica al firmware propietario y al microcódigo sin fuente. ^{[ 19 ] : BSD} El proyecto Debian incluyó 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}

En el caso de OpenBSD, el líder del proyecto, Theo de Raadt, defiende la política de solicitar derechos de distribución únicamente para el firmware de microcódigo. «Una vez distribuidos... al menos el dispositivo funciona». Dando a entender que la alternativa sería que los miembros de su pequeño proyecto programaran ellos mismos el firmware libre en el lenguaje ensamblador de muchos conjuntos de chips, suplica: «No nos sobrecarguen 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 llegar al mercado pero más maduros. ^{[ 17 ]}

En la comunidad de desarrollo del kernel de Linux , Linus Torvalds ha hecho declaraciones contundentes sobre el tema de los módulos exclusivamente binarios, afirmando: "Me niego siquiera a considerar atarme las manos por algún módulo exclusivamente binario", y continuando: "Quiero que la gente sepa que cuando usan módulos exclusivamente binarios, es SU problema". ^{[ 21 ]} En 2008, 176 desarrolladores del kernel de Linux firmaron una Declaración de Posición sobre Módulos del Kernel de Linux que afirmaba: "Nosotros, los abajo firmantes, desarrolladores del kernel de Linux, 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 GNU General Public License . ^{[ 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 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 kernel 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 con sistema operativo Android se distribuyen en formato binario y están vinculados a una versión específica del kernel de Linux. Esto dificulta enormemente la actualización del kernel, ya que puede requerir ingeniería inversa , la reimplementación de los controladores propietarios como software libre, la creación y depuración de adaptadores, la aplicación de parches binarios o una combinación de estos pasos. Todo esto implica que los dispositivos antiguos nunca recibirán la última versión de Android.

Hay varias razones por las que los blobs binarios ejecutables pueden ser problemáticos. ^{[ 11 ]}

En primer lugar, su funcionamiento preciso es desconocido y los errores no se pueden detectar mediante la auditoría del código fuente; con frecuencia, los errores solo se diagnostican tras una investigación minuciosa cuando un sistema comienza a comportarse de forma inesperada. Estos errores no detectados también pueden exponer silenciosamente a usuarios y sistemas a riesgos de seguridad. Por lo tanto, no se puede comprobar la idoneidad del controlador para su propósito, e incluso si se encuentra un error, no existe una solución sencilla.

En segundo lugar, dado que el código fuente no está disponible, el controlador no puede ser mejorado fácilmente por sus usuarios, no puede ser portado a arquitecturas que no fueron admitidas originalmente, ni adaptado para funcionar con ligeras variantes del hardware, ni actualizado para que funcione en nuevos núcleos 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 incluyan puertas traseras, software espía ni código malicioso en el archivo binario. Además, el fabricante del 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 quiebre, dejar el controlador completamente sin soporte.

Finalmente, los binarios sin formato pueden considerarse un punto de inflexión entre la parte de la comunidad que cree en los ideales del software libre y rechaza el software propietario, y la parte que ve el código abierto como deseable por razones puramente técnicas, sin oponerse con firmeza a los binarios sin formato "siempre que funcionen". Esta fragmentación, junto con la creciente aceptación de componentes propietarios en Linux, debilita 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 wrapper es un software que permite a un sistema operativo usar un controlador de dispositivo binario propietario escrito para otro sistema operativo. Ejemplos de wrappers son NDISwrapper para Linux y Project Evil para FreeBSD y NetBSD . Estos wrappers permiten a estos sistemas operativos usar 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. 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 los 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 bio(4) , bioctl y sensor drive como una solución alternativa para el monitoreo de RAID , ^{[ 27 ] [ 16 ]} conceptos que posteriormente también se han incorporado a NetBSD .

El firmware es el software requerido por los controladores integrados que acompaña a algún hardware, generalmente no se considera un blob binario. ^{[ 28 ] [ 19 ] : BSD [ 11 ] : ...} En muchos dispositivos, el firmware se almacena en memoria flash integrada no volátil , pero para reducir costos y facilitar la corrección de errores, algunos dispositivos contienen solo RAM estática y requieren que el sistema operativo host cargue el firmware/microcódigo cada vez que se encienden. Aunque el firmware está presente en el controlador del sistema operativo, simplemente se copia al dispositivo y no es ejecutado por la CPU, eliminando preocupaciones sobre fallas de seguridad adicionales en comparación con lo que ya es posible con un ataque DMA incluso si el firmware ya estuviera almacenado dentro del dispositivo en todo momento. El proyecto OpenBSD acepta imágenes de firmware/ microcódigo binario 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 pueden proporcionarse en el árbol de puertos (lo que impide que algunos dispositivos inalámbricos restringidos (por ejemplo, Intel Wireless) estén disponibles durante la instalación inicial). ^{[ 30 ]} En las implementaciones de Microsoft Windows, el binario de microcódigo puede estar incrustado en el controlador de dispositivo SYS / DLL / VXD directamente, en lugar de un archivo de microcódigo separado.

Muchos programas propietarios basados ​​en proyectos de código abierto, como Microsoft Edge y Google Chrome , incluyen bibliotecas de envoltura propietarias (DLL/SO) para la aceleración de hardware . ^{[ 31 ]} La biblioteca de envoltura no son controladores, sino que están relacionadas con aplicaciones para invocar la aceleración de hardware en ciertos dispositivos de hardware ( AMD , Intel , NVIDIA , Qualcomm , etc.).

La BIOS , que funciona como gestor de arranque y admite aplicaciones heredadas en modo real , es un componente crucial de muchos ordenadores 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 migrar la BIOS heredada a una interfaz moderna con un modelo de controlador modular. EFI es de código cerrado y finalmente fue adoptada por muchos fabricantes de hardware líderes del sector como UEFI (Interfaz de Firmware Extensible Unificada). El EDK (Kit de Desarrollo de EFI) se desarrolló para ayudar en los proyectos de desarrollo de firmware EFI. ^{[ 32 ]}

También a finales de la década de 1990, se inició el proyecto coreboot para crear desde cero una alternativa de código abierto a la BIOS tradicional. ^{[ 32 ]} La comunidad de desarrolladores de coreboot se organiza en torno a Stefan Reinauer y está liderada por desarrolladores de firmware con derechos de confirmación. ^{[ 33 ]} A pesar de que el firmware binario de código cerrado ha sido el núcleo de la arquitectura x86 , coreboot solo incorpora los pocos binarios propietarios necesarios para proporcionar a los usuarios un soporte de hardware básico. ^{[ 34 ]} Una alternativa completamente de código abierto a la BIOS y la UEFI es libreboot , que fue promovida por la Free Software Foundation (FSF). ^{[ 35 ]}

• McMillan, Robert (21 de junio de 2006). "Investigadores piratean el controlador Wi-Fi para acceder a una computadora portátil" . InfoWorld. Archivado del original el 2 de julio de 2006. Consultado el 23 de junio de 2006 .
• Artículo de KernelTrap sobre el controlador wpi(4) de Damien Bergamini, una alternativa sin blobs a ipw3945 para OpenBSD.
• Entrevista de KernelTrap con Jonathan Gray y Damien Bergamini sobre los blobs binarios.
• Entrevista sobre la vulnerabilidad inalámbrica Black Hat, transcrita textualmente por Brian Krebs en el sitio web del Washington Post, archivada el 5 de mayo de 2012.
• Un ejemplo creativo del valor de los conductores gratuitos , LWN.net