Injeção de Falhas Real no Kernel: Uma Biblioteca de Caos C99 com LD_PRELOAD para Qualquer Processo

Bibliotecas de injeção de falhas se dividem em dois grandes grupos. O primeiro grupo faz mock na camada da aplicação: mock de repositório, mock de cliente HTTP, retorno de exceção. Limpo. Rápido. E completamente desconectado do que o ambiente operacional real faz quando degrada.

O segundo grupo recorre a ferramentas de infraestrutura: Toxiproxy para falhas de proxy TCP, tc netem para moldagem de pacotes no nível do kernel, Pumba ou Chaos Monkey para matar contêineres. Poderoso, mas requer configuração externa, conflita com o isolamento de testes e frequentemente roda em um processo separado do qual a aplicação não tem conhecimento.

Ambos os grupos ignoram algo: a fronteira da libc. A camada onde sua aplicação, independentemente da linguagem ou runtime, passa o controle para o sistema operacional. Onde `read()` realmente acontece. Onde `getaddrinfo()` resolve nomes. Onde `mmap()` aloca memória. Onde `clock_gettime()` retorna o tempo.

Se você intercepta aqui, você intercepta tudo. E se as falhas que você injeta nessa camada são indistinguíveis das falhas que o kernel produz — porque usam os mesmos códigos errno, as mesmas convenções de valor de retorno, as mesmas características de temporização — então o que você construiu não é um mock. É uma simulação. Uma simulação real ao nível do kernel.

LD_PRELOAD é um recurso do linker dinâmico do Linux que insere objetos compartilhados no link-map de um processo antes de qualquer outra biblioteca — incluindo a libc. Quando uma aplicação chama `connect()`, a resolução de símbolos do linker dinâmico percorre o link-map em ordem. Se uma biblioteca pré-carregada exporta um símbolo chamado `connect`, esse símbolo vence.

Isso nos dá interposição: a capacidade de envolver qualquer função da libc sem modificar o código chamador ou recompilar qualquer coisa. E está disponível desde antes de a maioria dos sistemas de produção atuais terem sido projetados.

As propriedades fundamentais que tornam esta a camada certa:

**Universalidade independente de linguagem.** O `socket.connect()` do Python passa pelo glibc. O `net.connect()` do Node.js passa pelo glibc. O `Socket.connect()` do Java — via JNI — passa pelo glibc. Uma única biblioteca pré-carregada intercepta todos eles.

**Falhas reais do kernel.** Retornamos valores errno reais. O código chamador não consegue distinguir um ECONNREFUSED real do nosso ECONNREFUSED injetado. O circuit breaker vê uma falha real, não uma simulada com consciência de teste.

**Zero alterações na aplicação.** Sem agentes. Sem importações de API. Sem necessidade de integração com framework de testes na camada da aplicação. A aplicação roda normalmente; as falhas aparecem abaixo dela.

**Escopo de processo.** As falhas têm escopo para um único processo. Execute seu processo de teste com um conjunto de falhas; execute sua dependência em um contêiner separado sem nenhuma falha. Sem contaminação cruzada.

O conjunto de bibliotecas cobre seis domínios de falhas independentes, cada um como um objeto compartilhado separado. Eles podem ser carregados individualmente ou compostos — a composição é segura porque cada biblioteca possui um conjunto disjunto de símbolos (o Teorema de Propriedade de Símbolos, documentado em detalhes na documentação de arquitetura).

O mecanismo é simples em princípio, mas cuidadoso na execução.

**Passo 1 — Inicialização da biblioteca.** Quando o `.so` pré-carregado é carregado, seu construtor é executado. Ele chama `dlsym(RTLD_NEXT, "connect")` para encontrar o `connect` real da libc. RTLD_NEXT pula o DSO chamador no link-map e retorna o próximo símbolo correspondente — a implementação real da libc. Esse ponteiro é armazenado em cache em uma variável estática. Sem dlsym por chamada no caminho quente.

**Passo 2 — Interceptação de chamada.** Quando a aplicação chama `connect()`, o linker dinâmico encontra nosso símbolo primeiro (ordem do link-map). Nosso wrapper é executado: ele lê o arquivo de configuração (ou um snapshot em cache), avalia se uma falha deve ser disparada com base no seletor de endpoint e na probabilidade, e então injeta a falha ou passa a chamada para a função real da libc via o ponteiro em cache.

**Passo 3 — Invariante de propriedade de símbolo.** Se duas bibliotecas pré-carregadas tentam ambas envolver `read()`, uma delas receberá RTLD_NEXT apontando para a outra, causando dupla injeção. Evitamos isso com atribuição estrita de símbolos: cada símbolo da libc pertence a exatamente uma biblioteca no conjunto. `libchaos-net.so` não possui `read()` — símbolos de I/O pertencem a `libchaos-io.so`. As bibliotecas se compõem com segurança porque foram projetadas para isso.

Não existe API. Não existe header público. Não existe biblioteca para linkar. A interface inteira é um arquivo de configuração em texto simples.

Issa foi uma escolha deliberada. Um arquivo de configuração pode ser escrito por um script shell, um job de CI, um harness de testes em qualquer linguagem ou um humano no terminal. Não requer integração com sistema de build. Pode ser trocado em quente enquanto o processo está em execução. Pode ser versionado junto com dados de teste. E cria zero acoplamento entre a biblioteca de caos e a aplicação sob teste.

A sintaxe de configuração é `selector:operation:effect:value:probability`. Alguns exemplos representativos:

