Solo – un cargador .so para binarios estáticos de Linux

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo proyecto, Solo, incorpora su propio cargador ELF en binarios Linux enlazados estáticamente para que puedan hacer `dlopen()` de controladores de GPU y otros controladores solo para glibc del host incluso cuando están compilados contra musl. Los comentaristas sopesan el atractivo de binarios portables, en su mayor parte estáticos, frente a los riesgos de reimplementar partes de la ABI de glibc y la semántica del cargador, advirtiendo sobre la compatibilidad futura, la seguridad y la fragilidad del comportamiento no documentado. El hilo se amplía hacia una crítica del fragmentado panorama de la ABI de espacio de usuario y del empaquetado en Linux, contraponiendo contenedores, AppImage y estrategias de “compilar contra una glibc antigua” con ideas más radicales como un espacio de usuario freestanding, sin libc.

Propósito y enfoque del proyecto

  • Solo busca permitir que binarios Linux totalmente estáticos enlazados con musl carguen dinámicamente controladores .so proporcionados por el host (en particular, controladores de GPU compilados contra glibc) mediante la incorporación de:
    • Un cargador ELF personalizado (x86‑64, aarch64).
    • Un “puente de ABI de glibc” que adapta símbolos de glibc sobre musl.
  • El objetivo son binarios portables que se ejecuten sin modificaciones en distribuciones con glibc, distribuciones con musl (p. ej. Alpine) y, eventualmente, Android/bionic, manteniendo la sensación de ser “estáticos” desde la perspectiva de la aplicación.

Preocupaciones de seguridad y corrección

  • Varios comentarios advierten que implementar un cargador ELF personalizado y un adaptador de ABI es frágil:
    • Cualquier error al mapear y ejecutar código es un posible vector de RCE, especialmente si se usa en contextos privilegiados.
    • La ABI SysV/ELF tiene sutilezas no documentadas (p. ej., AT_SECURE) que son fáciles de implementar mal.
  • El autor responde que:
    • ld.so ya hace un mapeo similar.
    • El proyecto tiene pruebas extensas, 100% de cobertura, y se ejecuta contra ~1000 paquetes de Debian, con planes de fuzzing.

Entrelazado de glibc, musl y la ABI

  • Larga discusión sobre que en Linux:
    • ld.so, libc.so, libstdc++, TLS, átomos, unwinding y los globals de C++ están profundamente entrelazados y en parte no documentados.
    • Las bibliotecas compartidas compiladas para glibc dependen efectivamente de esa glibc exacta junto con su cargador.
  • Algunos sostienen que este diseño convierte a las libc alternativas (musl, bionic) en opciones de segunda clase y obliga a trucos como Solo.
  • Otros responden que, para C, la ABI es en gran medida estable y glibc suele mantener compatibilidad hacia atrás, especialmente si compilas contra una glibc antigua.

Enlace estático frente a dinámico y distribución

  • Bando pro-estático:
    • Quiere binarios totalmente autocontenidos, desconfía de glibc y de la inestabilidad de las distribuciones, y prefiere C/Rust sin dependencias o syscalls directas.
    • Señala problemas con controladores propietarios o solo para glibc, GPU, NSS, Mesa, etc. en sistemas musl.
  • Bando escéptico:
    • Argumenta que Solo introduce riesgos de compatibilidad futura: controladores futuros podrían requerir símbolos de glibc nuevos o versionados que el puente embebido no soporte.
    • Sugiere enfoques más simples: enlazar dinámicamente contra una glibc antigua, usar contenedores (Docker/Flatpak), o baselines estilo AppImage/manylinux.

¿Es un problema de nicho?

  • Algunos dicen que esto solo importa para distribuciones basadas en musl o controladores propietarios; la mayoría de las distros están bien con el enlace dinámico estándar.
  • Otros insisten en que es un dolor real para desarrolladores pequeños e independientes que no pueden compilar/empaquetar por distribución, pero quieren binarios únicos que “simplemente funcionen” en glibc, musl y Android.

Código y documentación generados por LLM

  • El autor usa abiertamente LLMs para el código y la documentación y lo defiende como una forma de alta productividad, con revisión humana.
  • Algunos lectores desconfían mucho de los README escritos por LLM, los perciben como “slop” y los asocian con proyectos de poco esfuerzo.
  • Otros argumentan que el prejuicio estilístico no es lo importante y que la calidad técnica y las pruebas importan más que si el texto “suena” a LLM.