Second draft of the Y2038 design document

Second draft of the Y2038 design document

[Albert ARIBAUD]

Hi all, and a happy New Year while we're still in January.

I have produced a second draft of what will eventually become the Y2038
design document:

https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=55

Hopefully, all comments from previous round have been taken 
Questions, notes, comments, corrections can be appended to the document
and/or discussed here.

Cordialement,
Albert ARIBAUD
3ADEV

Re: Second draft of the Y2038 design document

[Paul Eggert]

Some typos: "1901-12-13 19:55:13 UTC" should be "1901-12-13 20:45:52 
UTC". "sentive" should be "sensitive". "20338" should be "2038". "Thins" 
should be "This".

I don't see why functions like 'time' and 'gettimeofday' should be 
allowed to misbehave on 64-bit hosts after 2038. They should just work. 
Glibc should not worry about 64-bit kernels without 64-bit time support. 
Any such kernels should just get fixed before 2038 rolls around.

Why are struct rusage, getrusage, etc. Y2038-sensitive? They hold 
intervals, not absolute times.

Re: Second draft of the Y2038 design document

[Arnd Bergmann]

On Thursday 28 January 2016 13:13:09 Paul Eggert wrote:
> Some typos: "1901-12-13 19:55:13 UTC" should be "1901-12-13 20:45:52 
> UTC". "sentive" should be "sensitive". "20338" should be "2038". "Thins" 
> should be "This".
> 
> I don't see why functions like 'time' and 'gettimeofday' should be 
> allowed to misbehave on 64-bit hosts after 2038. They should just work. 
> Glibc should not worry about 64-bit kernels without 64-bit time support. 
> Any such kernels should just get fixed before 2038 rolls around.
> 
> Why are struct rusage, getrusage, etc. Y2038-sensitive? They hold 
> intervals, not absolute times.

It can theoretically still overflow, though not at the same time:
If you have a large NUMA system with thousands of CPUs and an HPC
workload running on all of them for a couple of months at a time,
the field will overflow.

getrusage is also an example of a class of interfaces that need to
be addressed in one way or another because they contain a time_t
member in a structure, so any user space program that sees the
current definition of struct rusage but uses a 64-bit time_t will
disagree on the layout with the old kernel system call. Other
interfaces in this class are clock_getres, pselect, ppoll,
io_getevents, recvmmsg, semtimedop, rt_sigtimedwait,
sched_rr_get_interval, and sysinfo, along with many ioctl commands.
There is no overflow in them, but we have to either add a
replacement interface, or redefine the API to pass a 'long' instead
of 'time_t' to keep binary compatibility.

My current patch set for the kernel syscalls uses a structure
with all 64-bit members, so we can share the implementation between
the new 32-bit system call in compat mode with the existing native
64-bit system call. I'm not particularly attached to that solution,
it's just one of multiple ways to do this and I had to pick one.

	Arnd

Re: Second draft of the Y2038 design document

[Paul Eggert]

On 01/28/2016 03:21 PM, Arnd Bergmann wrote:
>> Why are struct rusage, getrusage, etc. Y2038-sensitive? They hold
>> >intervals, not absolute times.
> It can theoretically still overflow, though not at the same time:

In that case, I don't understand why nanosleep, setitimer, adjtime, 
pselect, etc. are not marked as Y2038-sensitive, as they can all 
overflow a 32-bit time_t in the same way that getrusage can.

Re: Second draft of the Y2038 design document

[Arnd Bergmann]

On Thursday 28 January 2016 16:12:30 Paul Eggert wrote:
> On 01/28/2016 03:21 PM, Arnd Bergmann wrote:
> >> Why are struct rusage, getrusage, etc. Y2038-sensitive? They hold
> >> >intervals, not absolute times.
> > It can theoretically still overflow, though not at the same time:
> 
> In that case, I don't understand why nanosleep, setitimer, adjtime, 
> pselect, etc. are not marked as Y2038-sensitive, as they can all 
> overflow a 32-bit time_t in the same way that getrusage can.

Agreed. As Joseph said earlier, it does not really matter whether
the interface is problematic by itself. If anything uses a time_t,
it has to be changed along with everything else based on the
definition of that type.

	Arnd

Re: Second draft of the Y2038 design document

[Albert ARIBAUD]

Hi Arnd and Paul,

Le Fri, 29 Jan 2016 09:58:16 +0100, Arnd Bergmann <arnd@arndb.de> a
écrit :

