[cip-dev] Y2038. a risk that requires attention today and would benefit from CIP participation

[cip-dev] Y2038. a risk that requires attention today and would benefit from CIP participation

[Agustin Benito Bethencourt]

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 at codethink.co.uk

[cip-dev] Y2038. a risk that requires attention today and would benefit from CIP participation

[Arnd Bergmann]

On Tue, Jan 24, 2017 at 5:58 PM, Agustin Benito Bethencourt
<agustin.benito@codethink.co.uk> wrote:
> @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.

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