Mentre gli sviluppatori ed i manutentori Debian ricevono accesso a un Inference Portal dedicato (conseguenza della General Resolution che ha stabilito la responsabilità umana come principio fondante delle contribuzioni “artificiali”), mentre il patron di NVIDIA, dopo aver consigliato ai ragazzi di non studiare la programmazione, spiega a tutti che “il problema dei junior si risolverà in due anni“, c’è chi deve convivere con l’intelligenza artificiale qui ed ora, e sono gli sviluppatori del Kernel Linux.

Tra i crawler AI che mettono in crisi i repository e le 423 CVE pubblicate in una sola volta il carico AI pro capite da gestire nel progetto Linux rende sempre più necessario introdurre ausili per facilitarne il lavoro. Un esempio pratico è quello che racconta Phoronix a proposito di un nuovo “Taint” introdotto nel Kernel, chiamato TAINT_FORCED_BIND.

Prima di proseguire è quindi bene chiarire cosa sia effettivamente un Taint.

Un Taint del Kernel Linux è, in sostanza, un’etichetta che il Kernel può apporre a sé stesso quando si verifica una condizione che potrebbe rendere meno affidabile un bug report o un’analisi successiva. Non significa necessariamente che “il Kernel si è rotto”: significa piuttosto che è successo qualcosa di particolare e che, da quel momento in poi, chi analizza un eventuale problema deve tenere conto di quella circostanza.

Queste informazioni finiscono nel cosiddetto Tainted Kernel State, visibile anche attraverso /proc/sys/kernel/tainted, e vengono utilizzate dagli sviluppatori per capire se un crash o un comportamento anomalo è avvenuto in un ambiente non completamente “pulito”. Un Kernel può, per esempio, risultare tainted perché è stato caricato un modulo proprietario, perché è stato rilevato un problema hardware o perché è stata utilizzata una funzionalità pensata esplicitamente per il debugging.

Ad esempio, sul mio laptop all’interno di /proc/sys/kernel/tainted ho 12865 che significa come il mio sistema abbia ben cinque Taint attivi: 12865 = 8192 + 4096 + 512 + 64 + 1, ciascuna delle quali ha un suo preciso significato:

Valore	Bit	Significato
1	0	È stato caricato un modulo proprietario (proprietary module)
64	6	Un’applicazione userspace ha richiesto il taint
512	9	Il Kernel ha generato un warning
4096	12	È stato caricato un modulo esterno (out-of-tree)
8192	13	È stato caricato un modulo non firmato

Dovrebbe essere chiaro ormai: un taint non è, di per sé, una misura di sicurezza né un meccanismo che impedisce qualcosa: è un metadato sullo stato del Kernel, utile soprattutto quando bisogna interpretare un problema.

Ed eccoci quindi a TAINT_FORCED_BIND che nelle parole di Greg Kroah-Hartman, maintainer della versione stabile del Kernel Linux, si presenta così:

The ability to add and remove devices from a driver through the sysfs “bind” and “unbind” files was created all those decades ago as a way that kernel developers can iterate faster, and provide a debugging way for users to attempt to add a new device to a driver without having to rebuild their kernel.

This api over the years has been abused and recently come under a major fuzzing “attack” through tools like syzbot which decided that it would attempt to just randomly bind any driver to any type of device, causing loads of unneeded errors and pointless kernel patches to be generated by unsuspecting new developers.

La capacità di aggiungere e rimuovere dispositivi da un driver tramite i file “bind” e “unbind” di sysfs è stata creata decenni fa come un modo in cui gli sviluppatori del Kernel possono iterare più velocemente, e fornire un metodo di debug per gli utenti per tentare di aggiungere un nuovo dispositivo a un driver senza dover ricompilare il loro Kernel.
Questa api nel corso degli anni è stata abusata e recentemente è finita sotto un importante “attacco” di fuzzing tramite strumenti come syzbot che ha deciso di tentare di associare casualmente qualsiasi driver a qualsiasi tipo di dispositivo, causando una marea di errori inutili e patch del Kernel senza senso generate da sviluppatori nuovi e ignari.

Tralasciando i tecnicismi, il problema, in fondo, è semplice: gli strumenti automatici, principalmente AI, utilizzati per mettere alla prova il Kernel sono diventati così aggressivi da poter generare anche errori provocati da situazioni che normalmente non si verificherebbero. E quindi si ritorna al problema ormai antico degli sviluppatori che finiscono per perdere tempo a inseguire problemi che non rappresentano un reale malfunzionamento del Kernel.

Il nuovo Taint serve quindi a lasciare un’etichetta sul Kernel quando un errore è stato provocato da un’associazione forzata tra un dispositivo e un driver. In questo modo, quando arriva una segnalazione, chi dovrà analizzarla sa subito che c’è un’informazione importante da considerare: quel problema è comparso dopo un’operazione anomala, effettuata intenzionalmente per mettere alla prova il Kernel.

Ed è forse questo il dettaglio più interessante dell’intera storia: TAINT_FORCED_BIND non nasce perché qualcuno ha deciso di aggiungere una nuova funzionalità al Kernel, ma perché l’automazione ha iniziato a produrre troppo rumore per gli esseri umani che devono occuparsene.

L’intelligenza artificiale, o più in generale l’automazione basata su tecniche di AI, sta quindi cambiando il lavoro degli sviluppatori del Kernel anche in un modo piuttosto curioso: non soltanto aiutandoli a scrivere o analizzare codice, ma costringendoli a modificare il Kernel stesso per riuscire a gestire meglio la quantità di problemi che gli strumenti automatici sono capaci di generare.

In altre parole, mentre discutiamo di quanto l’AI possa sostituire gli sviluppatori, nel Kernel Linux siamo già arrivati al punto in cui sono gli sviluppatori a dover modificare il Kernel per riuscire a convivere con l’AI.