2038 Problem with 32bit time in Linux

The problem is more complex than it seems at the first look. It is not solved by replacing the timer variable in the Linux kernel by a 64-bit value. I think this was done quite a while ago. The problems are the interfaces to the outside. For example there needed to be new system calls that transfer new time values based on 64-bit types. And software in user space also needs to use these new system calls. The 64-bit calls are supported since glibc-2.32. So software that wants to use these calls also has to be compiled at least with glibc-2.32 or newer. But as far as I know, this is not done automatically, the software actually has to be modified to use the 64-bit timestamp variants. So not only the Linux kernel has to be fixed for the Y2038 problem, also all the user space software has to be fixed for the Y2038 problem.

But even that is not enough. Also the file systems store time values, for example for the creation date or the last access. But the data structures in the directory or i-node entries are also defined a long time ago and can not easily be extended to use wider types. So also file systems have to be fixed for the Y2038 problem. This in turn has again an effect on the Linux kernel. When file systems are updated, also the Linux kernel needs to be updated again to support the new file system variants. Here is a table showing which file system has which limits. The table is taken from commit 9d14545bf9eed69fbd4af14b927a462324ea19 of the mainline Linux kernel. A similar list exists here: https://kernelnewbies.org/y2038/vfs

So where are we right now? The Linux kernel is supposed to be stable for Y2038 since 5.6 regarding the time value itself, the Virtual File System Layer (VFS), the system calls and all internal driver interfaces. The Y2038 patches have also been ported back to kernel 5.4. The last changes that I can see in the 5.4 branch that are labeled with y2038 are from 5.4.78. Current F&S releases on i.MX8 are based on 5.4.80, so these versions should be safe. Unfortunately there are no 5.4 releases for the i.MX6 boards yet. We are working on this, but it's not yet finished.

The F&S toolchains for Buildroot based on gcc-8.3 are using glibc-2.32, so basically Buildroot is prepared to build Y2038-safe software. However if all packages in Buildroot are already updated to be Y2038-safe is a big question and I would doubt it. Yocto builds its own toolchain as part of the build process (it actually builds several toolchains). So checking the versions in Yocto is more complex. I can do this, if you really need this information. For the software packages in Yocot, it is the same question as for Buildroot.

For the file systems, we typically use FAT and EXT4 on eMMC. As you can see, FAT is at least safe until year 2107, EXT4 is safe if the extra variant is used. On NAND we are safe, UBIFS is rather new and was using 64-bit time values right from the beginning.

Is this all? You never know for sure. For example in kernel 5.10, there were some more changes to support a longer time range in the XFS file system. This has no effect unless you actually use XFS in your system. And of course if you simply use one single program in user space that is not converted yet, your whole system may still break in the year 2038.

If you really want to be sure if your system is Y2038-safe, then you have to check every single program and every single library that you actually use. This is nearly impossible and therefore I believe that the chance is very high that it will still need some software updates before 2038 to fix further problems that pop up until then. So it is essential that you implement an update procedure in your device to be able to install newer versions of your software in the future. Having an update feature but not needing an update is far better than needing an update and not having an update feature.

Your F&S Support Team