VLOG 308: Il bug Unix del 2038 #OperazioneNostalgia

Nello scorso episodio vi ho parlato del «Millennium Bug»
Bene, molti di voi - sicuramente - avranno anche pensato:

“Vabbè, ma… io per fortuna utilizzo Linux, che è basato su un sistema Unix, che è un sistema molto più stabile, che non ha questa categoria di problemi come il Millennium Bug: qui le cose sono decisamente molto più affidabili, come tutti i sistemi Unix, che sono affidabilissimi sin dagli anni '70, giusto?”

Beh… quasi!
Perché se la volta scorsa abbiamo parlato del Millennium Bug, adesso mi sembra il caso di parlare dell'Edizione Unix del Millennium Bug, ossia del bug del 2038: ecco un piccolo problema che non molti conoscono, ne parliamo oggi, in quest'episodio di Diario di Viaggio on the road #OperazioneNostalgia
[🎵🎶]

Sui sistemi Unix c'è una variabile di sistema, si chiama ‘Epoch’ (come uno dei personaggi del film Matrix, per vostra curiosità).
Questa variabile semplicemente misura il numero di secondi che sono trascorsi dalla mezzanotte del 1 gennaio 1970.
È una variabile molto importante per il sistema, non solo per la misurazione della data e dell'ora, ma soprattutto perché viene utilizzata per tutta una serie di fattori nei quali c'è bisogno di poter generare un «numero pseudocasuale»: quando c'è bisogno che il sistema «s'inventi un numero» per poterlo utilizzare per la generazione di certificati di sicurezza, per poterlo utilizzare per la generazione di uuid, per la generazione di valori che debbano essere il più possibile «casuali», si parte - soprattutto - dalla numerazione che viene generata dalla variabile Epoch.
E, come dicevo, il problema della variabile Epoch è che misura il numero di secondi che sono trascorsi dal 1 gennaio 1970 al momento attuale.
E misurare una cosa in secondi - naturalmente - richiede una variabile piuttosto "corposa": infatti si usa un signed long int.
In time.h c'è un signed long int che viene utilizzato per contenere questa varabile che è un intero a 32bit.
Essendo "signed" può assumere una serie di valori (il valore massimo non me lo ricordo a memoria, quindi ve lo scrivo qua a schermo) e, superato questo valore massimo, passerà quindi, automaticamente, al valore negativo (perché l'ultimo bit, una volta settato, è il "segno"), e il valore negativo… è un problema per quanto concerne i valori delle date, perché naturalmente se il numero di secondi passato dal 1 gennaio 1970 diventa negativo, a questo punto l'orologio non va più avanti nel tempo, ma comincerà ad andare indietro nel tempo!
Ecco di nuovo un problema molto simile a quello del Millennium Bug: nel momento in cui "finisce" il valore massimo del signed long int, partiamo… abbiamo l'overflow, partiamo dal valore negativo e ci troviamo a partire da una data che si trova molto indietro nel tempo.

–Vabbè: ma il valore massimo di secondi è un numero molto, molto elevato! Quand'è che arriveremo a questo long int? Quand'è che arriveremo "in fondo" a questo valore massimo positivo?

In realtà non molto avanti nel tempo, perché ci arriveremo alle 3:14:07 del 19 gennaio 2038, cioè - tendenzialmente - tra… diciotto anni!
E che cosa succederà in quel momento?
In quel momento (alle 3:14:07), il "secondo successivo" salteremo al valore negativo, e quindi la data passerà alle 20:45:52 del 13 dicembre 1901, e questo provocherà una sfilza di situazioni più che imbrazzanti, soprattutto se si dovesse andare a calcolare la data di un file, se ci fossero delle procedure che - per esempio - cancellano i file log più vecchi di un mese: improvvisamente verrebbero CASSATI VIA TUTTI I LOG, perché si troverebbero essere più vecchi di un centinaio di anni.
Questo per fare l'esempio più spicciolo, ma naturalmente ci sono moltissimi altri problemi legati a questa situazione.
Purtroppo il problema è che la soluzione - al momento (in questa architettura, che abbiamo a disposizione in questo momento) - è quello di non utilizzare più un signed long int, ma di utilizzare un signed long long int (ossia il cosiddetto signed big int), che è una variabile intera, sempre signed (quindi con valori positivi e negativi), ma che non è più a 32 bit, bensì a 64 bit, il cui valore massimo che può essere misurato, rispetto al 1 gennaio 1970, è avanti di non so quanti MILIARDI di anni: praticamente finirà prima l'universo che il contenuto di questa variabile (tanto che si parlava di cominciare a utilizzare questa variabile non tanto per misurare i secondi passati dal 1 gennaio 1970, ma di cominciarla a utilizzare per misurare i MILLISECONDI passati: lascerebbe - comunque - sempre centinaia di migliaia di anni di "spazio di manovra", ma permetterebbe di avere anche dei valori pseudocasuali mooolto più pseudocasuali di prima.
Naturalmente ecco subito che uno pensa:

“Vabbè la soluzione è immediata: si va nella libreria time.h, si cambia questo signed long int con un signed long long int (con un signed big int)”

E invece no: non è così semplice come sembra, perché naturalmente ci sono centinaia di programmi, di librerie, di oggetti, di overlay, di moduli, di demoni, di QualsiasiAltraCosa™ che partono dal presupposto che in time.h la variabile Epoch sia un signed long int (punto primo).
Punto secondo: c'è un altro problema, il bigint è una variabile a 64 bit, che non si può creare se l'architettura è a 32bit: non c'è lo spazio fisico sull'architettura per memorizzare la variabile.
Quindi la situazione potrebbe sembrare meno complessa di quanto sembri, ma è molto più complessa di quanto sembri, perché diciott'anni son lì, dietro l'angolo; il duemila, il Millennium Bug, è passato, adesso ci manca poco ad altri diciotto anni e arriviamo anche a questo problema.
Certo: nel corso del tempo, piano piano, siamo arrivati già a cominciare a modificare, a utilizzare variabili a 64bit, a utilizzare questo signed big int; nel corso del tempo le cose sono migliorate, ma ci sono ancora tutta una serie di strumentazioni che lavorano ancora a 32bit: soprattutto moltissime strumentazioni un pochino più «parche» a livello di risorse, e uno pensa:

“Vabbè insomma: questo è un problema dei sistemi Unix… Come influisce l'utente "normale"? Negli anni '70 i sistemi Unix erano grandi sistemi dipartimentali”

Sì, negli anni '70 sì, ma negli anni 2000, soprattutto nell'anno 2020 Unix è un po' «Tutto Intorno a Noi»:

• Android ha il cuore in un kernel Unix
• Mac OS X ha il cuore in un sistema BSD Unix
• Linux ha il cuore in un sistema Unix
• Tantissime situazioni e tantissime apparecchiature hanno un cuore Unix.

Addirittura, quando si cominciò a dover «litigare» con la storia del Millennium Bug, cominciarono a nascere dei componenti hardware che erano "Y2K compliaint" (già pronti all'ambito del 2000), moltissimi di questi erano componenti hardware che utilizzavano versioni embedded di Linux: per esempio c'erano dei router, degli switch di rete "managed", delle attrezzature di rete molto importanti… che operano a 32bit, perché sono componenti di rete che devono svolgere ben pochissimi compiti, quindi devono svolgere quelle quattro funzioni e non c'è bisogno di un grosso hardware, quindi utilizzano hardware a 32bit.
E questi sono componenti che sono tuttora attivi ed essendo componenti che svolgono solo una funzione, quindi la svolgono molto bene e non hanno bisogno di  grossi aggiornamenti… eh! Potrebbero venire coinvolti in questo grosso problema: potrebbero andare completamente in blocco perché c'è l'overflow della variabile Epoch.
Che cosa ci ha insegnato il Millennium Bug? Che cosa ci insegna il bug del 2038 dei sistemi Unix? Che non bisogna MAI pensare, quando si progetta qualcosa:

“Vabbè ma chi vuoi che usi questa cosa fra 20~30 anni?!”

Bisogna cercare di guardare al futuro e di pensare che, soprattutto considerata l'esperienza del passato, ci sono delle cose che - se devono svolgere un semplice compito - potrebbero svolgere quel semplice compito per molti anni nel futuro e quindi bisogna essere previdenti e mai pensare:

“Vabbè ma questa cosa fra 20~30 anni chi vuoi che la stia ancora utilizzando?”

Bisogna invece avere la capacità di dire

“No, va bene: questa potrebbe essere utilizzata fra 20~30 anni. Anche se non viene utilizzata potrebbe evolversi, basandosi anche sulle librerie che ci sono al momento.”

Allora, se pur vero (e l'abbiamo visto nello scorso episodio di #OperazioneNostalgia) che le risorse sono limitate e bisogna usarle con parsimonia, è anche vero che le risorse bisogna anche utlizzarle con intelligenza, e se c'è la possibilità - su un hardware a 64bit - di avere a disposizione una risorsa che può crescere nel tempo, e quindi può essere utile avere questa risorsa a disposizione a 64bit già in partenza… magari - FORSE - è il caso di farlo, anziché dire

“No, vabbè: la usiamo a 32bit, che occupa meno memoria, che occupa meno architettura”

perché comunque quella risorsa può crescere, bisogna fare una corretta progettazione dei sistemi informatici: questo è quello che abbiamo imparato dal Millennium Bug, dal bug di Epoch dei sistemi Unix, e chissà che nel futuro non saltino fuori altri problemi del genere…
Insomma non siamo al sicuro dalle macchine: i film di fantascienza avevano ragione! 😱
Scherzi a parte, conoscevate questo bug del contatore Epoch dei sistemi Unix? Conoscevate il Millennium Bug?
Conoscevate un po' queste situazioni che possono provocare dei fallimenti catastrofici nei sistemi informatici? Parliamone: nei commenti qua sotto, oppure su Twitter con l'hashtag #DdVotr
Bene: io sono Grizzly, questo era #OperazioneNostalgia
Come sempre vi invito a mettere pollice-in-alto, condividere questo vlog, iscrivetevi al canale: noi ci vediamo alla prossima puntata, ciao a tutti!