2038: only 21 years left

Sometimes it seems that on the front of the struggle with the problem of 2038 there was a relative lull. However, time is ticking, and the day when 32-bit values ​​of type time_t can no longer display dates correctly will occur in less than 21 years. This period may seem large, but the relatively long life cycle of many embedded systems implies that some of them, being commissioned in our time, will still work when the critical moment comes. Arnd Bergmann is one of the main developers dealing with this problem. At the Linaro Connect 2017 conference, he shared news on the current state of affairs in this area.

According to Bergmann, the work is carried out in three independent directions at once, the first of which is the Linux kernel itself. For the past five years, he has been looking for ways to prepare the core by 2038. Much of this work involves converting 32-bit timestamps to 64-bit values ​​— even on 32-bit systems. Some 32-bit timestamps are also used in user APIs, which greatly complicates the problem. Bergmann has a plan to improve these APIs by adapting versions of problematic system calls adapted to 2038, but these changes have not yet been applied, with the exception of the recently added statx () system call in version 4.11, which will replace the stat () call family. At the same time, there are many other system calls that need such a replacement.

Deepa Dinmani is also engaged in solving problems related to the kernel. She began as an intern for the Outreachy program and, after completing the internship, continued to work on this task. Dinamani solved one of the most difficult problems by developing her own set of patches for the virtual file system layer , and also plans to deal with other system calls. Calling setsockopt () , among others, can be particularly difficult: it is not so easy to fix or emulate at the glibc level. There is a noticeable progress in the work on creating patches for the device mapper module and the input subsystem. Bergmann also wrote a patch for the video4linux subsystem, but it was rejected and requires a different approach. Approximately the same situation with the sound subsystem. Other problematic components of the kernel are the key management system and the real time clock.

Some system calls will not receive a replacement, since for them the best solution is emulation in the C libraries - this is the second direction in preparation for 2038. Bergmann noted that the glibc community has done particularly great work in this area. At the library level, it is planned to provide full backward compatibility. This means that it will be possible to build programs with both 32-bit and 64-bit time stamps, while the latter can be used even in older versions of the kernel. In other words, glibc developers are looking for solutions that work on all platforms and with minimal distortion. (Details can be found in the draft draft).
')
The third direction is connected with the distributions assemblies, and the real progress here is possible only after the first two tasks are solved. According to Bergmann, it is unlikely that distributive authors will still support 32-bit systems in 2038, so they have no cause for concern. The only exception may be the Debian distribution, whose authors seem interested in continuing to support, even though the process is obviously laborious. At some point, a complete reassembly may be required, which will hardly please both authors and users, but this solution, at least, is guaranteed to work. In such a system, compatibility is key; Now a code is being put into operation, which may not be adapted to the offensive of 2038, but I want it to work as far as possible.

Automotive systems are another major area of ​​concern. Many devices, such as mobile phones, will stop working by 2038 for many other reasons, so there is no point in preparing them for its offensive. However, cars are in operation much longer. There may still be cameras on the move, and it is very likely that there will be many closely integrated systems, for example, in building infrastructure. Some of these systems will fail in 2038. That is why it is so important to solve the problem as soon as possible.

At the same time, with the correction of some components, difficulties will arise, even when the tasks of preparing the kernel, C libraries and distributions will be basically solved. Many of these difficulties are associated with the use of 32-bit values ​​of type time_t in file formats. For example, cpio will break, which will cause certain problems, as it is used in the format of RPM packages. NFSv3, ext3, and XFS file systems will also experience crashes due to the use of 32-bit time stamps. The first two systems are likely to become obsolete long before the beginning of 2038, and solutions are being developed for XFS. Finally, there are many applications that have not yet come to the attention of developers, as well as corporate systems to which the community does not have access.

When Bergmann was asked what tools he used in his work, he replied that the basic approach was to build a kernel with completely removed 32-bit types responsible for the presentation of time: this way you can immediately identify the places to be edited. For the rest, the corrections are carried out mostly manually. It is assumed that plugins for sparse or GCC can help in this task.

At the end of the speech, John Schulz asked if the BSD community, which (in some versions ) already solved the 2038 problem, can help Linux. Bergmann replied that help would be "insignificant." BSD distributions have the advantage of being able to rebuild from scratch, so they do not need to maintain compatibility with custom ABIs in the same way. Their experience in preparing applications by 2038 is not without value, but it is not known how useful it will be for the Linux community.

Note the PVS-Studio command. We are interested in this problem and we plan to implement diagnostics in the PVS-Studio analyzer, which will warn you about the use of 32-bit variables of the type time_t . The original of this article was published on lwn.net (CC-SA license).