Kernel-Echte Foutinjectie: Een C99 LD_PRELOAD Chaos-bibliotheek voor Elk Proces

Foutinjectiebibliotheken vallen uiteen in twee brede kampen. Het eerste kamp mockt op de applicatielaag: een repository mocken, een HTTP-client mocken, een uitzondering teruggeven. Overzichtelijk. Snel. En volledig losgekoppeld van wat de echte operationele omgeving doet wanneer die degradeert.

Het tweede kamp grijpt naar infrastructuurtools: Toxiproxy voor TCP-proxykopieën, tc netem voor pakketvormgeving op kernelniveau, Pumba of Chaos Monkey voor het uitschakelen van containers. Krachtig, maar ze vereisen externe opzet, botsen met testisolatie en draaien vaak in een apart proces waarvan de applicatie geen weet kan hebben.

Beide kampen missen iets: de libc-grens. De laag waar uw applicatie, ongeacht taal of runtime, overdraagt aan het besturingssysteem. Waar `read()` daadwerkelijk plaatsvindt. Waar `getaddrinfo()` namen omzet. Waar `mmap()` geheugen alloceert. Waar `clock_gettime()` de tijd retourneert.

Als u hier onderschept, onderschept u alles. En als de fouten die u op deze laag injecteert niet te onderscheiden zijn van de fouten die de kernel produceert — omdat ze dezelfde errno-codes gebruiken, dezelfde retourwaardeconventies, dezelfde timingkenmerken — dan is wat u heeft gebouwd geen mock. Het is een simulatie. Een kernel-echte simulatie.

LD_PRELOAD is een functie van de Linux dynamische linker die gedeelde objecten in de linkmap van een proces invoegt vóór elke andere bibliotheek — inclusief libc. Wanneer een applicatie `connect()` aanroept, doorloopt de symboolresolutie van de dynamische linker de linkmap in volgorde. Als een vooraf geladen bibliotheek een symbool met de naam `connect` exporteert, wint dat symbool.

Dit geeft ons interpositie: de mogelijkheid om elke libc-functie te omhullen zonder de aanroepende code te wijzigen of opnieuw te compileren. En het is beschikbaar sinds voordat de meeste huidige productiesystemen werden ontworpen.

De belangrijkste eigenschappen die dit de juiste laag maken:

**Taalonafhankelijke universaliteit.** Python's `socket.connect()` loopt via glibc. Node.js's `net.connect()` loopt via glibc. Java's `Socket.connect()` — via JNI — loopt via glibc. Een enkele vooraf geladen bibliotheek onderschept ze allemaal.

**Kernel-echte fouten.** We retourneren echte errno-waarden. De aanroepende code kan een echte ECONNREFUSED niet onderscheiden van onze geïnjecteerde ECONNREFUSED. De circuitonderbreker ziet een echte storing, geen testbewuste gesimuleerde.

**Nul applicatiewijzigingen.** Geen agents. Geen API-imports. Geen testframework-integratie vereist op applicatieniveau. De applicatie draait normaal; de fouten verschijnen eronder.

**Procesbereik.** Fouten zijn beperkt tot een enkel proces. Voer uw testproces uit met één set fouten; voer uw afhankelijkheid uit in een aparte container zonder fouten. Geen kruisbesmetting.

De bibliotheekset dekt zes onafhankelijke foutdomeinen, elk als een apart gedeeld object. Ze kunnen afzonderlijk worden geladen of worden samengesteld — de samenstelling is veilig omdat elke bibliotheek een disjuncte set symbolen bezit (het Symboolbezitstheorema, gedetailleerd gedocumenteerd in de architectuurdocumentatie).

Het mechanisme is eenvoudig in principe, zorgvuldig in uitvoering.

**Stap 1 — Bibliotheekinitialisatie.** Wanneer het vooraf geladen `.so` wordt geladen, wordt de constructor uitgevoerd. Het roept `dlsym(RTLD_NEXT, "connect")` aan om de echte libc `connect` te vinden. RTLD_NEXT slaat de aanroepende DSO in de linkmap over en retourneert het volgende overeenkomende symbool — de echte libc-implementatie. Deze aanwijzer wordt gecached in een statische variabele. Geen per-aanroep dlsym in het hot path.

