Buongiorno nexiane, con questo messaggio inauguro ufficiosamente la rubrica "Trusting What?!?", dedicata alle segnalazioni e ai commenti in merito a tutto ciò che *pare* studiato appositamente per fornire a qualcuno backdoors direttamente nell'"hardware" dei dispositivi o per consentire attacchi di tipo "Trusting Trust" [1], AFAIK erroneamente comunemente circoscritti alle "sole" compiler backdoors [2]. Molti di voi in questa lista sanno bene a cosa mi riferisco, ma per coloro che non hanno questo livello di conoscenza mi permetto di sintetizzare il nocciolo del discorso. Eventuali note e correzioni sono benvenute. La morale della lezione del 1984 di Ken Thompson, documentata nel vol. 27 n. 8 della rivista "Communications of the ACM" dal titolo "Reflections on Trusting Trust" [1], è che la catena che conduce all'esecuzione del codice binario sui nostri dispositivi (cioè come funzionano davvero) è relativamente complessa e che se viene compromesso un anello della catena allora è possibile che l'autore della compromissione sia in grado di accedere al nostro dispositivo, ovviamente compresi tutti i dati che contiene; inoltre, più "vicino" all'hardware è l'anello compromesso, peggiore sarà il livello di compromissione perché tutti gli anelli che "girano sopra" saranno potenzialmente compromessi. Azzardo un elenco di questa catena, partendo dagli strati più "interni": 1. l'elaboratore ed i suoi circuiti accessori (CPU, memoria RAM, bus di comunicazione, ecc.); 2. il microcode della CPU, programmi che traducono le istruzioni macchina (ed altre cose analoghe) in operazioni dettagliate a livello di circuiti logici, quelli dei quali sono fatte le CPU; 3. il software che funziona _sotto_ al kernel, veri e propri sottosistemi incorporati nei microprocessori e che funzionano a livelli di accesso alle risorse (inclusa ovviamente la memorai RAM) _inferiori_ al kernel stesso; 4. il kernel, il nocciolo del sistema operativo che consente alle applicazioni di "colloquiare" con l'hardware, in particolare mi "limiterei" ai "driver" dei dispositivi (WiFi, scheda grafica, stampante, scanner... microscopio elettronico, ecc.); 5. il sistema di build del software (compilatore, linker, ecc. Ovviamente le librerie usate.) 6. il software "user space", quello applicativo: dalla shell di sistema al browser, word processor, ecc. ecc. In questa "rubrica" vorrei saltare a piè pari tutto ciò che fa parte dei livelli 5 e 6 perché la soluzione alla domanda "come mi posso fidare" esiste già e si chiama "bootstrappable builds" [3] e "reproducible builds" [4]: non che sia già tutto risolto, anzi, ma direi che gli strumenti per risolverli ci sono già e si tratta quindi "solo" di applicarli (in qualche caso significa anche completare alcuni interessantissimi progetti, che meriterebbero più risorse). Parlerei piuttosto di come ci possiamo fidare dal kernel in giù, che è un problema del quale ancora _io_ non vedo la soluzione all'orizzonte, o meglio una soluzione alla portata di un'ampia fascia di cittadini. Alla prossima puntata. Saluti, Giovanni P.S.: questo lavoro rappresenta per me una sorta di ricerca propedeutica alla prossima edizione del vol.1 del libro "Cittadinanza digitale e tecnocivismo" (in CC-BY-SA): chi contribuirà con informazioni o commenti interessanti avrà infinita riconoscenza mia, degli altri autori e dei cinque o sei lettori :-) [1] http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf [2] egli disse: «I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode» [3] https://bootstrappable.org/ [4] https://reproducible-builds.org/ -- Giovanni Biscuolo