
Approaching the kernel year-2038 end game - Tomte
https://lwn.net/SubscriberLink/776435/664f2f0b0b6fc9f5/
======
LeonM
I have been working in the embedded world for some time. What worries me is
that even new embedded systems come with ancient kernels and stdlibs, most of
which won't be y2k38 compatible.

Many of these devices will still be operating in 2038, but long forgotten.
Think HVAC control systems, kitchen appliances, security systems, etc. Cars,
trains, information signs, traffic lights, many of these public infrastructure
systems will fail.

And these systems are very, very hard to update, if possible at all. We'll be
having a lot of e-waste in 2038.

~~~
chungy
I wonder how many of these systems would really be sensitive to the clock
overflowing to 1901. HVAC, kitchen applications, information signs, traffic
lights... they all seem relatively low-risk to me. As long as things still
happen in regular intervals, it's hard to imagine a crisis. (I would be
surprised if many of these even have synced clocks in the first place, I can
imagine them happily thinking it's somewhere in the 1980s and nobody is the
wiser.)

~~~
DuskStar
Does your system need to connect to a service on the internet? Does that
service use an SSL cert?

If so, it almost certainly has a not-before time, and overflowing back to
January 1st, 1970 will be before that not-before time. And so any behavior
relying on that IoT device connecting to a service will fail.

~~~
artursapek
I certainly hope traffic lights are _never_ connected to the internet.

~~~
nopassrecover
I’d always assumed they must be connected to support the ability of fire
engines to setup route plans or the central traffic management teams to be
able to override light sequences.

I see now there are other novel ways of supporting preemption for emergency
vehicles, although I’m still unconvinced that’s what our city uses as the
lights often preempt several minutes in advance and from over a kilometre
away.

~~~
FireBeyond
Most US preemption devices are just a visible (and sometimes optional
infrared) stroke at 80Hz. Visibility to the sensor/receiver device is largely
subject to prevailing light (bright day, more challenging, night/shade, then
it's easy to pick out the strobe).

\-- fire/ems provider.

~~~
nexuist
Question, since I've always been curious about this: How difficult would it be
to make your own preemption device? Are such things available on online
stores?

I'm assuming it's illegal to use one obviously, but I wonder what precautions
are used to prevent unauthorized usage, if that can even be disclosed to the
public. What's stopping the average joe from getting one from Alibaba?

~~~
FireBeyond
Honestly, pretty little, other than the risk of being observed. There may be
systems that allow for authentication, but I've not seen them (though I'm not
an expert).

There is an encoding standard for prioritization that some larger systems use,
that mass transit may utilize, but can be overrode by Fire/EMS/LE.

------
hermitdev
The 32-bit Unix 2038 end has already been an issue in some fields. For
instance, in finance, it was already an issue in 2008 when calculating risk,
payments, etc on say a 30 year bond.

~~~
adtac
Aha, the real reason behind the 2008 crisis!

------
jzl
_" This may seem like a distant problem, but, as Tom Scott recently observed,
the year-2038 apocalypse is now closer to the present than the year-2000
problem."_

Wow, I knew it was approaching soonish, but that's an eye-opening way of
putting it.

I wonder how many pre-2000 kernel versions are being used in devices right
this moment.

~~~
BurningFrog
That doesn't change that it's a solid 19 years away.

~~~
ams6110
Exactly what programmers were saying in 1981.

~~~
jeremyjh
Were they wrong? y2k was a non-event, unless you were a consultant cashing in.

~~~
Dylan16807
"Fixing the brakes on my car was a non-event, unless you count the mechanic
cashing in."

~~~
jeremyjh
Routine automative work is a good analogy. There was programming work to do,
people did it in time, and life went on.

~~~
Dylan16807
Well don't insult the people that fixed it and kept it from being a giant
problem.

It wasn't a non-event, because it took a lot of effort to make everyone
_aware_ of the need to fix the bugs.

It's like routine maintenance except that every single device involved is
going to hit problems right about at the same time, with almost no signs of
trouble until the exact second it falls over. So it's not harder to fix, but
if it's not fixed then it hits vastly harder.

~~~
jeremyjh
I was one of those people fixing it. How is it insulting to say that the
biggest impact was the enrichment of the people working on it?

~~~
Dylan16807
"non-event unless you were cashing in" pretty strongly implies it wasn't
necessary.

------
maxander
“Supporting 32-bit time system calls after 2038” will serve future generations
as an example of the lengths that developers are supposed to go to in order to
ensure backwards compatibility, even in the face of apparent absurdity.

Alternately, it will serve as a joke about how scared everyone was of breaking
things written with our primitive and brittle 21st century programming
techniques.

~~~
hermitdev
Also, how "X" will always be enough. It May be sufficient for the foreseeabke
future, but software engineers are horrible about underestimating how long the
software we write will stick around.

Pretty sure I made some short sited decisions as an intern, and most of that
code is approaching 20 years old, and I bet it hasnt been fixed or rewritten,
because for the time being, it works.

