Bugul anului 2038

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare
Manuale de programare UNIX.

Bugul anului 2038 (pe scurt: Y2038 ) este un bug computer , cunoscut de experți, care afectează unele programe software în gestionarea datelor referitoare la anul 2038 și ulterior.

Problemă

Problema afectează programele care utilizează reprezentarea POSIX pentru a calcula timpul: aceasta calculează data sistemului ca număr de secunde care au trecut de la Unix Epoch Time 1 ianuarie 1970 (ignorând secundele de salt ). Acest tip de sistem este standardul pentru sistemele Unix și afectează și software-ul pentru alte sisteme de operare care au fost dezvoltate în C. Pe majoritatea sistemelor la 32 de biți , valoarea datelor time.h folosită pentru acest calcul este un tip întreg pe 32 de biți semnat .

Folosind acest sistem, cel mai îndepărtat moment reprezentabil va apărea la 03:14:07 pe 19 ianuarie 2038 ( UTC ). După acest timp, contorul va depăși valoarea maximă și va fi tratat ca un număr negativ. Computerele vor citi data nu ca 2038, ci ca 1901 (mai exact, 20:45:52 UTC vineri, 13 decembrie 1901 ), provocând greșeli de calcul. [1] „Anul 2038” se mai numește „Y2038”, „Y2K38” sau „Y2.038K”.

Exemplu care arată resetarea datei.

Eroarea Y2038 poate apărea și la date anterioare anului 2038 sau, mai exact, ori de câte ori un software afectat de acesta trebuie să calculeze o dată viitoare după cea critică. În mai 2006 , de exemplu, eroarea a lovit serverul web AOLserver , care a gestionat cererile care nu expirau la baza sa de date, atribuindu-le o dată de expirare egală cu un miliard de secunde în viitor. La 21:27:28 din 12 mai 2006 (data serverului; cu un miliard de secunde înainte de 2038), sistemul de calcul a depășit limita critică, returnând astfel o dată de expirare în trecut și provocând o blocare a sistemului. [2] [3]

Soluții

Nu este ușor să rezolvați problema pentru combinațiile actuale de procesoare , sisteme de operare și sisteme de fișiere . Schimbarea valorii time.h pentru a utiliza un sistem pe 64 de biți ar face sistemul incompatibil cu software-ul, sistemele de stocare și toate instrumentele care utilizează o reprezentare binară a timpului. Schimbarea time.h la un număr întreg nesemnat , permițând amânarea problemei la 7 februarie 2106 , ar provoca în continuare probleme pentru multe programe.

Multe sisteme de operare pentru sistemele pe 64 de biți folosesc deja numere întregi pe 64 de biți pentru time.h Trecerea la acest tip de arhitecturi este în curs de desfășurare și se așteaptă să fie finalizată înainte de 2038. Cu toate acestea, există încă sute de milioane de sisteme pe 32 de biți pe piață astăzi, dintre care multe sunt sisteme încorporate. În pofida actualizării ritmului actual al computerelor la fiecare 18-24 de luni, computerele încorporate pot funcționa neîntrerupt pe tot parcursul vieții sistemului pe care îl controlează. Utilizarea time.h pe 32 de biți a fost, de asemenea, inclusă în diferite formate de fișiere, ceea ce înseamnă că problema va persista dincolo de viața mașinilor în sine. Folosirea unei valori semnate pe 64 de biți ar duce la apariția problemei în timp cu aproximativ 290 de miliarde de ani.

Au fost făcute, de asemenea, diverse propuneri alternative, dintre care unele sunt utilizate, pentru a exploata această schimbare excesivă în data maximă calculabilă: printre acestea, includ în calcul milisecunde sau microsecunde, scurtând durata de viață utilă a mașinilor la 300.000 de ani. [4] [5]

Bug-uri similare

O eroare foarte asemănătoare cu anul 2038 este cea a unor SSD-uri HPE care nu mai funcționează după 32 768 ore. Firmware-ul acestor unități a fost programat folosind un număr întreg de 16 biți semnat pentru a reprezenta orele de funcționare, ceea ce se traduce într-un număr maxim reprezentabil de 32.768 ore, adică 3 ani, 270 zile și 8 ore. Pentru comparație, utilizarea unui număr semnat pe 32 de biți ar produce un maxim de 2.147.836.648 ore, ceea ce este aproximativ echivalent cu 245.000 de ani. După pragul fatal de 32.768 de ore, SSD-urile afectate devin inutilizabile și datele conținute în acestea trebuie considerate pierdute pentru totdeauna. [6]

Notă

  1. ^ Bun venit pe site-ul Anului 2038 Bug , la 2038bug.com . Adus la 22 august 2019 (arhivat din original la 1 ianuarie 2014) .
  2. ^ The Future Lies Ahead . The American Caliban . 28 iunie 2006. Adus 22 august 2019 .
  3. ^ Ceva în neregulă după 2006-05-12 21:25 , pe mail-archive.com . Adus la 22 august 2019 .
  4. ^ Unununium Time , pe unununium.org , 8 aprilie 2006. Adus la 22 august 2019 (arhivat din original la 8 aprilie 2006) .
  5. ^ Documentație API Java, Sun Microsystems , la docs.oracle.com . Adus la 22 august 2019 .
  6. ^ Unele SSD-uri HPE mor după 32 768 de ore: să clarificăm (și să ne amintim copiile de rezervă) , la Hardware Upgrade . Adus la 1 ianuarie 2020 .

Elemente conexe

linkuri externe

Securitate IT Portal de securitate cibernetică : accesați intrările Wikipedia care se ocupă de securitatea cibernetică