[TUHS] The 2038 bug...

Michael Kjörling michael at kjorling.se
Thu Jan 7 04:20:42 AEST 2021


On 6 Jan 2021 12:08 -0500, from henry.r.bent at gmail.com (Henry Bent):
>> On recent Linux/i386 kernels it's actually 64 bits. In practice, only
>> users who are stuck with old i386 Linux versions will have a problem.
> 
> Do you happen to know what the cutoff is?  Are 2.6 kernels (still very
> common) safe?  3.x?  4.x?

I haven't dug particularly deeply, but unless I am missing something,
Debian Buster's 4.19 kernel seems to map `time_t` to plain `long`
regardless of architecture. I don't have an i386 architecture system
handy, but wouldn't that make it 32 bits wide on i386 & Co?

linux/time.h:

struct timespec {
        __kernel_time_t tv_sec;                 /* seconds */
        long            tv_nsec;                /* nanoseconds */
};

asm-generic/posix_types.h:

#ifndef __kernel_long_t
typedef long            __kernel_long_t;
typedef unsigned long   __kernel_ulong_t;
#endif
/* ... */
typedef __kernel_long_t __kernel_time_t;

Both from Debian's linux-libc-dev package, version 4.19.160-2, amd64
architecture.

If that's right, then I'd definitely expect anything 2.x and 3.x to be
unsafe, and 4.x to at best be suspect; so Dario's mention of 5.6
doesn't sound unreasonable as a first guess.

We've got maybe fifteen years before this starts to become a real
issue. Time to start working on those upgrade plans...

-- 
Michael Kjörling • https://michael.kjorling.semichael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”



More information about the TUHS mailing list