Blob binario

En el contexto del Software Libre, Blob binario (en inglés Binary blob) es un término peyorativo para un objeto cargado en el núcleo de un sistema operativo de código abierto o libre, sin tener su respectivo código fuente disponible.

Cuando los fabricantes de hardware proveen una documentación técnica completa de sus productos, los desarrolladores de sistemas operativos son capaces de escribir controladores para tales dispositivos e incluirlos en los núcleos de sus sistemas operativos. Sin embargo algunos proveedores de hardware tales como Nvidia no proveen la documentación técnica necesaria para desarrollar tales controladores, en cambio los mismos proporcionan los controladores ya compilados (blobs binarios); esta práctica es más común en controladores para placas aceleradoras de video, dispositivos de redes y controladores de disco RAID.

Aceptación

Cuando los desarrolladores no tienen acceso tanto a la documentación ni al código de los controladores de algún dispositivo, algunos proyectos de sistemas operativos, incluyendo NetBSD, FreeBSD, DragonFly BSD, y algunas distribuciones GNU con Linux, aceptan blobs binarios como una ruta rápida para implementar las funcionalidades faltantes o mejoradas que estos blobs binarios proveen.

Los proyectos OpenBSD y Liberty BSD tienen la notable política de no aceptar ningún blob binario dentro de su árbol de código, previniendo potenciales agujeros de seguridad indetectables e irreparables y a su vez demostrar la transparencia y libertad de su sistema.

Entre las distribuciones GNU/Linux, gNewSense, Trisquel, Parabola son las más conocidas por su activa oposición en contra de los blobs binarios. La fundación para el software libre esta activamente luchando en contra de los blobs binarios y recomienda gNewSense.

Uso vía wrappers

Para hacer uso de los blobs binarios disponibles para otros sistemas operativos, algunos proyectos incluyen wrappers, los cuales permiten usar controladores escritos para otros sistemas operativos ajenos al mismo.

Problemas

Hay un buen número de razones por la cual blobs binarios pueden causar problemas:

Los usuarios no son capaces de modificar el software y distribuir versiones modificadas.
Los blobs binarios están usualmente limitados a unas cuantas arquitecturas de hardware y no pueden ser portadas a ningún otro sistema.
La corrección del controlador no puede ser chequeada.
El código no puede ser auditado para la seguridad de los usuarios o grupos de terceros.
Los usuarios están forzados a confiar en que sus vendedores no colocaron puertas traseras y software espía en el blob binario.
En caso de errores, incompatibilidades o vulnerabilidades, el controlador no puede ser reparado por los desarrolladores de los sistemas.
El vendedor de hardware puede decidir abandonar el soporte para sus dispositivos en cualquier momento.
En algunos casos, fabricantes incluso prohíben distribución de sus blobs binarios, un caso ejemplar es el de equipos Macintosh viejos (ej.:iMac5,2) de sus cámaras iSight, el fabricante prohíbe distribución de su controlador, el que solo es integrado en MacOSX. Como resultado, no se puede instalar una distribución de GNU/Linux y tener la cámara funcionando nada más instalar el sistema operativo, ya que se prohíbe la distribución del controlador, solo el usuario particularmente puede hacer la extracción molesta del driver desde MacOSX, para un uso por supuesto, particular.

Firmware

El firmware no es usualmente considerado un blob binario, sin embargo la Fundación para el Software Libre ha comenzado una campaña para la adopción de firmwares y BIOS abiertos por parte de los fabricantes.

Software de inicialización

