John Stultz: Dealing with 2038

May 5, 2014

Participants: Andy Lutomirski, Arnd Bergmann, Ben Hutchings, Daniel Phillips, Grant Likely, H. Peter Anvin, Jonathan Corbet, Josh Triplett, Li Zefan, Rafael J. Wysocki, Theodore Ts'o, and Tony Luck.

People tagged: (none).

John Stultz raised the year-2038 epoch issue, noting that 32-bit hardware was likely to still be in use in 2038, and also pointing out that NetBSD and OpenBSD recently changed their ABI to convert time_t to long long so as to avoid this issue. Andy Lutomirski indicated interest, and would also like to an interface similar to clock_gettime() that took a simple nanosecond counter instead of the current seconds/nanoseconds split. Andy would also like to see something done about leap seconds. Josh Triplett would also like discussions to include general patterns for switching away from old and broken ABIs, which would include supporting the old broken ABI as long as necessary. Andy Lutomirski called out CONFIG_COMPAT_VDSO as an example. This is default “n”, but is enabled to allow old software to run. H. Peter Anvin argued that Linux has dealt with these transitions before, but that time_t was non-trivial due to the large number of userspace library ABIs that must also change. Peter was not optimistic about the libraries properly maintaining separate versions for the old and new time_t size, and suggested switching to int32_t, which would put of the problem until 2106. Thsi would have some issues, such as old binaries believing that 2039 comes before 2037, but there will be problems with any approach.

Josh Triplett suggested that the handling of off_t might be a good model for time_t. Theodore Ts'o pointed out that off_t was never used as heavily as is time_t, and besides, the approach with off_t was to migrate to a new type loff_t. The issues with libraries providing 64-bit time_t and programs only wanting 32-bits are more tricky [ perhaps in part because a 32-bit off_t would still work on small files even in a 64-bit world ]. Ted agrees that 32-bit-only chips will still be with us in 2038, but expects that many of them will be in deep embedded environments that don't need a full set of libraries. H. Peter Anvin noted that the transition to a 64-bit off_t was enormously complex, and believes that time_t will be even more complex. John gave automotive infotainment systems as an example of a long-lifespan embedded system that needs a diverse set of libraries. John also argues that the 32-bit ABI absolutely will need to break by 2038. Arnd Bergmann offers up medical and military embedded systems to the list of long-lifespan embedded systems needing a diverse set of libraries. Li Zefan said that a number of Huawei products fit this description as well.

Theodore Ts'o asks where the solution lies, noting that if this is really a library problem, then LKS might not be the right place to try to solve it. John Stultz asked for glibc contacts, and also noted that he would be tag-teaming this topic with Thomas, with John covering Kernel Summit and Thomas covering Plumbers. Theodore Ts'o suggested Roland McGrath and Dave Miller as good initial glibc contacts. Josh Triplett believes that fixing the kernel is non-trivial, asking how the kernel ABI can be changed so as to inflict minimal pain on userspace applications and libraries. Josh also asks if some of the userspace compatibility code now located in the kernel can be moved to low-level libraries that ship with the kernel. Theodore Ts'o asked that someone do kernel-fix homework up front, looking through all the kernel interfaces (syscalls, ioctls, etc.) that deal in time_t or clock_t. Ted also feels that mailing-list discussions are more productive for brainstorming than are face-to-face meetings, hence the call for advance homework. John Stultz obliged, sending an email listing three options with pros and cons for each. Ted asked John to expand the homework to include glibc and other libraries, and critiqued the idea of providing a new set of time-related system calls (similar to what was done for large-file support back in the day). Given the glibc issues, Ted suggested setting up some discussions at Plumbers. John agreed with the idea of proposing a Year 2038 microconference at Plumbers. Daniel Phillips called out the benefits of an LKS discussion as a great soapbox, and suggested that the audit system could be used to detect applications using the sign bit of time_t, which could help enable Peter's idea of kicking the can down the road to 2106. Tony Luck argued that any auditing needs to happen sooner rather than later, noting that the first Y2038 bugs appeared in 2008 in software used to calculate 30-year mortgages. Daniel agreed that auditing should happen as soon as possible. Daniel also argued that large-file support is not yet universally supported by applications, even 17 years after introduction, as was made clear when applications were broken by a buggy test for large-file support in autoconf. Daniel also argued that a great many libraries will change ABI when time_t changes size: Although glibc will likely use symbol versioning or mangling to maintain binary compatibility, most library maintainers won't go to that effort.

Theodore Ts'o wonders when we will take 2038 seriously, guessing based on Y2K that it will be 2035 or so. Arnd Bergmann notes that the majority of the affected systems are embedded systems, many of which run a custom userspace. Even in the embedded space, many people will be moving to x64-64 and arm64. Therefore, getting support in the kernel is a good first step, as people building special-purpose userspaces would naturally use the new 2038-safe API. Josh Triplett adds that 32-bit-on-64-bit environments such as x32 can access 64-bits when needed, so that the main concern is for new systems that don't do 64-bit at all. The long lifetime of embedded systems means that the problem needs to be solved sooner rather than later. H. Peter Anvin agreed, stating that although he once believed that 32-bit-only devices would be extinct by the mid-2020s, the persistence of $0.25 8-bit microcontrollers running specialty OSes now leads him to believe that these will be replaced by $0.25 32-bit microcontrollers running Linux. The fact that packaging dominates the cost of the silicon, makes this transition inevitable. Peter further worries that many of them will be in Internet-connected Internet of Things. Grant Likely agrees, stating that there will be a very long tail of cheap 32-bit embedded platforms. Grant believes that Tim's cereal-box freebie Linux system isn't far off.

Andy Lutomirski suggests adding a 64-bit mode to 32-bit kernels so that all quantities passed into and out of the kernel are 64-bit quantities even on 32-bit systems, possibly with the help of an __attribute__((64_bit_layout)). Andy calls out the reuse of the existing 64-bit ABI as a big benefit of this scheme, but wonders if it is practical.