**Stap 2 — Aanroeponderbreking.** Wanneer de applicatie `connect()` aanroept, vindt de dynamische linker eerst ons symbool (linkmapvolgorde). Onze wrapper wordt uitgevoerd: het leest het configuratiebestand (of een gecachede momentopname), evalueert of een fout moet worden geactiveerd op basis van de eindpuntselector en kans, en injecteert de fout of roept de echte libc-functie aan via de gecachede aanwijzer.

**Stap 3 — Symboolbezitsinvariant.** Als twee vooraf geladen bibliotheken beide `read()` proberen te omhullen, zal één van hen RTLD_NEXT krijgen dat naar de andere wijst, wat dubbele injectie veroorzaakt. We voorkomen dit met strikte symbooloewijzing: elk libc-symbool wordt eigendom van precies één bibliotheek in de set. `libchaos-net.so` bezit `read()` niet — I/O-symbolen behoren toe aan `libchaos-io.so`. De bibliotheken zijn veilig samen te stellen omdat ze daarvoor zijn ontworpen.

Er is geen API. Er is geen publieke header. Er is geen bibliotheek om tegen te linken. De volledige interface is een plat tekstconfiguratiebestand.

Dit was een bewuste keuze. Een configuratiebestand kan worden geschreven door een shellscript, een CI-taak, een testharnas in elke taal, of een mens in een terminal. Het vereist geen integratie met het bouwsysteem. Het kan worden verwisseld terwijl het proces actief is. Het kan worden versiebeheerd naast testdata. En het creëert nul koppeling tussen de chaos-bibliotheek en de te testen applicatie.

De configuratiesyntaxis is `selector:operation:effect:value:probability`. Een paar representatieve voorbeelden:

Een van de minder voor de hand liggende technische uitdagingen is het herladen van de configuratie terwijl een multi-threaded proces actief is. De naïeve aanpak — het bestand bij elke aanroep lezen — is te duur. De naïeve vergrendelingsgebaseerde aanpak — een mutex vasthouden tijdens het bijwerken van de configuratiemomentopname — blokkeert elke onderschepte systeemaanroep tijdens het herladen.

We gebruiken een vergrendelingsvrije aanpak gebaseerd op atomaire vergelijking-en-verwisseling:

**Twee momentopnamebuffers.** Eén is actief; de andere is beschikbaar voor schrijven. Een 64-bit atomaire sleuf bevat de mtime van de momenteel actieve configuratie.

**Herlaadwinnaardetectie.** Elke onderbreking controleert de mtime van het configuratiebestand ten opzichte van de gecachede waarde. Bij een verschil wint één thread de CAS-race om te beginnen met herladen. Verliezers zien de RELOADING-toestand en wachten kort.

**Atomaire omschakeling.** De winnaar schrijft de nieuwe configuratie naar de inactieve buffer en wisselt vervolgens atomair de actieve index. Vanaf dit punt zien alle threads de nieuwe configuratie. De oude buffer is beschikbaar voor de volgende herlaadcyclus.

Het herlaadvenster is typisch minder dan 15 microseconden. Lezers worden nooit geblokkeerd door schrijvers in de stationaire toestand. Dit maakt het praktisch om foutpercentages te wijzigen tussen testmethoden zonder het proces opnieuw te starten.

Integratie in een CI-pipeline is bewust minimaal gehouden. Vooraf gecompileerde binaire bestanden voor vier platformcombinaties (glibc/musl × amd64/arm64) zijn beschikbaar. Geen bouwstap nodig — download het juiste binaire bestand voor het besturingssysteem en de architectuur van uw CI-runner, schrijf een configuratiebestand en stel LD_PRELOAD in.

Multi-threaded correctheid wordt afgedwongen via thread-lokale opslag in plaats van vergrendelingen waar mogelijk.

