[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.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”
    
    
More information about the TUHS
mailing list