Prácticamente todo el mundo utiliza sus computadoras con firmware de inicialización privativos, llenos de blobs, esto representa desventajas, ya mencionadas más arriba, pero al tratarse de un software de bajo nivel (firmware), tiene más desventajas, ya que es el primer software que se inicializa al encender la computadora, también inicializa todos los periféricos, un sistema operativo, y a menudo se le insertan puertas traseras a propósito o contiene errores involuntarios, que pueden ser explotados por los mismos fabricantes, fabricantes terceros, o algunos "hackers malintencionados" (no confundir con palabra "hacker"(persona que ama programar o/y modificar programas), ya que a menudo en los medios de comunicación llaman a los "piratas" o "hackers malintencionados" como simplemente "hackers"). Los fabricantes responsables de programar software de inicialización, a menudo dejan de dar soporte muy rápido (sacar actualización o/y introducir, o/y mejorar características). Todos estos fabricantes se niegan a dar código fuente de sus programas, por lo tanto a cualquier usuario le resulta "prácticamente" imposible: corregir errores, revisar vulnerabilidades, revisar calidad de código fuente, reducir o incrementar tamaño del software (este último es importante cuando se quiera sustituir chip SPI flash (el que contiene el firmware de inicialización con todas sus regiones) por uno de mayor tamaño (ej.:16MiB), y escribir ceros para rellenar el espacio, y posteriormente flashear el ROM compilado)...Esto último, en un futuro no lejano (y en versiones estables), podría dar la implementación de ejecutar un sistema operativo entero (ej.:GNU con Linux) desde chip SPI. Solo las personas especializadas y las más talentosas podrían pensar en practicar ingeniería inversa a un software de inicialización, probablemente perdiendo mucho tiempo, ya que aportarían poco, dado la cantidad inmensa de hardware que existe en el mundo de segunda mano y nuevo, probablemente la mejora seria solo para un equipo específico.

Aunque Google (criticado por el espionaje tan masivo y por colaboración con NSA) tiene muy buenos proyectos que dan mucha libertad a los usuarios, y uno de sus proyectos es Coreboot, que viene ya pre-instalado en (todos, algunos o muchos) sus Chromebooks. Si bien, da mucha libertad a sus usuarios, pero ninguno de sus equipos puede ser certificado por Free Software Foundation con su certificación oficial "respects your freedom". Como se puede observar, la lista de hardware que cumple con la certificación, es extremadamente reducida. Coreboot y los Chromebooks no cumplen con la certificación, ya sus sistema operativo, "núcleo" Linux y firmware de inicialización, siguen conteniendo algunos blobs binarios. Los Chromebooks suelen llevar hardware que necesita blobs difícil de reemplazar, como por ejemplo los chips Wifi (en algunos o todos Chromebooks vienen soldados o con conexiones propietarias), muy problemáticos, ya que solo tarjetas Atheros (no todas, ni muy modernas) funcionan sin blobs binarios, y son todo un deseo para el que quiere ejecutar cualquiera de los sistemas operativos que no proporcionen software privativo (software no libre que priva a sus usuarios de sus libertades). En computadoras portátiles son fácilmente sustituibles estas tarjetas wifi, ya que se conectan a un puerto "MiniPCI Express" (PCI_Express), universal en los ordenadores portátiles modernos, pero si se trata de una laptop nueva, probablemente se anule la garantía al haber accedido al interior del equipo. Estas tarjetas son muy fáciles de encontrar en mercados de segunda mano, y suelen ser muy baratas.

