Hacker News Reader

Comment by ncmncm | Hacker News Reader

Meanwhile, the unsigned 32-bit count of seconds (also) since 1970 used in pcap output from tcpdump, and used universally throughout the financial industry with no hint of a move away from it, will not roll over until 2106. If they are still in use then, code will interpret small values as implying a time after 2106, rather than as an ancient historical time before 2000.

It is hard to know why anybody thought it so urgent to go to 64-bit seconds counters for internal use in the kernel.

View on HN

> Meanwhile, the unsigned 32-bit count of seconds (also) since 1970 used in pcap output from tcpdump, and used universally throughout the financial industry with no hint of a move away from it, will not roll over until 2106. If they are still in use then, code will interpret small values as implying a time after 2106, rather than as an ancient historical time before 2000.

The format would need to change before 2106, because I'm pretty sure that the time is stored as a big-endian encoded value -- to expand it requires changing the format.

There really is nothing revolutionary about using an unsigned value, it just delays the problem by 80 years. Yeah, it's not something we'll have to worry about but our (great-)grandkids will.

> It is hard to know why anybody thought it so urgent to go to 64-bit seconds counters for internal use in the kernel.

There are many digital infrastructure projects which are planning to ship today's Linux for the next few decades (think things like traffic lights, as is the case in Japan). Fixing the 2038 problem now is necessary, because those deployments won't be updated until it's too late.

But more importantly, the UAPI used to represent time as a 32-bit integer so it's necessary to replace those syscalls with new versions -- and you need to give enough time for userspace to migrate. The same problem of deployed software equally applies here. And if you're going to fix the UAPI you might as well fix the problem entirely.

The pcap-ng format uses 64-bit timestamps and has replaced pcap in Wireshark/dumpcap at least. It sounds like tcpdump supports reading but not writing pcap-ng.

https://pcapng.github.io/pcapng/ https://wiki.wireshark.org/Development/PcapNg

> It is hard to know why anybody thought it so urgent to go to 64-bit seconds counters for internal use in the kernel.

I routinely encounter systems running 15-20 year old kernels. Given that, NOW is the time to fix the 2038 problem.

Note that 2106 is about 86 years from now — quite a bit more than 15-20.

Also, 20 years ago was before the Linux 2.4 kernel. You encounter systems running Linux 2.2 routinely?!

There's at least a couple of reasons that doesn't apply.

Software projects don't develop linearly. 20 years ago the Linux kernel was 8 years old, today it's 28 years old. The motivation to upgrade the relatively mature 2020 kernel will be much less than that to upgrade the immature 2000 kernel.

And perhaps the biggest one - computers have changed. 20 years ago a PC that could run Linux was a big power hungry thing. Today it's the size of a box of matches. Embedded Linux PCs with limited upgrade paths are everywhere today.

When I worked on satellites (stopped in 2015) we'd routinely use electronic test equipment which was running an embedded version of Windows 98. Given that the stuff shipping today is even further down the maturity curve, I think it's almost certain that it'll be used in 20 years (if it still works).

Early versions of 2.6 and 2.4, release >= 15 years ago.

15-20 year old kernels are probably very insecure, what contexts are you seeing such old systems in?

People aren't really concerned about the security of their non-internet connected HVAC controller or elevator. If it's in the wall people don't really think about it or update it.

And in cases where it doesn't have any communication mechanisms with the outside world, telling it its 1990 again in 20 years isn't going to be a problem.

Yah the time on the thermostat will be wrong, but if no one has upgraded it in that long, its probably ok, put a piece of tape over it.

Mostly embedded, industrial systems, medical devices, set-top boxes and home routers. You connect to the serial port or gain access by other means and most of the time you are greeted by ancient versions. It gives me the chills.

> It is hard to know why anybody thought it so urgent to go to 64-bit seconds counters for internal use in the kernel.

I would like to know if there's a better explanation, but at least one reason is: time_t is by C standard suppressed to be able to represent real time - this may include past and future. You definitely want it 64b on the userland side. But once you do that, you either need to do careful conversation everywhere in kernel/user boundary, or use 64b in both.

In some circumstances a rolling window will work. But for generic timekeeping, the files and records we have now are not going away. You can use unsigned numbers to delay the problem, but if you change the interpretation of small values you are going to break many many things.

A rolling window probably adds more complexity and heuristics than adding a few bits once.

This attitude blows my mind. There have been comments on HN, and for that matter by people I actually know, that covid isn't a problem because only a few people have it (heard that less than 2 weeks ago, just 1 day before UK lockdown started).It's as if they cannot see the future and they literally have to crash into something before they acknowledge it exists. That kind of blindness will kill a lot of people. I just don't understand it.

Covid is a poor metaphor for this. Time_t is perfectly observable and predictable and approaches linearly. 2106 is a long time away.

time_t is also used in code for relative time and that has to be signed.

86 years ought to be enough for anybody!

How old are you tho?

Reply on news.ycombinator.com