> On Thursday 28 January 2016 16:12:30 Paul Eggert wrote:
> > On 01/28/2016 03:21 PM, Arnd Bergmann wrote:
> > >> Why are struct rusage, getrusage, etc. Y2038-sensitive? They hold
> > >> >intervals, not absolute times.
> > > It can theoretically still overflow, though not at the same time:
> > 
> > In that case, I don't understand why nanosleep, setitimer, adjtime, 
> > pselect, etc. are not marked as Y2038-sensitive, as they can all 
> > overflow a 32-bit time_t in the same way that getrusage can.
> 
> Agreed. As Joseph said earlier, it does not really matter whether
> the interface is problematic by itself. If anything uses a time_t,
> it has to be changed along with everything else based on the
> definition of that type.

Thanks for the feedback (and sorry I could not reply earlier). I will
update the list accordingly.

Cordialement,
Albert ARIBAUD
3ADEV

Re: Second draft of the Y2038 design document

[Albert ARIBAUD]

Bonjour Paul,

Le Thu, 28 Jan 2016 13:13:09 -0800, Paul Eggert <eggert@cs.ucla.edu> a
écrit :

> Some typos: "1901-12-13 19:55:13 UTC" should be "1901-12-13 20:45:52 
> UTC". "sentive" should be "sensitive". "20338" should be "2038". "Thins" 
> should be "This".

Thanks, will fix this.

> I don't see why functions like 'time' and 'gettimeofday' should be 
> allowed to misbehave on 64-bit hosts after 2038. They should just work. 
> Glibc should not worry about 64-bit kernels without 64-bit time support. 
> Any such kernels should just get fixed before 2038 rolls around.

What about using GLIBC used over a current 64-bit kernel version, which
does not have proper Y2038 support, which makes GLIBC unable to provide
correct time-of-day past Y2038?

Should this GLIBC/kernel version combination be considered forbidden,
IOW, are we saying a Y2038-proof GLIBC should only be used with a
Y2038-proof kernel?

Cordialement,
Albert ARIBAUD
3ADEV

Re: Second draft of the Y2038 design document

[Arnd Bergmann]

On Monday 21 March 2016 13:15:20 Albert ARIBAUD wrote:
> > I don't see why functions like 'time' and 'gettimeofday' should be 
> > allowed to misbehave on 64-bit hosts after 2038. They should just work. 
> > Glibc should not worry about 64-bit kernels without 64-bit time support. 
> > Any such kernels should just get fixed before 2038 rolls around.
> 
> What about using GLIBC used over a current 64-bit kernel version, which
> does not have proper Y2038 support, which makes GLIBC unable to provide
> correct time-of-day past Y2038?

Which OS are you thinking of?

I don't think regarding Linux, we ever had any 64-bit kernel that did not
support 64-bit time_t correctly, aside from file system time stamps that
are depending on the file system implementation (e.g. ext4 until recently
was broken)

	Arnd

Re: Second draft of the Y2038 design document

[Paul Eggert]

Albert ARIBAUD wrote:
> What about using GLIBC used over a current 64-bit kernel version, which
> does not have proper Y2038 support, which makes GLIBC unable to provide
> correct time-of-day past Y2038?

We're saying "don't do that".

> Should this GLIBC/kernel version combination be considered forbidden,
> IOW, are we saying a Y2038-proof GLIBC should only be used with a
> Y2038-proof kernel?

No, we're saying that if your kernel has a Y2038 bug, the resulting system has a 
Y2038 bug. That doesn't mean you can't run a Y2038-safe glibc atop the buggy kernel.

By the way, a common problem with 64-bit kernels is not Y2038, it's something 
trickier, e.g., arbitrary limits at 2**63 / 1000000 because someone naively used 
a 64-bit microsecond counter. These limits are often well past 2038, but they 
don't have to be.  Are you worried about all arbitrary time limits before 2**63, 
or just time limits that show up by 2038?  For example, how about the time limit 
2**32 (in the year 2106)?

PS.  Did I mention the amusing limit hardcoded into zic?  It refuses to accept 
time stamps before the Big Bang....

Re: Second draft of the Y2038 design document

[Albert ARIBAUD]

Bonjour Paul,

Le Mon, 21 Mar 2016 11:19:18 -0700, Paul Eggert <eggert@cs.ucla.edu> a
écrit :

> Albert ARIBAUD wrote:
> > What about using GLIBC used over a current 64-bit kernel version, which
> > does not have proper Y2038 support, which makes GLIBC unable to provide
> > correct time-of-day past Y2038?
> 
> We're saying "don't do that".
> 
> > Should this GLIBC/kernel version combination be considered forbidden,
> > IOW, are we saying a Y2038-proof GLIBC should only be used with a
> > Y2038-proof kernel?
> 
> No, we're saying that if your kernel has a Y2038 bug, the resulting system has a 
> Y2038 bug. That doesn't mean you can't run a Y2038-safe glibc atop the buggy kernel.