Otro problema de los Chromebooks, un problema que para algunas personas no se considera como tal, es el chip gráfico (encargado de mostrar la imagen, gráficos en la pantalla, de aceleración 2d y 3d), el fabricante se niega a dar código fuente o alguna documentación sobre el funcionamiento de su hardware. Por lo tanto, aunque existe un proyecto que practica ingeniería inversa al software de este chip gráfico, el driver de código abierto no consigue aceleración 3d. Los únicos chips gráficos que no requieren ejecutar software privativo (firmwares privativos) para funcionar correctamente, son chips gráficos de Intel (anteriores a Skylake) y Nvidia (anteriores a Maxwell 2g(segunda generación de Maxwell))(Los chips gráficos "Kepler", de Nvidia, funcionan maravillosamente con drivers "Nouveau" (un gran trabajo de unas personas ingeniosas) y estos chips gráficos (Kepler) pueden ser re-clockeados ("reclock" *ver nota)(No confundir con overclock, downclock, underclock...), aunque solo se hace manualmente. Es genial pensar en chips gráficos de la marca AMD, pero sería un error, aunque algunos de sus chips gráficos pueden ejecutar sus drivers open-source con un rendimiento muy considerable, sin embargo todos los chips gráficos ATI/AMD necesitan software privativo para funcionar, un blob de datos necesita ser ejecutado, sin este blob el cualquier chip gráfico ATI/AMD se vuelve prácticamente inusable. Si alguien lo pone en duda, puede comprobarlo corriendo un sistema operativo compuesto solo por software libre, o ejecutando un kernel sin dicho blob. Por lo tanto, si se desea utilizar sistema operativo GNU con Linux en un Chromebook, se recomienda usar un entorno de escritorio como LXDE o XFCE, porque no requieren aceleración 3d.

*-Reclock: poner el chip gráfico y memoria a sus relojes máximos "de fábrica" (nada de overclock) (se recomienda siempre la versión más reciente (pero estable) de "núcleo Linux"("núcleo de Linux": no existe tal cosa)), esto en drivers oficiales de Nvidia se hace automáticamente en el momento de requerir más potencia, como al momento de ejecutar un juego o un juego que requiera gráficos 3d. En el momento de poca o ninguna carga (un pstate de idle), los relojes vuelven al "pstate" más bajo. El reclock con driver Nouveau es capaz de elevar las frecuencias de reloj de memoria y core, tan bien como lo hace el de Nvidia (aunque manualmente), y obtener un rendimiento similar al blob de Nvidia sin ejecutar software privativo. Mucha gente se ha quejado del mal rendimiento de driver Nouveau (tirando la toalla y acabando por instalar software privativo de Nvidia), pero en el momento actual solo Kepler ofrece un reclock manual de core y memoria correctos, los demás chips gráficos de Nvidia, si ejecutan Nouveau, se quedan con un pstate el más bajo, o pstate de idle(reposo). Aunque Maxwell 1g (primera generación de Maxwell), se le ha logrado ya hacer reclock al core, pero sin memoria es de poca utilidad. Códigos de chips gráficos de Nvidia

Una gran ventaja de los Chromebooks, es su procesador, ARM, es muy popular en los dispositivos móviles y de bajo consumo, donde la autonomía es importante, y por su TDP, con lo cual se calientan muy poco y no precisan de disipadores grandes ni de ventiladores. Procesadores de arquitectura ARM poseen importante ventaja al no llevar Microcódigo (Microcode updates, muy bien conocidas en cuanto a Intel), en los Chromebook el sustituto es Circuito integrado. También cabe mencionar que los Chromebooks (todos, muchos o algunos) de fábrica llevan software libre en el EC (también conocido como "controlador empotrado" o "embebido", que principalmente se usa en ordenadores portátiles, y son los responsables de hacer con control y manejo de teclado (interno), apertura y cierre de la tapa, cualquier interruptor, leds indicadores, teclas de acceso rápido, botones, luces de asistencia (si están disponibles)...). El principal problema de Microcodigo de procesadores Intel, es que nadie puede saber (Excepto Intel) que hace además de lo que se supone que hace, el usuario está abandonado ante los pies de Intel (AMD tiene sistemas homólogos). El problema viene con el gran riesgo en cuanto a privacidad y seguridad con sistemas de administración remota de Intel, bien conocidos como Intel Active Management Technology (para ver las posibilidades oficiales que tiene, ver párrafo "Features"). También, a partir de las series "i" de Intel (a partir de 2010), junto al mismo procesador y chip gráfico, en el mismo cilicio integra otro procesador (considerado uno de los rootkits más sofisticados, que deja en ridículo cualquier rootkit conocido en cuanto al software malévolo).

En internet se puede encontrar muchísima más información sobre el procesador secundario de Intel, basta poner palabras clave en su buscador favorito como: "Intel ME backdoor", "Intel ME", "Intel ME rootkit", "Intel ME privacy", "Intel ME surveillance", "Intel vpro backdoor", "Intel ME Security"...

Para solucionar la mayoría de los problemas expuestos arriba, existe un firmware de inicialización muy estricto, que no permite integración de ningún tipo de blob binario, se llama Libreboot, este proyecto está compuesto por Software Libre (no confundir con la iniciativa Open-Source), y forma parte del Proyecto GNU desde 14 de mayo de 2014.

Se sabe que Libreboot procede de Coreboot, y se considera distribución de Coreboot. Libreboot es la versión estable de Coreboot.

Libreboot es un reemplazo de BIOS, firmwares de inicialización propietarios, EFI o UEFI privativos. Libreboot es un firmware de inicialización que inicializa el hardware, carga el bootloader para seleccionar y cargar un sistema operativo. También es una BIOS de código abierto, pero no se identifica con el movimiento Open-Source del Coreboot. Se exige mencionar que Libreboot es software libre. La primera computadora en soportar este software es una Thinkpad x60 (por aquel entonces marca registrada de IBM), por desgracia nunca fue distribuida oficialmente con un software de inicialización libre.

Al nacer Libreboot, este no tenía ningún nombre, y principalmente se le llama como "versión deblobeada de Coreboot". Una de las intenciones de Libreboot es hacerlo más fácil de usar, de obtener y compilar que Coreboot. Asegurándose de que absolutamente cualquier usuario obtenga la libertad deseada.

Libreboot tiene unas ventajas enormes frente a una BIOS propietaria:

Recomienda y distribuye solo software libre. Coreboot distribuye ciertas piezas de software privativas, las que son necesarias para hacer funcionar ciertas computadoras. Los ejemplos pueden ser: actualizaciones de microcódigo de CPU, inicialización de memoria, inicialización de vídeo (caso de chips gráficos Nvidia o ATI/AMD)... El proyecto Coreboot a menudo recomienda añadir más software privativo el que el mismo proyecto no distribuye, como blobs de inicialización de vídeo o peor aun "Intel Management Engine". Sin embargo, muchos dedicados y talentosos sujetos en Coreboot trabajan muy duro para reemplazar los blobs cuando sea posible.
Soportar tanto hardware como sea posible. Libreboot soporta menos hardware que Coreboot, porque la mayoría de equipos todavía necesitan ciertos componentes compuestos por software privativo para funcionar correctamente. Libreboot intenta a soportar tanto hardware como sea posible, pero sin ningún componente compuesto de software propietario.
Hacer Coreboot mas amigable para el usuario y facilidad para usarlo. Coreboot es notoriamente más difícil de hacer funcionar, dado por poca documentación y soporte enfocados hacia el usuario final. Mucha gente simplemente se rendirá antes de instalar Coreboot.
Libreboot intenta superar este defecto, asegurándose que cada cosa desde compilación hasta la instalación es automatizada, tan factible como sea posible. El proyecto produce documentación enfocada hacia usuarios no especializados. También intenta proveer del mejor soporte a través de listas de correos electrónicos oficiales, de participantes, o de desarrolladores, también se puede contactar fácilmente a través de canal IRC (#libreboot) para obtener ayuda.
Libreboot ya viene con Payload, en este caso "GRUB", flashrom (programa para leer y escribir firmware de los chips) y otras utilidades. Todo está integrado. Sino, de otro modo, la mayoría de los pasos serían complicados, todo esta hecho para el usuario con antelación.
El usuario puede bajarse imágenes ROM (Libreboot ya compilado y listo para ser instalado) e instalarlas, sin tener que ponerse a compilar ningún código fuente. Pero si por cualquier razón personal, el usuario desea compilar desde código fuente, el sistema de compilado es totalmente automática, el usuario puede compilar el código fuente fácilmente si lo desea, por la razón que sea.
Libreboot tiene muchas ventajas sobre firmware de inicialización propietarios, como tiempo de inicio más rápidos y mayor seguridad. Puedes instalar una distribución de GNU+Linux con "/boot/" encriptado, verificación por firmas GPG en tu núcleo, escribir el núcleo en tu chip flash SPI, y más...
Hackeable(modificable) y personalizable. Tu eres el dueño te tu hardware y software, siéntete libre en modificar el código fuente. Cambia el payload, el fondo de inicio, letra, quita funciones o añade nuevas, revisa calidad y seguridad del código fuente... y comparte los cambios con los demás. Nadie es quien, para decidir como usar lo que te pertenece.
Participación en el proyecto. Cuanta más gente, más potente se hace el proyecto. Libreboot está compuesto por voluntarios, y gente que ya participa en otros proyectos. Cualquier persona que tenga el mínimo deseo de ayudar, es bienvenida. Si no sabes programar, puedes ayudar en muchas otras cosas. También se busca gente con conocimientos mínimos (que sepan reprogramar/desbrickear los chips flash SPI), para testear las versiones inestables (versiones beta que suelen salir muy frecuentemente).
No excluir hardware ni dejar tirado a nadie. Cada vez que se distribuye una versión (sea beta o estable), se distribuye para todo el hardware compatible existente al mismo tiempo. También recientemente, se precompilan ROMs para chips flash de tamaño no oficial (16MiB), por lo tanto usuarios con hardware modificado no necesitan compilar desde el código fuente, sino pueden proceder directamente a la instalación.
Fácilmente actualizable. Libreboot está documentado, basta leer detenidamente, todo es fácilmente accesible, no hay infinidad de información perdida por internet, todo esta unificado y simplificado, incluyendo explicaciones gráficas, y en un futuro, con vídeos como ejemplo. A contrario de firmwares de inicialización privativos, Libreboot no tiene esposas digitales (DRM), no restringe en nada al que lo usa, el usuario puede decidir que versión usar, basta ejecutar un comando para actualizar (update) a o retroceder (downgrade), si alguien no se siente cómodo con nueva versión, es libre de usar las versiones anteriores. También cabe mencionar, que una vez instalado el Libreboot, se quitan las esposas digitales impuestas por el fabricante contra la escritura, cediendo así al propietario del hardware su derecho a tener el control sobre su propiedad, pudiéndose así actualizar o retroceder la versión que ejecuta su máquina. Más tarde el usuario puede proteger contra la escritura su chip flash, pero la desventaja que trae, es que para escribir una versión diferente a la ya instalada, hará falta un dispositivo de programación externa. La protección contra la escritura, imposibilita hacer cualquier cambio en la ROM ya flasheada en el chip, no pudiéndose actualizar o retroceder versión a través de software.
Rapidez en tomar medidas. Cuando hay un fallo, incompatibilidad, inestabilidad, brecha de seguridad... Nada más saberlo, los participantes del proyecto y los desarrolladores actúan al instante (principalmente los usuarios de una versión estable no tienen mucho de qué preocuparse). En cambio los fabricantes de BIOS privativas, se muestran muy vagos (corrigen errores "si quieren" y con lentitud, tampoco proporcionan código fuente, ni siquiera la documentación de como funciona)(tampoco dan actualizadores de sus firmwares para otros sistemas operativos que no sean Microsoft Windows(y solo unas pocas versiones compatibles), imposibilitando al usuario de actualizar si este decide elegir usar otro sistema operativo diferente), a parte, tras una cierta antigüedad del hardware, dejan de dar soporte, estancándose en una versión para siempre, dejándole al usuario en manos de la suerte. En parte, esto último es una parte de Obsolescencia programada.

Datos: Q763151