**PRNG per thread.** Elke thread heeft zijn eigen toestand voor de generator van willekeurige getallen. Foutsequenties zijn onafhankelijk per thread — geen globale willekeurigheidsknelpunt, geen contentie op gedeelde toestand. Dit betekent ook dat foutsequenties deterministisch per thread zijn bij hetzelfde zaad, wat van belang is voor het reproduceren van testfouten.

**Recursiewachter.** Wanneer de chaoscode libc-internals aanroept (stat om mtime te controleren, read om het configuratiebestand te lezen), zouden die aanroepen zelf worden onderschept, wat oneindige recursie veroorzaakt. Een `__thread int guard`-variabele voorkomt dit: als de recursidiepte niet nul is, roepen we onmiddellijk door naar de echte functie.

**FD-naar-pad-cache.** De onderschepper voor bestands-I/O moet een bestandsdescriptor koppelen aan een pad (voor het matchen van padprefixregels). Het lezen van `/proc/self/fd/<fd>` bij elke I/O-aanroep is te duur. We onderhouden een 32-sleuf direct-mapped thread-lokale cache (fd % 32) die wordt gevuld bij `open()` en ongeldig gemaakt bij `close()`. Het cachemispercentage voor echte werklasten is onder de 3%.

We documenteren de beperkingen expliciet in plaats van gebruikers ze te laten ontdekken.

**Kan niet worden onderschept:**

- **Directe systeemaanroepen.** De Go-runtime doet systeemaanroepen rechtstreeks via het `syscall`-pakket, waarbij libc volledig wordt omzeild. Go-programma's gecompileerd zonder CGO zijn immuun voor LD_PRELOAD-chaos op hun netwerk-I/O. (Java via JNI is prima; JNI loopt via glibc.) - **Statische binaire bestanden.** LD_PRELOAD is een dynamische linkermechanisme. Statische binaire bestanden hebben geen dynamische linker; vooraf laden heeft geen effect. - **Setuid/setgid binaire bestanden.** De kernel verwijdert LD_PRELOAD voor setuid-binaire bestanden (AT_SECURE-semantiek). Dit is een beveiligingsfunctie waarop we terecht vertrouwen. - **vDSO fast-path klokken.** Sommige clock_gettime-aanroepen lopen via de vDSO, niet glibc. Onze tijdbibliotheek onderschept op het niveau van de glibc-wrapper, die stroomafwaarts van de vDSO zit. In de praktijk betekent dit dat de fout wordt geactiveerd op de glibc-aanroep vóór de vDSO-opzoekactie — het netto-effect is hetzelfde, maar de interne klok van de kernel wordt niet beïnvloed.

**Kan worden onderschept:** - Elk dynamisch gelinkt proces op Linux (glibc of musl) - Java via JNI — inclusief alle socket-, bestands-, DNS- en tijdaanroepen in de JDK - Python, Node.js, Ruby, PHP — gebruiken allemaal glibc voor systeem-I/O - Rust-binaire bestanden die std gebruiken (wat glibc gebruikt) of CGO-overbrugde C-bibliotheken

We meten doorgaande overhead met rdtsc-geserialiseerde microbenchmarks om worst-case cijfers te verkrijgen. Het hot path voor een doorgaande aanroep (geen fout geconfigureerd):

- **Configuratiecache-treffer (geen herlaad nodig):** ~20–40 ns overhead boven de werkelijke systeemaanroepkosten. Dit is een mtime-statcontrole (gecached in een atomaire sleuf), een regelscanning (lineair over N regels, typisch N < 16) en een aanroep via de gecachede functieaanwijzer. - **Cachemis (configuratiebestand herladen):** Één stat()-systeemaanroep plus een read() van het configuratiebestand — typisch 150–300 ns totaal, en alleen bij de eerste aanroep na een configuratiewijziging. - **Fout geïnjecteerd:** De foutoverhead zelf (slapen voor LATENCY, errno instellen voor ERRNO) domineert; de wrapperkosten zijn verwaarloosbaar.

Voor een goed geconfigureerde testsuite met een klein aantal regels ligt de doorgaande overhead onder de ruis van een netwerkaanroep. U betaalt tientallen nanoseconden bovenop bewerkingen die microseconden tot milliseconden kosten.