LWN：GPSD 中的時間溢出！
關注了就能看到更多這么棒的文章哦～
A GPSD time warp
By Jake Edge
August 4, 2021
DeepL assisted translation
https://lwn.net/Articles/865044/
GPSD project，提供了一個跟 GPS 設備進行通信的 daemon 程序，用來獲取這些傳感器提供的位置信息。但是 GPS 衛(wèi)星本身也提供了高精度的時間信息，GPSD 可以同時提取這些信息來供網絡時間協(xié)議（NTP，Network Timer Protocol）服務使用。不過，GPSD 代碼中的一個 bug 會導致 10 月份的時候出現(xiàn)時間倒退，如果受影響的 NTP 服務在那之前沒有及時更新的話很可能會面臨破壞。
可以說問題的根本原因是 GPS week-number 的滾動實現(xiàn)，因為在最初的 GPS 協(xié)議中，只有 10 個比特用于表示 week number。10 個 bit 的話，在數(shù)到 1023 后就會溢出，所以只能表示 19.6 年左右。由于 GPS 的時間紀元（epoch）是從 1980 年初開始的，所以已經發(fā)生了兩次翻轉（rollover）事件（分別在 1999 年和 2019 年）。在 2038 年之前不應該再有了，但是 GPSD 的一些合理性檢查代碼中的一個 bug 將導致在 2021 年 10 月 24 日的時候會從 week number 中減去 1024。這樣一來就會變回到 2002 年 3 月了，誰都不希望看到這個結果。
這個問題是由 Stephen Williams 在 7 月 21 日報告出來的。它對 GPSD 的 3.20-3.22 版本都有影響，也就是從 2019 年最后一天開始到現(xiàn)在的所有版本。即將發(fā)布的 3.23 版本（最早會在 8 月 4 日發(fā)布）將會 fix 這個問題，但人們需要把所有相關的服務器上的 GPSD 都更新到這個版本。有人擔心如果 NTP 服務器管理員沒有收到這個消息的話，很可能會在十月份的時候碰到這件倒霉事。
bug report 中貼出了相關的代碼。在 gpsd_gpstime_resolv() 函數(shù)中使用了一個錯誤的常量值：
/* sanity check week number, GPS epoch, against leap seconds
* Does not work well with regressions because the leap_sconds
* could be from the receiver, or from BUILD_LEAPSECONDS. */
if (0 < session->context->leap_seconds &&
19 > session->context->leap_seconds &&
2180 < week) {
/* assume leap second = 19 by 31 Dec 2022
* so week > 2180 is way in the future, do not allow it */
week -= 1024;
GPSD_LOG(LOG_WARN, &session->context->errout,
"GPS week confusion. Adjusted week %u for leap %d\n",
week, session->context->leap_seconds);
}
這段代碼可能有點難讀懂，因為比較的順序與通常的寫法相反。也許這是 Yoda notation 寫法，不過這種寫法一般也不會用來進行這些大于、小于的比較。其他地方計算出來的 week number 都考慮到了 rollover 問題，跟 2180 進行了比較，不過這并不是 comment 里面所說的 "way in the future" （很久之后），而是實際上對應于 10 月 24 日。這個檢查顯然是為了避免出現(xiàn)一些虛假的 regression，正如 comment 里第一句所說。
GPSD 的維護者 Gary E. Miller 承認了這個問題，他說他本想使用 2022 年 12 月 31 日的 week number，但在計算時出現(xiàn)了錯誤，算成了 2180。這部分代碼事實上還 "預測 " 在 2022 年底會增加一個閏秒，但是，正如 Williams 指出的，這個預測并不正確。此外，其實不久之后會出現(xiàn)負閏秒（negative leap second），但寫代碼的時候并沒有考慮到這一點。
Miller 說，直到 2020 年為止，"閏秒一直是可以可靠預測的"，但最近發(fā)現(xiàn)地球旋轉速度增加，因此這一點出現(xiàn)了變化，也增加了出現(xiàn)負閏秒的可能性。然而，大家談論的代碼是針對 regression test，而不是實時處理 GPS 數(shù)據的代碼，這是問題的另一部分。
7 月 24 日，Miller 提交了一個 fix，從 live path 中刪除了錯誤判斷條件。但是這個 fix 只出現(xiàn)在 3.23 版本中，不會被 backport 到以前的版本中，至少 GPSD project 的規(guī)矩是這樣。雖然各大發(fā)行版可能會做這件事，但他并不相信這樣足以讓事情變好：
gpsd 沒有足夠的志愿者來維護 "多個 branch"。一些發(fā)行版試圖 cherry-pick 一些 patch，但通常會使事情變得更糟。
這個 bug 已經在 gpsd-dev 和 gpsd-users 的郵件列表中公布過了。所以幾個發(fā)行版的打包發(fā)布人員已經看到了。他們做什么我們就無法控制了。
3.23 版將在一周內發(fā)布。
[…] 發(fā)行版不接受 gpsd 的 update 版本，也不把他們的改動推送回 upstream 上，這是我感到非常不爽的一個問題。
Williams 在他正在維護的 GPSD 3.19 的 branch 中發(fā)現(xiàn)了這個錯誤。針對 3.20 進行的一些修改被 backport 到該分支中，然后他對代碼進行測試的時候發(fā)現(xiàn)了這個問題。但 Miller 認為，發(fā)行版和其他人都應該運行最新版本，而且當 3.23 一旦可用，他們就應該升級到 3.23，因為每個新版本都修復了一些與安全有關的錯誤。當然，這與其他項目的立場有些類似，比如 Linux 內核項目，Miller 指出："我[要]贊同 Greg K_H 的口號：所有用戶必須更新。"
會議還討論了負閏秒的問題。Williams 說，在合入了 Miller 的 fix 后，不再存在之前那種問題了，而且哪怕是之前那些有問題的代碼，碰到負閏秒也不會有什么大的影響。他只是碰巧注意到這個有問題的代碼沒有預計到負閏秒的可能性。目前還沒有人發(fā)現(xiàn)如果負閏秒時會有什么問題，不過確實可以做更多的測試來確認。
正如 Miller 所說，GPS 協(xié)議的設計者比較短視地 "植入" 了一個僅有 20 年的 rollover 周期。Miller 的說法是："從設計上就決定了 GPS 每隔 1024 個星期就會發(fā)生一次 rollover"。最近出現(xiàn)的 CNAV 協(xié)議（目前尚未部署到所有 GPS 衛(wèi)星上）將 week number 升級到了 13 位，這就會給我們一個 157 年的重復周期，看起來更加安全一點，盡管第一次溢出也會在 116 年后的 2137 年發(fā)生。到那時，很可能會有其他的導航技術（和時間技術），或者在某個地方再擠進幾個 bit。
如果希望在 10 月中旬以后仍然能夠依靠 GPSD 獲得準確時間的話，就需要運行沒有這個 bug 的版本。在電影中，時間倒流很有趣，但對于在互聯(lián)網上分配時間的系統(tǒng)來說可就不那么有趣了。使用 GPSD 的 NTP 服務的話就必須升級，或者至少避免使用 3.20-3.22 期間的版本。
[感謝 David A. Wheeler 為我們介紹了這個問題。]
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關注，關注 LWN 深度文章以及開源社區(qū)的各種新近言論～