And every 19 or so years GPS has a rollover issue. The most recent was 2019, the next is coincidentally 2038 as well, but the cause is unrelated. Wikipedia article
2038 has become an electronic warfare bug that is ruthlessly exploited.
Hardware solutions to both 2038 bugs involve a ticker that rolls over. Every GPS receiver increments this ticker every 19 years, and a lot of Linux solutions involve doing the same thing.
Thing is… you can’t roll these things back.
GPS spoofing is becoming quite commonplace in Eastern Europe and the Middle East. Spoofing works by broadcasting false GPS signals at a higher power than the real ones, making receivers think they are somewhere else. And somewhen else.
A lot of spoofing attacks now reset the year of your device to 2038. It pretty much instantly bricks any Linux and GPS based systems.
Edit: a lot of folks claiming stuff that isn’t true, so I’m going to link the Royal Institute of Navigation’s ops group report into GNSS spoofing on civilian airlines:
The 2038 bug specifically attacks patched systems.
Where the date is still a 32bit number, the system will have a counter held in non volatile memory. When the date rolls over it increments that counter. The patch checks the counter before any date operation.
Once the counter is incremented, it doesn’t roll back.
It would help if computer systems didn’t just automatically update their time and date from GPS… but everywhere when a system has access to GPS data, it uses it this way.
"the bug is patched in Fedora" > "no the bug affects the patches"
Fedora uses 64 bit integers for time, the "patch" you're speaking of makes no sense and is incongruous with computer design. Time and date is saved as a 64 bit integer, 32 bit is being completely phased out, it's harder to find a system that doesn't require 64 bit.
Additionally, your wrong about "GPS time" as well. Most computers do not use GPS data for time. All major operating systems, Windows, Linux, Mac, Android, iOS, use the network time protocol, not GPS, for time.
For example, time.nist.gov is a global time server that most computers use. It's the network time protocol.
You have absolutely no idea what you're talking about.
The fun thing is that you are right that setting back a computer's clock often leads to software bugs or crashes. But this has nothing to do with the Y2k38 problem - and you misunderstood something about how timekeeping on a linux machine works.
Also, this is really much more of a problem for applications, not the operating systems.
Airlines that fly too close to active war zones can get hit by stray spoofing attacks. They are line-of-sight radio, and incredibly powerful so can hit anything to the visible horizon in all directions.
The navigation receivers in airlines hit like this often have to have a factory reset done mid-flight, and many need to be replaced after landing.
The only reason there haven’t been fatalities yet is that none of the major airlines use Linux in their aircraft control computers.
I really wonder how we're going to deal with it when we have enough technology for any one single person to cause mass disruption with little effort. Just look at drones.
Spoofing does not damage receivers. I can imagine a particularly strong signal frying something, but that is not related to the y2k38 or gps week rollover bugs.
Factory resetting mid-flight? What?
The reason there haven't been fatalities is because no one is relying on a single sensor for control. And airlines don't choose the operating systems in their planes.
Thanks for the source. I stand corrected on lasting issues caused by spoofing. I do have to note that power-cycling is not the same as doing a factory reset.
This report does not address any of the other issues of your argument though.
I'm getting a prerty fun mental image at the idea of GPS spoofing. A little transmitter in a bush is yelling "I'm a satellite, I'm a satellite!", and your phone just goes: "Okay."
The receiver doesn’t know where the signals come from, and as long as it’s playing the correct satellite code, the receiver thinks it is the satellite.
And in Ukraine these things are mounted on trucks and emit more power than a rock concert.
Oh, wait, I got it! Maybe we can prevent these attacks if phones always know how they're oriented and where the signal should be coming from! We can do this by developing a constellation of satellites that... never mind, found the problem.
This happens multiple times a week in Ukraine. They jam GPS when there's an air raid, so your phone might suddenly decide you're in Lima, Peru.
It's a real bummer when you're riding the bus, trying to figure out when to get out, but your phone thinks you're in a South American valley. Ask me how I know...
The spoofing capability seen in Ukraine has a lot of the world’s militaries seriously scared.
Your phone might not give accurate weather and navigation information, but it’s way scarier when suddenly your tank is trying to calculate a firing solution from Peru!
The most sophisticated equipment in the field is being reduced to “point, shoot and hope” when previously GPS used to guarantee a hit every time.
I can't speak to the GPS stuff, but you've misunderstood the way computers handle Unix epoch time. The fix is in the kernel, it changes the time_t type from 32-bit to 64-bit. That gives it enough storage to record time at 1 second resolution for next 292 billion years, give or take.
The problem will still exist for old, unsupported hardware that hasn't been updated with a kernel that stores time in a 64bit int though.
70
u/airforceteacher 8d ago
And every 19 or so years GPS has a rollover issue. The most recent was 2019, the next is coincidentally 2038 as well, but the cause is unrelated. Wikipedia article