Date
1 - 2 of 2
Y2038. a risk that requires attention today and would benefit from CIP participation
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
during the past CIP Members meeting call, Monday 23rd January, Members agreed on bringing to the attention of CIP contributors and friends the Y2038 topic. What is Y2038 refers to? "Y2038 refers to an issue related to the way time is handled by computers. Time is often represented as the number of seconds since Jan 1, 1970. Whenever a 32-bit signed integer is used for this, the maximum value that can be represented is ± ~68 years, 19 days from the epoch, which corresponds to Jan 19, 2038. What happens after that is system dependent, but generally not good. A computer may act as if its time got reset to Dec 1901, or possibly to the epoch of Jan 1, 1970. It may give unexpected results or crash." Definition extracted from http://www.y2038.com[1]. Check more about the description of the problem in Wikipedia[2]. The Linux Kernel community is already acting on this topic since version 3.17[3] at least. One of the most interesting activities is to define tasks for newbies[4] related with this topic. You can read in this article[5] an update about what is being done, from 2015 and another reference[6] from 2016. CIP Members has expressed their interest for Y2038 on user space too. Arnd Bergmann, in CC, is one of the advocates of the Y2038 initiative. @Arnd, is there any further documentation we should read about this topic? What are the key activities at this point within the Linux Kernel related with the topic? Who can we talk to related with user space? Any light you can provide us would be helpful. [1] https://y2038.com/faq/ [2] https://en.wikipedia.org/wiki/Year_2038_problem [3] https://lwn.net/Articles/607741/ [4] https://kernelnewbies.org/y2038 [5] https://lwn.net/Articles/643234/ [6] https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-More-Y2038-Work Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@...
|
|
Arnd Bergmann <arnd@...>
On Tue, Jan 24, 2017 at 5:58 PM, Agustin Benito Bethencourt
<agustin.benito@...> wrote: @Arnd, is there any further documentation we should read about this topic?Deepa Dinamani has done some important work on the kernel, but had a hard time getting some of the patches accepted at first. With her work, we now have some of the basics of converting over VFS, which I assume is one of the hardest parts. She is also looking into refactoring my system call series now, which is the other hard and absolutely essential part of the kernel work. Besides those there are a couple of areas that are tricky and spread out across the kerne (rtc, key management, probably one more), a couple that require small interface changes (input, v4l) and have to be done carefully, and lots of drivers that need to be individually fixed. Once those are done, 32-bit kernels and 64-bit kernels are equally good at dealing with y2038. I actually have an older prototype series that removes the definition of 'time_t' inside the kernel to ensure that there are no type confusions. Then there are issues that affect both 32-bit and 64-bit systems and that have to be fixed regardless. This mostly affects file systems (e.g. XFS), and many of them won't ever get fixed (e.g. ext3 is broken, but ext4 is a working replacement, same for NFSv2 vs NFSv3/4). The problem also exists in some network protocols and common file formats (e.g. CPIO). Again, these have to be dealt with individually. In user space, Albert Aribaud has an initial glibc patch set [1], which is most of what we require for typical 32-bit applications. glibc will allow building with either 32-bit or 64-bit time_t and support both at runtime (including on old kernels). In order to actually make it work beyond 2038, all user space has to be recompiled against the new glibc. Once that is done, we still have to deal with application specific bugs, where either timestamps are encoded as 32-bit integers on-disk, or the application uses its own types internally instead of time_t. Arnd [1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
|
|