Login
Newsletter
Werbung

Do, 23. Februar 2017, 15:25

Software::Entwicklung

Entwurf für Überwindung des Jahr 2038-Problems in glibc

Die glibc-Entwickler haben einen ausführlichen Entwurf vorgelegt, um die Änderungen zu diskutieren, die für einen erweiterten Zeit-Datentyp nötig sind. Die Aufgabe ist nicht so klein, wie es scheinen mag, da möglichst viele Kombinationen von Programmen und Kernel-Versionen unterstützt werden sollen.

Mirko Lindner

Intern verwalten Unix-Systeme die Zeit in einem Zähler, der die Sekunden seit dem 1.1.1970 anzeigt. Auf 32 Bit-Systemen ist dies nach wie vor eine 32 Bit-Zahl mit Vorzeichen. Daher würde im Jahr 2038 ein Überlauf eintreten. Im Kernel selbst könnte dies leicht durch eine Verlängerung auf 64 Bit behoben werden. Doch der Wert wird auch durch verschiedene Kernel-Schnittstellen und Systemaufrufe an die Anwendungen übergeben. Damit besteht das Problem in allen 32 Bit-Systemen und 32 Bit-Anwendungen. Das Problem ist seit langem bekannt und es wurden bereits Änderungen diskutiert oder vorgenommen, um es zu lösen.

In dieser Beziehung sind NetBSD und OpenBSD bereits weiter, allerdings begünstigt durch die Tatsache, dass deren Ökosystem kleiner ist und sie willens waren, die Kompatibilität mit älteren, nur als Binärdateien vorliegenden Programmen zu brechen. 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.

Sicher ist, dass es eine solch radikale Lösung in Linux nicht geben wird. Die Kompatibilität mit bestehenden Anwendungen, die 32-Bit-Zeit verwenden, soll auf allen Architekturen gewahrt bleiben. In den letzten Jahren wurde klar, dass dazu auch eine enge Zusammenarbeit zwischen den Kernel-Entwicklern und denen von glibc nötig ist. 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.

Die Arbeit zur Jahr 2038-Sicherheit hat nun wesentliche Fortschritte gemacht, indem die glibc-Entwickler einen Entwurf zu den nötigen Änderungen vorgestellt haben. Dieser soll zunächst als Grundlage für weitere Diskussionen dienen. Der Entwurf versucht alle Aspekte der geplanten Umstellung abzudecken und ist daher sehr ausführlich. Er definiert zunächst den Bereich, für den er zuständig ist, die grundlegenden Begriffe, die zu erreichenden Ziele und die Randbedingungen. Dann werden die von glibc definierten Datentypen und Funktionen ausführlich analysiert. Es folgen die geplanten Änderungen an Datentypen und Funktionen und Kompatibilitätsbetrachtungen.

Eine Grundvoraussetzung der Implementation ist bereits unabänderlich beschlossen. Programme werden entweder die 32-Bit-Zeitfunktionen oder deren 64-Bit-Äquivalent nutzen können, aber nicht beide. In den nächsten Jahren werden die 32-Bit-Varianten noch die Voreinstellung sein, so dass sich für die Anwendungen zunächst nichts ändert. Verlangt eine Anwendung explizit die 64-Bit-Zeit, werden die Datentypen und Funktionen entsprechend umdefiniert, behalten aber ihre Namen. Sauber geschriebene Anwendungen sollten, zumindest solange sie keine Zeiten nach 2037 verwenden, unverändert funktionieren, gleichgültig, ob sie mit 32- oder 64-Bit-Funktionen compiliert wurden. Es kann sein, dass es noch ein Jahr oder mehr dauert, bis die Änderungen implementiert sind, aber jedenfalls wird es lange, bevor es kritisch wird, eine Lösung geben.

Werbung
Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung