X
Home & Office

Thanks to a nasty GPSD bug, real-life time travel trouble arrives this weekend

On October 24, 2021, some time-keeping systems are going to take a trip back in time to March 2002, unless you update your GPSD programs.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

"Does anybody really know what time it is? Does anybody really care?"

Actually, if you use computers for pretty much anything, you do. Oh, you may not know it if you're not a system or network administrator, but security, identification, networks, everything that makes the internet go depends on accurate time-keeping. Some systems rely on Global Positioning Systems (GPS) appliances and the GPSD daemon to tell the exact time, and a nasty bug's been uncovered in GPSD that's going to pop up on October 24, 2021. If left unpatched, it's going to switch your time to some time in March 2002, and your system will crash with a resounding kaboom. Here's how it works.

First, Earth time is not absolute. Earth's spin speed varies in response to geological events. The International Earth Rotation and Reference Systems Service (IERS) tracks this, and every few years, it adds a leap-second to the year. This is done to Coordinated Universal Time (UTC), which is the standard universal time system. UTC is used by the internet's Network Time Protocol (NTP). In turn, NTP is used to keep all internet-connected devices in sync with each other.

How does NTP know what time it is? By synchronizing NTP servers with atomic clocks. NTP is based on a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio, or modem. Stratum 2 (secondary) servers are synchronized to stratum 1 servers and so on. Usually, NTP clients and servers connect to Stratum 2 servers. 

So far, so good, but how do stratum 1 servers sync up with clocks? Many of them use GPSD. This service daemon monitors one or more GPSes for location, course, velocity, and for our purposes, the most important element it tracks is time. This code, which is a mix of a linkable C service library, a C++ wrapper class, and a Python module, has, like all programs, its fair share of bugs.

Recently it was discovered that a bug in the time rollback (aka "GPS Week Rollover") sanity checking code scheduled for November 2038 will instead trigger this Sunday, and cause 1,024 to be subtracted from the October 24, 2021 week number. In other words, a lot of computers are in for a quick, sharp visit to March 2002.

This will be ugly. Or, as Stephen Williams, who uncovered the bug put it, "I have a feeling that there will be some 'interesting moments' in the early morning when a bunch of the world's stratum 1 NTP servers using GPSD take the long strange trip back to 2002."

GPSD maintainer Gary E. Miller has acknowledged the problem, and a fix has been made to the code. To be exact, the fix is in August 2021's GPSD 3.23 release. So, what's the problem if the fix is already in? 

Well, there are two problems. First, it won't be backported to previous releases. If you're still using an older version, you may be out of luck. Second, as Miller observed, not all distros "pick up GPSD updates or upstream their patches. [This] is a very sore spot with me." So, just because your operating system is up to date does not mean that it will have the necessary GPSD fix. Miller suggests that you check it and do it yourself: "I [am] gonna fall back on Greg K_H's dictum: All users must update."

Oh, wondering what the mysterious root cause of all this commotion GPS Week Rollover? It's a legacy GPS problem. The GPS signal GPS week number uses a 10-bit code with a maximum value of 1,023. This means every 19.7 years; the GPS week number rolls over to zero. Or, as Miller noted, "This code is a 1024 week time warp waiting to happen."

So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble. Otherwise, well, remember all that chatter about how awful Y2K was going to be? Y2K, as the end of the tech world, fizzled because we did all the right things. This one may not be a global problem, but I can easily see many companies ending up in a world of trouble if they don't make sure their time-keeping is properly patched. 

Related Stories:

Editorial standards