Solo – um carregador .so para binários estáticos Linux

Artigo original ↗ Discussão no Hacker News ↗

Um novo projeto, Solo, incorpora seu próprio carregador ELF em binários Linux estaticamente vinculados para que eles possam usar `dlopen()` em drivers de GPU e outros drivers apenas glibc do host, mesmo quando compilados contra musl. Os comentaristas ponderam o apelo de binários portáveis, em grande parte estáticos, contra os riscos de reimplementar partes da ABI e da semântica do carregador da glibc, alertando para compatibilidade futura, segurança e a fragilidade de comportamento não documentado. O debate se amplia para uma crítica ao ecossistema fragmentado de ABI de user space e à história de empacotamento do Linux, contrastando containers, AppImage e estratégias de “compilar contra uma glibc antiga” com ideias mais radicais como um userland livre de libc e freestanding.

Propósito e abordagem do projeto

  • O Solo pretende permitir que binários Linux totalmente estáticos vinculados a musl carreguem dinamicamente drivers .so fornecidos pelo host (notavelmente drivers de GPU compilados contra glibc) ao incorporar:
    • Um carregador ELF personalizado (x86‑64, aarch64).
    • Uma “ponte ABI da glibc” que faz shim de símbolos da glibc sobre musl.
  • O objetivo é ter binários portáveis que rodem sem modificações em distros glibc, distros musl (por exemplo, Alpine) e, eventualmente, Android/bionic, mantendo ainda a sensação de serem “estáticos” do ponto de vista do aplicativo.

Preocupações com segurança e correção

  • Vários comentários alertam que implementar um carregador ELF personalizado e um shim de ABI é frágil:
    • Qualquer bug no mapeamento e na execução de código é um possível vetor de RCE, especialmente se usado em contextos privilegiados.
    • O ABI SysV/ELF tem sutilezas não documentadas (por exemplo, AT_SECURE) que são fáceis de errar.
  • O autor responde que:
    • O ld.so já faz um mapeamento semelhante.
    • O projeto tem testes extensivos, 100% de cobertura, e é executado contra ~1000 pacotes Debian, com planos de fuzzing.

glibc, musl e o emaranhado de ABI

  • Longa discussão de que, no Linux:
    • ld.so, libc.so, libstdc++, TLS, atomics, unwinding e globais de C++ estão profundamente entrelaçados e em parte não documentados.
    • Bibliotecas compartilhadas compiladas para glibc dependem efetivamente daquela glibc exata mais seu carregador.
  • Alguns argumentam que esse design torna libcs alternativas (musl, bionic) de segunda classe e força gambiarras como o Solo.
  • Outros contrapõem que, para C, o ABI é em grande parte estável e a glibc geralmente mantém compatibilidade retroativa, especialmente se você compilar contra uma glibc mais antiga.

Linkagem estática vs dinâmica e distribuição

  • Campo pró-estático:
    • Quer binários totalmente autossuficientes, desconfia da glibc e da mudança das distros, e gosta de C/Rust sem dependências ou de syscalls diretas.
    • Aponta dores com drivers proprietários/apenas glibc para GPU, NSS, Mesa etc. em sistemas musl.
  • Campo cético:
    • Argumenta que o Solo introduz riscos de compatibilidade futura: drivers futuros podem exigir símbolos da glibc novos ou versionados que o shim embutido não suporte.
    • Sugere abordagens mais simples: linkar dinamicamente contra uma glibc antiga, usar containers (Docker/Flatpak) ou baselines no estilo AppImage/manylinux.

Isso é um problema de nicho?

  • Alguns dizem que isso só importa para distros baseadas em musl ou para drivers proprietários; a maioria das distros fica bem com linkagem dinâmica padrão.
  • Outros insistem que é uma dor real para pequenos desenvolvedores independentes que não conseguem construir/empacotar por distro, mas querem binários únicos que “simplesmente funcionem” em glibc, musl e Android.

Código e documentação gerados por LLM

  • O autor usa abertamente LLMs para código e documentação e defende isso como alta produtividade, com revisão humana.
  • Alguns leitores desconfiam fortemente de READMEs escritos por LLM, percebendo-os como “slop” e associando-os a projetos de baixo esforço.
  • Outros argumentam que preconceito de estilo é deslocado e que qualidade técnica e testes importam mais do que o texto “parecer” de um LLM.