Pora na 64-bitowy czas. Inaczej w 2038 r. wszystko wybuchnie
Kiedy mówi się o problemach informatycznych związanych z datami większość osób pamięta panikę Y2K z roku 2000. Jednak za nieco ponad 13 lat czeka nas kolejne wyzwanie, które może okazać się równie poważne - problem roku 2038, znany także jako Unix Epochalypse lub Y2K38.
To właśnie w odpowiedzi na to zagrożenie projektanci dystrybucji Debian podjęli decyzję o przejściu na 64-bitowy format czasu już w nadchodzącej wersji 13 Trixie. Decyzja ta nie jest przypadkowa. Problem dotyczy systemów, które mierzą czas w sposób uniksowy - jako liczbę sekund, które upłynęły od 1 stycznia 1970 r. Na systemach 32-bitowych ta liczba jest przechowywana jako 32-bitowa liczba całkowita ze znakiem, która może reprezentować maksymalnie 2 147 483 647 sekund. To oznacza, że dokładnie 19 stycznia 2038 r. o godzinie 03:14 systemy zaczną interpretować czas jako 13 grudnia 1901 r.
Skala problemu - miliony urządzeń pod znakiem zapytania
Debian nie podejmuje tej decyzji bez powodu. Jak tłumaczą opiekunowie dystrybucji jest sporo ekonomicznie wrażliwego sprzętu 32-bitowego, a nowe urządzenia wciąż są wysyłane (automotive, IoT, telewizory, routery, kontrolery zakładów, monitorowanie/kontrola budynków, tanie telefony z Androidem). Ta lista nie brzmi jak coś poważnego, ale w rzeczywistości opisuje infrastrukturę krytyczną dla współczesnego świata.
Czytaj też:
Systemy przemysłowe często działają przez dekady od wdrożenia. Kontrolery systemów HVAC w budynkach, systemy sterowania w zakładach przemysłowych czy routery w sieciach IoT - wszystkie te urządzenia mogą nadal funkcjonować w 2038 r. Automotive to szczególnie wrażliwy sektor, gdzie pojazdy z zaawansowanymi systemami IoT już dziś trafiają na drogi i będą eksploatowane przez następne 15-20 lat.
Problem dotyczy również tanich telefonów z Androidem, które często bazują na 32-bitowych procesorach ARM. Już dziś można zawiesić niektóre urządzenia z Androidem, ustawiając datę na 19 stycznia 2038 r.
Debian zmienia wszystko - ale nie dla najstarszego sprzętu
Przejście Debiana na 64-bitowy time_t to monumentalne przedsięwzięcie. Opiekunowie znaleźli tę zmienną wszędzie - w łącznie 6429 pakietach. Ponieważ zmiana wymaga złamania kompatybilności interfejsu binarnego aplikacji (ABI) musi nastąpić jednocześnie we wszystkich dotkniętych bibliotekach.
Debian wprowadza 64-bitowy time_t na wszystkich architekturach 32-bitowych poza i386. Ta ostatnia zostanie pozostawiona z 32-bitowym czasem jako architektura kompatybilności dla istniejących binariów x86. Opiekunowie pozostawiają jednak furtkę: Nowa architektura i686 x86 ABI/architektura używająca 64-bitowego czasu i potencjalnie nowszych funkcji ISA mogłaby zostać stworzona, gdyby było wystarczające zainteresowanie przeciągnięciem 32-bitowego x86 w jego teraz bardzo ograniczoną przyszłość.
Debian nie jest jedyną dystrybucją, która przygotowuje się na 2038 rok. Musl, alternatywna implementacja biblioteki C, już przeszła na 64-bitowy time_t w wersji 1.2.0. Gentoo debatuje nad bezpieczną ścieżką migracji, ale stoi przed większymi wyzwaniami jako dystrybucja oparta na kompilacji ze źródeł. OpenEmbedded i Yocto Project już oferują wsparcie dla 64-bitowego czasu przez dedykowane warstwy meta, takie jak meta-y2038. Texas Instruments udostępnia gotowe obrazy Y2K38-friendly oparte na kernelu 6.6 i systemie plików Scarthgap.
Dobrą wiadomością jest to, że główne komponenty systemów linuxowych już są przygotowane. Kernel Linux obsługuje 64-bitowy czas od wersji 5.1, gdzie wprowadzono nowe syscalle *time64 dla platform 32-bitowych. Pełna obsługa w przestrzeni użytkownika pojawiła się w kernelu 5.6 wraz z glibc 2.32+.
Glibc umożliwia teraz 64-bitowy time_t na systemach 32-bitowych poprzez odpowiednie flagi kompilacji (-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64). To oznacza, że większość nowych aplikacji kompilowanych z nowszymi wersjami toolchaina będzie automatycznie bezpieczna na 2038 r.
Szczególnie trudna sytuacja dotyczy systemów wbudowanych i IoT
Wiele urządzeń używa prostszych systemów operacyjnych lub starszych wersji Linuksa, które mogą nie mieć obsługi 64-bitowego czasu. Jako przykład można podać system bazujący na 32-bitowym FreeBSD, gdzie japońscy badacze zdecydowali się na zmianę punktu startowego Unix epoch zamiast przechodzenia na 64-bitowy time_t.
Problem komplikuje fakt, że wiele systemów IoT nigdy nie otrzymuje aktualizacji. Routery, systemy kontroli klimatyzacji, czy urządzenia przemysłowe często działają z oryginalnym oprogramowaniem układowym przez całą swoją żywotność.
Co dalej z Linuxem?
Przejście Debiana na 64-bitowy czas to znaczący krok w przygotowaniach do 2038 r., ale to dopiero początek. W przeciwieństwie do Y2K, gdzie problem dotyczył głównie formatowania dat, Y2K38 wymaga fundamentalnych zmian w architekturze systemów. Na szczęście linuxowa społeczność podchodzi do problemu 2038 proaktywnie.
Z nieco ponad 13 latami do krytycznej daty, mamy czas na przemyślane przygotowania. Debian pokazuje drogę, ale prawdziwe wyzwanie będzie polegało na aktualizacji milionów urządzeń wbudowanych, które już dziś trafiają do eksploatacji.
Gdzie w tym wszystkim są Windows i unixowe Android, macOS i iOS?
System Windows ma zdecydowanie bardziej skomplikowaną sytuację niż mogłoby się wydawać. Microsoft co prawda stosuje własny format FILETIME, który jest odporny na problem Y2038, ale w praktyce wiele aplikacji nadal może być podatnych na ten błąd.
Windows FILETIME używa 64-bitowej liczby całkowitej reprezentującej interwały po 100 nanosekund od 1 stycznia 1601 r., co pozwala na reprezentowanie dat aż do roku 30828. Ten format jest używany przez system plików NTFS i wiele funkcji systemowych Windows.
Jednak problemy pojawiają się na kilku poziomach:
- 32-bitowe aplikacje Windowsa nadal mogą używać bibliotek C/C++, które są podatne na Y2038;
- Aplikacje używające kompatybilnych z POSIX bibliotek (jak ActivePerl) mogą zawieść już dziś, gdy data jest ustawiona po 2038 r.;
- Testy wykazały problemy w niektórych komponentach, np. Windows Media Player przestaje działać po ustawieniu daty na 2038 r.;
- Windows Server ma już udokumentowane problemy z logowaniem do domeny i stosowaniem GPO po ustawieniu daty na 13 września 2037 r.
Android jest szczególnie podatny na problem Y2038, głównie ze względu na swoją architekturę opartą na Linuksie i szerokie zastosowanie 32-bitowych procesorów. Urządzenia działające pod 64-bitową odmiana tego systemu nie będą dotknięte omawianym problemem.
Sytuacja Apple'a jest znacznie bardziej złożona niż mogłoby się wydawać, z różnymi problemami w różnych okresach rozwoju systemów. Stare wersje Mac OS (przed OS X 10.6 Snow Leopard) są podatne na problem Y2038, ponieważ używają 32-bitowego time_t. Co ciekawe klasyczny Mac OS używa niepodpisanego 32-bitowego formatu z epoką rozpoczynającą się 1 stycznia 1904 r., co oznacza, że przepełnienie nastąpi dopiero 6 lutego 2040 r.
Nowsze wersje:
- OS X 10.7 Lion i nowsze używają 64-bitowego time_t i są bezpieczne na poziomie systemu;
- 32-bitowe aplikacje mogą nadal mieć problemy, nawet na 64-bitowych systemach;
- iOS na 32-bitowych urządzeniach (iPhone 5 i starsze) może mieć ograniczenia w ustawianiu dat po 2038 roku;
- 64-bitowe urządzenia iOS (iPhone 5s i nowsze) są generalnie bezpieczne.
Innymi słowy nowe urządzenia konsumenckie - wyłączając niedrogie telefony z Androidem - raczej przetrwają obie przyszłe dekady, choć to i tak będzie problem głównie dla miłośników sprzętu retro. Nie to jest problemem, a otaczająca nas informatyczna infrastruktura. Której aktualizacja będzie podatników i firmy drogo kosztować.