------
rwmj
In other news there's a GPS epoch arriving this April:
[https://www.spirent.com/blogs/positioning/2018/january/gps-r...](https://www.spirent.com/blogs/positioning/2018/january/gps-
rollover-week)

------
sys_64738
It’s all thanks to hardworking software people that Y2K wasn’t.

~~~
jzl
Yeah, huge shout out to Initech specifically for their amazing work in that
field.

;)

------
ryanbertrand
We launched a crime based RPG game on iOS back in the day that had a
leaderboard which tracked in game net worth (cash, investments, etc).

I still remember the day we woke up to multiple emails and lawsuit threats
from our top player whose net worth suddenly went negative on the leaderboard.

Our players were very competitive and loved pushing the boundaries by trying
to find vulnerabilities, shortcuts, etc so we assumed the worst and thought we
had a bug in our system! Turned out to be our JSON parsing library was using
integerValue on our NSNumber instances causing the ints to overflow. It was a
tough week waiting for Apple to review the app while our players lost faith in
us.

Lesson learned :)

(Luckily the player and our community was understanding and stay around)

~~~
teacpde
I like stories like this. Finding where the overflow happens could be a lot of
fun. How did you figure it out? Did it take a long time?

------
bloak
Just for fun, I installed Debian i386 unstable under QEMU and set the date
with date -s '2038-01-19 03:14'. The time rolled over to 1901.

Then I tried using git. It was badly broken: on 32-bit systems, git 2.20.1
seems unhappy with dates before 1970 or after 2038.

Will Debian 11 work after 2038 on 32-bit hardware, I wonder?

------
rurban
I really don't like the _NEW suffix, as in SO_TIMESTAMP_NEW, opposed to the
normal SO_TIMESTAMP64 naming scheme, as in the function names. But it renders
the existing names as old and outdated, so it does make some sense.

~~~
ge0rg
It only makes sense from a shortsighted "today's" perspective. What happens if
there is another API change? Do you call the new new suffix _NEWER? _NEWNEW?

~~~
rurban
Thanksfully 64 is the endpoint. "We'll never need 128bit time_t struct's!"
Famous last words. But really, we don't. We don't need to mix low precision
with high precision times, "one for all" . Calculating in ns does not make
sense in the year scale.

------
stesch
> Some of the final steps in this transition for the core kernel have been
> posted, and seem likely to be merged for 5.1.

This doesn't sound as good as they wanted it to sound. I thought they were
already save.

On the other hand, planned obsolescence could help and nobody is using 20 year
old kernels in 2038 anymore. Hopefully.

~~~
dtech
This is only for 32-bit systems. 64-bit systems have always used a 64-bit
timestamp.

The difficulty is that the ABI defines a 32-bit timestamp on 32-bit kernels so
that can't easily be changed without breaking backwards compatibility. That's
what this post is about.

So for desktops and servers this has been solved for years already. I don't
know how prevalent 32-bit is in embedded versus 64-bit.

~~~
keeperofdakeys
The popular Raspberry Pi platform only started shipping with a 64-bit ARM cpu
in 2016, and ARM chipsets with 64-bit support only started appearing around
2012/2013\. So I'd expect many new embedded platforms to continue using 32-bit
systems well into the next decade.

~~~
akiselev
There are still probably billions of devices made each year with 8 bit
microcontrollers that are decades old designs. We won't be free of 32bit ARM
until the turn of the century.

------
brodouevencode
I found this article better explains the issue:
[https://fossbytes.com/year-2038-problem-linux-
unix/](https://fossbytes.com/year-2038-problem-linux-unix/)

------
seotut2
Hopefully, this will be humanity's last problem of this kind.

Or, now that I think of it, hopefully it won't be.

------
ilovetux
How much time does moving to 64 nits buy us? it's likely considerable, but I
cant help but imagine a time when we have to address this problem for a third
time. It seems to me like a more robust solution is possible.

~~~
omegaham
The 64 bit clock will overflow about 292 billion years from now. That's long
enough for me.

\---

Worrying about 64-bit time overflow is like worrying about IPv6 address
exhaustion.

~~~
monocasa
> Worrying about 64-bit time overflow is like worrying about IPv6 address
> exhaustion.

And for those following along at home IPV6 is a 128 bit value. ~2^93 is enough
to individually address every subatomic particle on Earth.

~~~
segfaultbuserr
> ~2^93 is enough to individually address every subatomic particle on Earth.

IPv6 address exhaustion is very unlikely, but it's more likely than some may
have thought about.

Only 64-bit of the 128-bit address space was fully utilized, it means the
utilization rate is less than 0.0000000000000000055%. And no, it's not a bug,
it's a feature. The huge address space was intended to make address
assignment, configuration, and routing easier. That is, in the real world, the
first 64-bit part becomes the network identifier, and the last 64-bit becomes
the device identifier. Ideally, everyone's home, business, institution,
datacenter, etc, will get a unique, globally routable 64-bit network prefix.

So no, every subatomic particle on Earth will not get its own IPv6 address.
But, everyone of the 7 billion people on Earth can have prefixes for their
263,524,915 personal computer networks.