Which is fine; obviously I'll rephrase the document to that effect.

> By the way, a common problem with 64-bit kernels is not Y2038, it's something 
> trickier, e.g., arbitrary limits at 2**63 / 1000000 because someone naively used 
> a 64-bit microsecond counter. These limits are often well past 2038, but they 
> don't have to be.  Are you worried about all arbitrary time limits before 2**63, 
> or just time limits that show up by 2038?  For example, how about the time limit 
> 2**32 (in the year 2106)?

I am primarily tasked to work on fixing the Y2038 issue. I might also
fix some othern non-Y2038-related, time limits on a case-by-case basis,
but priority goes to Y2038.

> PS.  Did I mention the amusing limit hardcoded into zic?  It refuses to accept 
> time stamps before the Big Bang....

:D

Cordialement,
Albert ARIBAUD
3ADEV

Re: Second draft of the Y2038 design document

[Joseph Myers]

I don't think the classification of whether symbols are "Y2038-sensitive" 
is useful.

The relevant question is: does the ABI to a function involve time_t, 
whether directory or indirectly (e.g. through struct stat)?  If it does, a 
separate version is needed for _TIME_BITS=64.  That includes functions 
involving relative timestamps.  And the notes "3. Regardless of the time_t 
size, the function may not return a time_t value beyond Y2038." and "4. 
Regardless of the time_t size, the function may not accept an time_t input 
value beyond Y2038." simply seem wrong - functions should accept, and be 
able to return, arbitrary valid time_t values.

There should (preferably) not be functions such as time64 that you 
mention, nor types such as time64_t, at the user API level.  Rather, 
_TIME_BITS=64 would cause time_t to be remapped to __time64_t and calls to 
time to end up calling __time64 at the assembler level.

I don't see how EDOM could be correct for out-of-range values.  EOVERFLOW 
seems clearly correct for overflow on both input and output.

The sentence "Symbol versioning appears unnecessary so far." is either 
wrong or meaningless, and so should be removed.  All new symbols get the 
appropriate symbol version for the first glibc release they are in.  It 
may well be the case that all new interfaces have new names at the 
assembler level - including e.g. __xstat64_time64 - rather than being new 
versions of existing names - but if that's what you mean, then say so (and 
explicitly address what the __xstat etc. interfaces would look like).

There is the matter of time interfaces used internally in glibc.  Just as 
glibc uses the stat64 interfaces internally (instead of defining 
_FILE_OFFSET_BITS=64 when glibc is built, because the redirections that 
implies would be problematic for building the 32-bit function variants), 
so I suppose glibc would internally use e.g. __clock_gettime_time64 when 
it needs to get a timestamp (and all glibc-internal uses of affected 
functions, including stat functions, would need reviewing to convert them 
to the new forms).  (When building for a 64-bit architecture, such calls 
would then need to be remapped back to the functions that actually exist 
in glibc.)

The claim "On some architectures, time_t is already 64-bit wide even 
though it still contains a signed value ranging from -2**31 to (2**31)-1. 
Introducing 64-bit support should only change the range from -2**63 to 
(2**63)-1." seems misleading.  On 64-bit platforms, there is no existing 
constraint that time_t contains a 32-bit value, and nothing for 64-bit 
support to fix in that regard; values may be arbitrary 64-bit values 
already.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Second draft of the Y2038 design document

[Arnd Bergmann]

On Thursday 28 January 2016 21:13:55 Joseph Myers wrote:
> I don't think the classification of whether symbols are "Y2038-sensitive" 
> is useful.
> 
> The relevant question is: does the ABI to a function involve time_t, 
> whether directory or indirectly (e.g. through struct stat)?  If it does, a 
> separate version is needed for _TIME_BITS=64.  That includes functions 
> involving relative timestamps.  And the notes "3. Regardless of the time_t 
> size, the function may not return a time_t value beyond Y2038." and "4. 
> Regardless of the time_t size, the function may not accept an time_t input 
> value beyond Y2038." simply seem wrong - functions should accept, and be 
> able to return, arbitrary valid time_t values.

The only example I can think of that is limited in this way is utimes
and kstat operating on file systems that cannot store time stamps beyond
2038, e.g. ext3. Setting a timestamp to a later date on such a file system
currently has undefined behavior (wraparound in some way) and we are
in the process of changing the kernel so it can instead either clamp
the values to the minimum/maximum representable times, or return an
error (the exact policy is not decided yet, but it should become
deterministic).

