Login
Newsletter
Werbung

Fr, 7. Februar 2020, 11:56

Software::Kernel

Linux 5.6 löst Jahr-2038-Problem für 32-Bit-Systeme

Die kommende Version 5.6 wird der erste Linux-Kernel sein, der gegen das Jahr-2038-Problem auf 32-Bit-Systemen immun ist. Damit das greifen kann, müssen die Anwendungen allerdings mit den neuen 64-Bit-Zeittypen compiliert werden, die erst in glibc 2.32 und musl 1.2 zur Verfügung stehen werden.

Larry Ewing

Kernel-Entwickler Arnd Bergmann beschäftigt sich bereits seit Jahren mit den Zeitgebern und allen Funktionen im Linux-Kernel, die mit Zeit zu tun haben. Mit einem jetzt vorgestellten Patch für Linux 5.6 kulminiert die Arbeit auf Kernel-Seite, alle Datenstrukturen auch in 32-Bit-Systemen auf 64 Bit umzustellen. Bergmann stellt diese Patches auch für Linux 5.4 zur Verfügung.

Sobald diese Änderungen integriert sind, werden die Datentypen time_t, timeval und timespec aus dem Kernel verschwinden, da sie nicht mehr benutzt werden. Auf Kernel-Seite sind damit alle Arbeiten erledigt, die nötig sind, um das Jahr-2038-Problem zu überstehen. Nicht geändert werden können allerdings alte Dateisystemformate wie ext2, ext4 (nur wenn kleine Inodes verwendet werden, die von ext3 herrühren), UFS und XFS (das in diesem Jahr beginnt, auf ein neues Format umzustellen). Für Anwendungen gibt es dem Entwickler zufolge aber noch eine Reihe von Dingen zu beachten. Zunächst müssen sie auf glibc 2.32 oder musl 1.2 warten, wenn sie mit diesen C-Bibliotheken compiliert werden. Änderungen am Programmcode sollten dank der Kompatibilitätsfunktionen nur manchmal notwendig sein. Anwendungen, die Systemaufrufe direkt verwenden, müssen auf die 64-Bit-Varianten umgestellt werden, das dürfte auch viele Anwendungen betreffen, die nicht in C/C++ geschrieben sind. Anwendungen, die private Kopien von Kernel-Headerdateien verwenden, müssen mit der neuesten Version neu compiliert werden. Eine Handvoll von Schnittstellen lässt sich zudem nicht umstellen, darunter die Struktur input_event.

64-Bit-Systeme nutzen schon länger 64-Bit-Zeitstempel. Doch auch auf diesen Systemen sind Probleme mit dem Jahr 2038 nicht ganz ausgeschlossen, wie man am Beispiel der Dateisystemformate sieht. All diese Probleme betreffen auch 32-Bit-Systeme weiterhin.

Das Jahr-2038-Problem ist bereits lange bekannt und hat seine Ursache in der Frühgeschichte der Computer. Da Speicher in Computern historisch knapp und teuer war, wurde der Zeitzähler als 32-Bit-Zahl definiert - mit Vorzeichen, um auch Zeiten vor 1970 darstellen zu können. Daher wird im Jahr 2038 zwangsläufig ein Überlauf eintreten. Im Betriebssystem-Kernel (Linux, BSD) konnte dies verhältnismäßig leicht durch eine Verlängerung auf 64 Bit behoben werden. Doch da der Wert auch durch verschiedene Kernel-Schnittstellen und Systemaufrufe an die Anwendungen übergeben wird, mussten zahlreiche Schnittstellen und Aufrufe ein 64-Bit-Pendant erhalten. NetBSD und OpenBSD konnten das Problem bereits viel früher lösen, allerdings begünstigt durch die Tatsache, dass deren Ökosystem kleiner ist. Für ältere, nur als Binärdateien vorliegende Programme wurde ein Kompatibilitätsmodul geschaffen. Die entsprechenden Änderungen wurden bereits im Oktober 2012 in NetBSD 6.0 sowie in OpenBSD 5.5 im Oktober 2014 publiziert. Die Änderung bestand in der Erweiterung des Unix-Zeitzählers, repräsentiert durch den Datentyp time_t, auf 64 Bit für alle Architekturen, also auch die 32-Bitter. Alle Programme in diesen Betriebssystemen und den Ports-Sammlungen mussten angepasst, neu compiliert und getestet werden, um das zu erreichen.

Auch in Linux wurde eine Lösung angestrebt, die die Kompatibilität mit bestehenden Anwendungen, die 32-Bit-Zeit verwenden, auf allen Architekturen wahrt. Dazu war auch eine enge Zusammenarbeit zwischen den Kernel-Entwicklern und denen von glibc nötig. Denn der Kernel kann zwar neue Systemaufrufe mit 64-Bit-Zeit zur Verfügung stellen, aber es ist Sache der glibc, diese in POSIX-kompatiblen Funktionen den Programmen zugänglich zu machen. Im Februar 2017 legten die glibc-Entwickler einen Entwurf zu den nötigen Änderungen vor (später aktualisiert), der inzwischen weitgehend umgesetzt wurde.

Im Kernel begannen die Arbeiten 2014, als die Datenstruktur timespec64 in Linux 3.17 eingeführt wurde. Der nächste Meilenstein datiert erst von August 2018, als in Linux 4.18 Kernel-intern eine neue Datenstruktur für Zeitstempel mit zwei 64-Bit-Feldern definiert und an einigen Stellen verwendet wurde. Außerdem wurden die SysV-Prozesskommunikationsaufrufe 2038-fest gemacht. Die Umstellung und Erweiterung des Kernels ging weiter, unter anderem mit den Aufrufen ppoll, pselect6, io_pgetevents, recvmmsg, futex und rt_sigtimedwait, die in Linux 5.0 64-Bit-Versionen auf 32-Bit-Systemen erhielten. In Linux 5.1 bekam eine Reihe von Systemaufrufen äquivalente Aufrufe mit 64-Bit-Zeitstempeln.

Mit den jetzt erfolgten Änderungen sowie den kommenden Versionen von glibc und musl lässt sich ab Herbst dieses Jahres sagen, dass Systeme, die keine Legacy-Dateisysteme verwenden, keine Probleme nach dem Januar 2038 haben werden, falls sie bis dahin noch im Einsatz sind. Und diese Möglichkeit ist bei eingebetteten Systemen keineswegs ausgeschlossen.

Werbung
Kommentare (Insgesamt: 16 || Alle anzeigen || Kommentieren )
Re[5]: Wozu ?!?? (blablabla233, Di, 11. Februar 2020)
Re: EFI - Fat (Verfluchtnochmal_5987108, So, 9. Februar 2020)
Re[6]: Wozu ?!?? (Ach je ..., So, 9. Februar 2020)
Re: Wozu ?!?? (Pffffft, So, 9. Februar 2020)
Re[5]: Wozu ?!?? (glasen, Sa, 8. Februar 2020)
Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung