Una delle opzioni di compilazione fornite inizialmente con il kernel 4.19 era la possibilità di decidere, in fase di build dell’immagine del kernel, se questo deve considerare il Random Number Generator (RNG) della CPU affidabile o meno.
Ma perchè questa decisione? Semplice, perchè l’RNG hardware presente nelle CPU di numerosi produttori, come ad esempio AMD, IBM (sulle CPU s390/POWER) ed Intel, è negli ultimi tempi al centro di un forte dibattito.
Si suppone infatti che il chip dedicato alla randomizzazione all’interno dei nostri processori non sia così tanto casuale e che, alla fine dei conti, la possibilità di predeterminare i numeri generati permetta ad enti esterni (NSA, Governo Cinese, etc.) di attaccare vari sistemi.
Even if I were convinced that Intel hadn’t backdoored RDRAND (or an NSA agent backdoored RDRAND for them) such that the NSA had a NOBUS (nobody but us) capability to crack RDRAND generated numbers, if we made a change to unconditionally trust RDRAND, then I didn’t want the upstream kernel developers to have to answer the question, “why are you willing to trust Intel, but you aren’t willing to trust a company owned and controlled by a PLA general?” (Or a company owned and controlled by one of Putin’s Oligarchs, if that makes you feel better.)
Anche se sono convinto che Intel non ha inserito una backdoor nel RDRAND (o che un agente dell’NSA ha inserito una backdoor nel RDRAND per loro) in modo che l’NSA abbia in esclusiva la possibilità di spaccare i numeri generati da esso, se facciamo una modifica per fidarsi incondizionatamente di RDRAND, allora non vorrei che gli sviluppatori del kernel upstream debbano rispondere alla domanda “perchè avete deciso di fidarvi di Intel, ma non volete fidarvi di un’azienda controllata da un generale del PLA?” (o di un’azienda posseduta e controllata da uno degli oligarchi di Putin, se vi fa sentire meglio).
Questo il pensiero di Theodore Ts’o, sviluppatore del kernel Linux, che aggiunge anche:
I’m not sure Linux distro’s will thank us for this. The problem is trusting the CPU manfuacturer can be an emotional / political issue. […] With this patch, we don’t put ourselves in this position — but we do put the Linux distro’s in this position intead.
Non sono sicuro che le distribuzioni Linux ci ringrazieranno per questo. Il problema di fidarsi o meno dei produttori di CPU può essere emotivo / politico. […] Con questa patch, non mettiamo noi in questa posizione (di scelta) — ma mettiamo invece le distribuzioni Linux
Il problema è quindi di chi deve scegliere; gli sviluppatori del kernel forniscono questa libertà di scelta all’utente, ma alla fine la prima scelta a riguardo dovranno farla chi confeziona e distribuisce le distribuzioni, integrando alla loro offerta “tecnica” quella che può essere vista dagli utenti come una posizione “politica“.
Fortunatamente il passo successivo all’integrazione di questa patch è stato quello di modificare la stessa per fare si di rendere l’opzione definibile solo in fase di compilazione, selezionabile invece in fase di boot tramite l’uso di una semplice opzione (per completezza, si tratta di random.trust_cpu). Nel caso quest’opzione non venisse definita, si utilizzerebbe la scelta fatta da chi ha rilasciato la specifica build del kernel che utilizziamo.
Questo sicuramente rende più semplice la scelta finale dell’utente, anche se non risolve totalmente il discorso politico/emotivo a cui accenna Ts’o.
Alla fine l’importante è avere, senza troppi grattacapi, la possibilità di scelta, ma saremo realmente pilotati da questo nella scelta dell’una o l’altra distribuzione?
Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.
Lascia un commento