> The claim "On some architectures, time_t is already 64-bit wide even 
> though it still contains a signed value ranging from -2**31 to (2**31)-1. 
> Introducing 64-bit support should only change the range from -2**63 to 
> (2**63)-1." seems misleading.  On 64-bit platforms, there is no existing 
> constraint that time_t contains a 32-bit value, and nothing for 64-bit 
> support to fix in that regard; values may be arbitrary 64-bit values 
> already.

Right, this is not architecture specific, just a couple of bugs in kernel
interfaces that are currently limited to 32-bit times internally. This
includes mostly file systems, but also some device drivers and network
protocols. In many cases, the internal (network, hardware, firmware, ...)
representation is an unsigned 32-bit number, so the overflow will not
happen until 2106.

	Arnd

Re: Second draft of the Y2038 design document

[Joseph Myers]

On Fri, 29 Jan 2016, Arnd Bergmann wrote:

> On Thursday 28 January 2016 21:13:55 Joseph Myers wrote:
> > I don't think the classification of whether symbols are "Y2038-sensitive" 
> > is useful.
> > 
> > The relevant question is: does the ABI to a function involve time_t, 
> > whether directory or indirectly (e.g. through struct stat)?  If it does, a 
> > separate version is needed for _TIME_BITS=64.  That includes functions 
> > involving relative timestamps.  And the notes "3. Regardless of the time_t 
> > size, the function may not return a time_t value beyond Y2038." and "4. 
> > Regardless of the time_t size, the function may not accept an time_t input 
> > value beyond Y2038." simply seem wrong - functions should accept, and be 
> > able to return, arbitrary valid time_t values.
> 
> The only example I can think of that is limited in this way is utimes
> and kstat operating on file systems that cannot store time stamps beyond
> 2038, e.g. ext3. Setting a timestamp to a later date on such a file system
> currently has undefined behavior (wraparound in some way) and we are
> in the process of changing the kernel so it can instead either clamp
> the values to the minimum/maximum representable times, or return an
> error (the exact policy is not decided yet, but it should become
> deterministic).

The main point here is that there is no glibc issue - glibc just passes 
64-bit time_t values to / from the kernel and it's the kernel's job to 
handle things appropriately if there are limitations from e.g. 
filesystems.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Second draft of the Y2038 design document

[Arnd Bergmann]

On Thursday 28 January 2016 20:41:14 Albert ARIBAUD wrote:
> Hi all, and a happy New Year while we're still in January.
> 
> I have produced a second draft of what will eventually become the Y2038
> design document:
> 
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=55
> 
> Hopefully, all comments from previous round have been taken 
> Questions, notes, comments, corrections can be appended to the document
> and/or discussed here.

Thanks a lot for the update!

I hope to follow up on the kernel side with new patches soon. For now,
the most important unsolved question is how the kernel headers should
interface with libc for the added structures and interfaces.

First of all, for interfaces in which the kernel needs to behave
differently based on the time_t definition, there needs to be a
macro that the kernel headers can check for, so the user side can
pass the right constants. One example would be asm/socket.h setting

#if (_TIME_BITS != 64) || (__BITS_PER_LONG != 32)
#define SO_TIMESTAMP            29
#else
#define SO_TIMESTAMP            53
#endif

so an application can ask for either an 8-byte timeval or a 16-byte
timeval to be copied into the buffer.

Should the kernel rely on the glibc-specific "_TIME_BITS" for this,
or do we define some other macro that the kernel can test for?
There are probably a few dozen such interfaces, mostly ioctl commands
that predate the _IOR/_IOW macros.


A second point is the definition of new data structures. My current
set of headers define additional __kernel_time64_t, __kernel_timespec,
__kernel_rusage, __kernel_stat, __kernel_timex, and __kernel_itimerspec.
This convention is not used today for structure, but is consistent
with the typedefs we have for other things (__kernel_off_t,
__kernel_time_t, ...) and avoids namespace conflicts. In all the above
examples, the new structure is identical between 32-bit and 64-bit
architectures. [background: this lets us have a common syscall
implementation for 64-bit and new 32-bit interfaces, while the
existing 32-bit interfaces are now handled through the optional
"compat" layer that is again shared between 32-bit and 64-bit
kernels and handles old 32-bit user space].

Does this work ok for glibc?


	Arnd

Re: Second draft of the Y2038 design document

[Joseph Myers]

On Fri, 29 Jan 2016, Arnd Bergmann wrote:

> Should the kernel rely on the glibc-specific "_TIME_BITS" for this,
> or do we define some other macro that the kernel can test for?

Note that _TIME_BITS would not be tested directly in most glibc headers; 
it would be tested in features.h and used there to define __USE_* macros.  
(This is an observation, not an answer to your question.)

> __kernel_time_t, ...) and avoids namespace conflicts. In all the above
> examples, the new structure is identical between 32-bit and 64-bit
> architectures. [background: this lets us have a common syscall
> implementation for 64-bit and new 32-bit interfaces, while the

To reiterate on identical structures: where nanoseconds are involved in 
struct timespec or anything else where POSIX requires "long" to be the 
type, it's a pain for glibc if the kernel treats them as a 64-bit value 
when coming from a 32-bit process, as opposed to a 32-bit value with 32 
bits of padding, because then glibc needs to copy user-provided structures 
and sign-extend the nanoseconds value before passing it to the kernel.  
(But for 64-bit processes, correct error checking requires that the value 
be treated as 64-bit.)  (This doesn't apply to timeval because that uses 
suseconds_t for microseconds.  But I'd also suppose that syscalls 
involving timeval would generally be considered deprecated and the 64-bit 
replacements would be using timespec.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Second draft of the Y2038 design document

[Arnd Bergmann]

On Friday 29 January 2016 15:40:13 Joseph Myers wrote:
> On Fri, 29 Jan 2016, Arnd Bergmann wrote:
> 
> > Should the kernel rely on the glibc-specific "_TIME_BITS" for this,
> > or do we define some other macro that the kernel can test for?
> 
> Note that _TIME_BITS would not be tested directly in most glibc headers; 
> it would be tested in features.h and used there to define __USE_* macros.  
> (This is an observation, not an answer to your question.)

After thinking some more about it myself, I concluded that it should
be something other than _TIME_BITS: If a program sets _TIME_BITS=64
in source code but then gets built against new kernel headers and old
libc headers, we end up with a 32-bit time_t and a kernel expecting
a 64-bit time_t, and that won't work.

This means the kernel has to check for a macro that gets set by
the libc. However, we then run into a problem if the kernel header
is the first (or only) thing that gets included by the user source
code, and the macro won't be defined before it is checked.

I don't see a method that works 100% reliably here to solve those
two problems together, but maybe you or someone else has an idea.

> > __kernel_time_t, ...) and avoids namespace conflicts. In all the above
> > examples, the new structure is identical between 32-bit and 64-bit
> > architectures. [background: this lets us have a common syscall
> > implementation for 64-bit and new 32-bit interfaces, while the
> 
> To reiterate on identical structures: where nanoseconds are involved in 
> struct timespec or anything else where POSIX requires "long" to be the 
> type, it's a pain for glibc if the kernel treats them as a 64-bit value 
> when coming from a 32-bit process, as opposed to a 32-bit value with 32 
> bits of padding, because then glibc needs to copy user-provided structures 
> and sign-extend the nanoseconds value before passing it to the kernel. 

Right, I'm well aware of this problem and I have no good answer here.
For the system calls that pass a timespec into the kernel (clock_settime,
clock_nanosleep, timer_settime, timerfd_settime, pselect6, ppoll,
io_getevents, recvmmsg, mq_timedsend, mq_timedreceive, semtimedop,
utimensat, rt_sigtimedwait and futex to be exact), we need some code
that sanitizes the input by clearing (sign-extending is not strictly
needed here but would not hurt) the upper 32 bits of the tv_nsec
field in the 64-bit structure.

This code can be either in glibc or in the kernel, and it's equally
ugly in both cases. The problem for the kernel is that we end up with
either an additional set of 16 system call entry points, or a runtime
check each time we copy a timespec into the kernel to see whether
we have a 32-bit or 64-bit task in order to correctly reject
invalid data.

My current patch series implements the runtime check method in the
kernel, but I expect to see requests to move the special case into
libc.

> (But for 64-bit processes, correct error checking requires that the value 
> be treated as 64-bit.)  (This doesn't apply to timeval because that uses 
> suseconds_t for microseconds.  But I'd also suppose that syscalls 
> involving timeval would generally be considered deprecated and the 64-bit 
> replacements would be using timespec.)

Correct: no system call passing timeval is currently allowed on a 32-bit
task when the kernel is configured with 32-bit time_t disabled.
For struct timex and struct rusage, there is still the open question
about how we want to handle them, as they embed a struct timeval.
At the moment, the replacement structures contain a different structure
with timeval semantics but a separate definition (struct
__kernel_timex_timeval and struct __kernel_rusage_timeval).

	Arnd