Um dos desafios de engenharia menos óbvios é a recarga de configuração em quente em um processo multi-thread. A abordagem ingênua — ler o arquivo a cada chamada — é cara demais. A abordagem ingênua baseada em lock — manter um mutex enquanto atualiza o snapshot de configuração — bloqueia cada syscall interceptada durante a recarga.

Usamos uma abordagem lock-free baseada em compare-and-swap atômico:

**Dois buffers de snapshot.** Um está ativo; o outro está disponível para escrita. Um slot atômico de 64 bits armazena o mtime da configuração ativa no momento.

**Detecção do vencedor da recarga.** Cada interceptação verifica o mtime do arquivo de configuração em relação ao valor em cache. Em caso de divergência, uma thread vence a corrida CAS para iniciar a recarga. As perdedoras veem o estado RELOADING e aguardam brevemente.

**Troca atômica.** O vencedor escreve a nova configuração no buffer inativo e, em seguida, troca atomicamente o índice ativo. A partir desse ponto, todas as threads enxergam a nova configuração. O buffer antigo fica disponível para o próximo ciclo de recarga.

A janela de recarga tipicamente fica abaixo de 15 microssegundos. Leitores nunca bloqueiam em escritores no estado estacionário. Isso torna prático alterar taxas de falha entre métodos de teste sem reiniciar o processo.

A integração em um pipeline de CI é intencionalmente mínima. Binários pré-compilados para quatro combinações de plataforma (glibc/musl × amd64/arm64) estão disponíveis. Nenhuma etapa de build é necessária — baixe o binário correto para o OS e a arquitetura do seu runner de CI, escreva um arquivo de configuração e defina LD_PRELOAD.

A corretude multi-thread é garantida por meio de armazenamento thread-local em vez de locks sempre que possível.

**PRNG por thread.** Cada thread tem seu próprio estado de gerador de números aleatórios. As sequências de falhas são independentes por thread — sem gargalo de aleatoriedade global, sem contenção em estado compartilhado. Isso também significa que as sequências de falhas são determinísticas por thread dado o mesmo seed, o que importa para reproduzir falhas de teste.

**Guarda de recursão.** Quando o código de caos chama internals da libc (stat para verificar mtime, read para ler o arquivo de configuração), essas chamadas seriam elas próprias interceptadas, causando recursão infinita. Uma variável `__thread int guard` previne isso: se a profundidade de recursão for diferente de zero, passamos diretamente para a função real.

**Cache FD-para-caminho.** O interceptor de I/O de arquivo precisa mapear um descritor de arquivo para um caminho (para correspondência de regras por prefixo de caminho). Ler `/proc/self/fd/<fd>` a cada chamada de I/O é caro demais. Mantemos um cache thread-local de mapeamento direto com 32 slots (fd % 32), preenchido no `open()` e invalidado no `close()`. A taxa de cache miss para cargas de trabalho reais é inferior a 3%.

Documentamos os limites explicitamente em vez de deixar os usuários descobri-los.

**Não é possível interceptar:**

- **Syscalls diretas.** O runtime do Go emite syscalls diretamente via o pacote `syscall`, contornando completamente a libc. Programas Go compilados sem CGO são imunes ao caos via LD_PRELOAD em seu I/O de rede. (Java via JNI funciona; JNI passa pelo glibc.) - **Binários estáticos.** LD_PRELOAD é um mecanismo do linker dinâmico. Binários estáticos não possuem linker dinâmico; o pré-carregamento não tem efeito. - **Binários setuid/setgid.** O kernel remove LD_PRELOAD para binários setuid (semântica AT_SECURE). Esse é um recurso de segurança no qual dependemos corretamente. - **Clocks com caminho rápido vDSO.** Algumas chamadas de clock_gettime passam pelo vDSO, não pelo glibc. Nossa biblioteca de tempo intercepta no nível do wrapper glibc, que fica downstream do vDSO. Na prática, isso significa que a falha é disparada na chamada glibc antes da consulta vDSO — o efeito líquido é o mesmo, mas o clock interno do kernel não é afetado.

**É possível interceptar:** - Qualquer processo linkado dinamicamente no Linux (glibc ou musl) - Java via JNI — incluindo todas as chamadas de socket, arquivo, DNS e tempo no JDK - Python, Node.js, Ruby, PHP — todos usam glibc para I/O de sistema - Binários Rust que usam std (que usa glibc) ou bibliotecas C com ponte CGO

Medimos o overhead de passthrough com microbenchmarks serializados por rdtsc para obter números de pior caso. O caminho quente para uma chamada de passagem (sem falha configurada):

- **Cache hit de configuração (sem recarga necessária):** ~20–40 ns de overhead além do custo real da syscall. Isso é uma verificação de mtime via stat (em cache em um slot atômico), uma varredura de regras (linear sobre N regras, tipicamente N < 16) e uma chamada pelo ponteiro de função em cache. - **Cache miss (arquivo de configuração recarregado):** Uma syscall stat() mais uma read() do arquivo de configuração — tipicamente 150–300 ns no total, e somente na primeira chamada após uma alteração de configuração. - **Falha injetada:** O overhead da falha em si (dormir para LATENCY, definir errno para ERRNO) domina; o custo do wrapper é desprezível.

Para uma suíte de testes bem configurada com um pequeno número de regras, o overhead de passthrough fica abaixo do nível de ruído de uma chamada de rede. Você paga dezenas de nanossegundos sobre operações que custam microssegundos a milissegundos.