Bug dell'anno 2038
|
Questa voce o sezione sull'argomento sicurezza informatica non cita le fonti necessarie o quelle presenti sono insufficienti.
|
Il bug dell'anno 2038 (in breve: Y2038) è un bug informatico, noto agli esperti, che ha ripercussioni su alcuni software nella gestione di date relative all'anno 2038 e successivi.
Problema[modifica | modifica wikitesto]
Il problema riguarda programmi che usano la rappresentazione POSIX per calcolare il tempo: questa calcola la data del sistema come il numero di secondi trascorsi dallo Unix Epoch Time 1 gennaio 1970 (ignorando i secondi intercalari). Questo tipo di sistema è lo standard per i sistemi Unix, e colpisce anche software per altri sistemi operativi che siano stati sviluppati in C. Sulla maggior parte dei sistemi a 32 bit, il valore del dato time.h usato per questo calcolo è un numero intero a 32 bit di tipo signed.
Usando questo sistema, l'istante più lontano rappresentabile scoccherà alle ore 03:14:07 del 19 gennaio 2038 (UTC). Dopo questo momento, il contatore supererebbe il valore massimo, e verrebbe considerato come un numero negativo. I computer leggeranno la data non come 2038, ma come 1901 (precisamente, le 20:45:52 UTC di venerdì 13 dicembre 1901), causando errori di calcolo.[1] "Year 2038" è chiamato anche "Y2038", "Y2K38" o "Y2.038K".
Il bug Y2038 si può manifestare anche in date precedenti al 2038 ovvero, nello specifico, ogni qual volta un software che ne è affetto debba calcolare una data futura successiva a quella critica. Nel maggio 2006, per esempio, il bug colpì il server web AOLserver che gestiva le richieste senza scadenza al proprio database assegnando alle stesse una data di scadenza pari ad un miliardo di secondi nel futuro. Alle 21:27:28 del 12 maggio 2006 (data del server; un miliardo di secondi prima del 2038) il sistema di calcolo superò il limite critico restituendo, di conseguenza, una data di scadenza nel passato e causando un crash del sistema.[2][3]
Soluzioni[modifica | modifica wikitesto]
Non è semplice risolvere il problema per le combinazioni attuali di processori, sistemi operativi e file system. Cambiare il valore di time.h per usare un sistema a 64 bit renderebbe il sistema incompatibile con software, sistemi di memorizzazione e tutti gli strumenti che usano una rappresentazione binaria del tempo. Cambiare time.h in un intero unsigned, permettendo di rimandare il problema al 7 febbraio 2106, causerebbe comunque problemi a molti programmi.
Molti sistemi operativi per sistemi a 64 bit usano già dei numeri interi a 64 bit per il time.h. Il passaggio a questo tipo di architetture è in corso, e ci si aspetta che sia completo prima del 2038. Tuttavia, ancora oggi esistono centinaia di milioni di sistemi a 32 bit sul mercato, di cui molti in sistemi integrati. Nonostante l'attuale ritmo di aggiornamento dei computer ogni 18-24 mesi, i computer integrati possono lavorare senza interruzioni per tutta la vita del sistema che controllano. L'uso di time.h a 32 bit è anche stato inserito in vari formati di file, cosa che comporta la persistenza del problema anche oltre la vita delle macchine stesse. L'uso di un valore di tipo signed a 64 bit sposterebbe l'emergere del problema in avanti nel tempo di circa 290 miliardi di anni.
Sono state avanzate anche varie proposte alternative, alcune delle quali in uso, per sfruttare questo spostamento eccessivo della data massima calcolabile: tra queste, includere nel calcolo i millisecondi o i microsecondi, abbreviando la vita utile delle macchine a 300.000 anni.[4][5]
Bug simili[modifica | modifica wikitesto]
Un bug molto simile a quello dell'anno 2038 è quello di alcune unità SSD di HPE che dopo 32.768 ore smettono di funzionare. Il firmware di queste unità è stato programmato utilizzando un numero intero a 16 bit con segno per rappresentare le ore di attività: ciò si traduce in un numero massimo rappresentabile di 32.768 ore, ovvero 3 anni, 270 giorni e 8 ore. Per fare un confronto, utilizzando un numero a 32 bit con segno si otterrebbe un massimo di 2.147.836.648 ore, equivalenti all'incirca a 245.000 anni. Superata la soglia fatidica delle 32.768 ore, le unità SSD affette diventano inutilizzabili e i dati in esse contenuti sono da considerare persi per sempre.[6]
Note[modifica | modifica wikitesto]
- ^ Welcome to The Year 2038 Bug Site, su 2038bug.com. URL consultato il 22 agosto 2019 (archiviato dall'url originale il 1º gennaio 2014).
- ^ The Future Lies Ahead, su The American Caliban, 28 giugno 2006. URL consultato il 22 agosto 2019.
- ^ Something wrong after 2006-05-12 21:25, su mail-archive.com. URL consultato il 22 agosto 2019.
- ^ Unununium Time, su unununium.org, 8 aprile 2006. URL consultato il 22 agosto 2019 (archiviato dall'url originale l'8 aprile 2006).
- ^ Java API documentation, Sun Microsystems, su docs.oracle.com. URL consultato il 22 agosto 2019.
- ^ Alcuni SSD di HPE muoiono dopo 32.768 ore: facciamo chiarezza (e ricordiamoci dei backup), su Hardware Upgrade. URL consultato il 1º gennaio 2020.
Voci correlate[modifica | modifica wikitesto]
Collegamenti esterni[modifica | modifica wikitesto]
- The Year-2038 Bug Website, su 2038bug.com (archiviato dall'url originale il 1º gennaio 2014).
- La pagina su How Stuff Works, su computer.howstuffworks.com.
- la FAQ del Project 2038, su maul.deepsky.com.
- Date critiche: 2038, su merlyn.demon.co.uk. URL consultato il 1º giugno 2007 (archiviato dall'url originale il 7 settembre 2015).
