整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

一直以來，操作系統(tǒng)的「時間、日期、時區(qū)」，是讓很多程序員在開發(fā)程序時比較敏感與特別關(guān)注的問題。

還記得即將步入 2000 年的“千年蟲”（Year 2000 Problem，簡稱“Y2K”）事件，由于早期的計算機配置比較低，那時為了節(jié)省空間就把年份只用后兩位數(shù)表示，如 1999 就表示為 99，導(dǎo)致新千年時電腦把 2000 年認為是 1900 年，出現(xiàn) Bug，進而引發(fā)各種各樣的系統(tǒng)功能紊亂甚至崩潰。

2012 年，有用戶發(fā)現(xiàn)低內(nèi)核版 Linux 開啟 NTP 服務(wù)器會遇到閏秒 Bug，導(dǎo)致服務(wù)器重啟。

2016 年，很多網(wǎng)友“作了一把”，將 iPhone 的日期設(shè)置到 1970 年 1 月 1 日，無意中觸發(fā)系統(tǒng) Bug，一時間導(dǎo)致 iPhone 重啟失敗，手機直接變板磚。

就在近日，一個新的關(guān)于時間 Bug 出現(xiàn)在 Windows 系統(tǒng)中。據(jù) Ars Technica 報道，有一位挪威數(shù)據(jù)中心的工程師 Simen 遇到了一個令人費解的時間 Bug， 它會導(dǎo)致 Windows Server 突然將系統(tǒng)時鐘重置到未來 55 天。

時間 Bug 帶來的混亂

事實上，這并不是 Simen 第一次遇到這個問題。

在去年 8 月，Simen 曾遇到過類似的錯誤，當時一臺運行 Windows Server 2019 的機器將時鐘重置到了 2023 年 1 月，但過了沒多久又自動跳回來了。

后來，直到事件日志被清除后才發(fā)現(xiàn)這一問題，但那時無法分析具體是什么原因?qū)е碌摹?/p>

現(xiàn)在，他又在一臺運行 Windows Server 2016 的機器上遇到了這個問題。

對于普通用戶而言，時間的錯亂帶來的短暫影響也許可以忽略不計。但是對于工程師而言，卻是一個讓人崩潰的存在。

Simen 的主要工作是在 Windows Server 維護一個路由表（存儲在聯(lián)網(wǎng)計算機中的電子表格（文件）或類數(shù)據(jù)庫），這個路由表實時跟蹤手機號碼從一個運營商轉(zhuǎn)到另一個運營商的過程。

當服務(wù)器出現(xiàn)時間 Bug 時，系統(tǒng)時鐘跳到八周后，這就帶來一個不可估量的后果，譬如，此前尚未遷移的號碼被列入已經(jīng)遷移、已經(jīng)轉(zhuǎn)移的號碼被列為待處理狀態(tài)，整個都亂掉了。

無獨有偶

本來以為這只是一個特例，但是搜索一下，網(wǎng)絡(luò)上遇到這個問題的工程師不在少數(shù)。

去年，有一位名叫 Ken 的工程師也發(fā)現(xiàn)了類似的“時間跳躍”現(xiàn)象，當時在 2-3 臺服務(wù)器上，時鐘時不時會跳躍到幾周后，甚至有一次直接跳到了 2159 年。

據(jù) Ars Technica 披露，Ken 在一封郵件中寫道：“受此影響的服務(wù)器呈指數(shù)增長，越來越多。在 5000 臺服務(wù)器（虛擬機）中，我們總共有 20 臺左右的服務(wù)器（虛擬機）遇到過這種情況。這種情況通常發(fā)生在數(shù)據(jù)庫服務(wù)器上。當數(shù)據(jù)庫服務(wù)器在時間上發(fā)生跳躍時，就會造成嚴重破壞，只要服務(wù)器在時間上有如此大的偏移，備份也就無法運行。對于我們的客戶來說，這一點至關(guān)重要。”

除了 Simen 和 Ken 之外，追溯到 2017 年，一位 Reddit 用戶 zanatwo 發(fā)帖稱他在一所大學(xué)工作，某一天，其發(fā)現(xiàn)校園內(nèi)的幾臺 Windows 10 計算機開始出現(xiàn)錯誤的時間。這些計算機上顯示的時間 Bug 完全是隨機的，在某些情況下，他的設(shè)備時間直接跳到了 31 個小時之前。

通過深入分析，當時 Reddit 用戶發(fā)現(xiàn)，時間變化與 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits 中的 Windows 注冊表鍵相關(guān)。進一步的調(diào)查顯示，當一些人試圖訪問大學(xué)網(wǎng)站時，這些錯誤報告稱網(wǎng)站使用的有效 SSL 證書無效。

Windows 官方發(fā)布的功能惹了禍？

經(jīng)過排查之后，以上幾位工程師將罪魁禍首統(tǒng)一定位到了 Windows 上一個鮮為人知的功能—— Secure Time Seeding（簡稱 STS）中。

這是微軟在 2016 年引入 Windows 的功能，主要作用就是在 Windows 設(shè)備無法通過安全連接與時間服務(wù)器通信的情況下，改進對正確時間的記錄。簡單來看，這也是設(shè)備在斷電情況下也能保證準確的時間。默認情況下，這一功能在 Windows 系統(tǒng)及服務(wù)器下是打開的。

從工作原理來看，為確定當前時間，STS 會調(diào)用 SSL（Secure Sockets Layer）握手過程中包含的一組元數(shù)據(jù)。具體來說，這些數(shù)據(jù)包括：

ServerUnixTime，日期和時間表示法，顯示自 1970 年 1 月 1 日 00:00:00 UTC 時起已過去的秒數(shù)。

從遠程服務(wù)器 SSL 證書中獲取的加密簽名數(shù)據(jù)，顯示該證書是否已根據(jù)所謂的 "在線證書狀態(tài)協(xié)議 "機制被撤銷。

在發(fā)布這一功能時，微軟工程師在官方文檔中寫道，他們使用 ServerUnixTime 數(shù)據(jù)是 "假定它在一定程度上是準確的"，但在同一句話中又承認它 "也可能是不正確的"。

為了防止 STS 根據(jù)單個不同步遠程服務(wù)器提供的數(shù)據(jù)重置系統(tǒng)時鐘，STS 會隨機穿插 SSL 連接到多個服務(wù)器，以得出當前時間的可靠范圍。

然后，該機制會將 ServerUnixTime 與 OCSP（Online Certificate Status Protocol，在線證書狀態(tài)協(xié)議 ）有效期合并，以產(chǎn)生盡可能小的時間范圍，并為其分配置信度分數(shù)。

當分數(shù)達到足夠高的閾值時，Windows 就會將數(shù)據(jù)歸類為 STSHC（Secure Time Seed of High Confidence，高置信度安全時間種子）。然后，STSHC 用于監(jiān)控系統(tǒng)時鐘是否存在 "嚴重錯誤"，并對其進行糾正。

盡管 STS 內(nèi)建了檢查和平衡機制，以確保其提供準確的時間估計，但長期以來工程師遇到的“時間跳躍”事件表明，該功能有時會做出誤差數(shù)天、數(shù)周、數(shù)月甚至數(shù)年的胡亂猜測。

在 Ars Technica 報道的文章中，其分享了來自工程師 Ken 遇到時間跳躍時的具體截圖。

第一張圖片中的選定行上方的 "預(yù)計安全時間 "條目顯示，Windows 預(yù)計當前日期為 2023 年 10 月 20 日，比系統(tǒng)時鐘顯示的時間晚四個多月。然后，STS 會更改系統(tǒng)時鐘，使其與"目標系統(tǒng)時間 "中顯示的錯誤的預(yù)計安全時間相匹配。

第二張圖片顯示了類似的情況，其中 STS 將日期從 2023 年 6 月 10 日改為 2023 年 7 月 5 日。

 

在遇到這一問題后，Ken 和 Simen 都向微軟進行了反饋，遺憾的是，他們并沒有得到實質(zhì)性的回應(yīng)與解決方案。

微軟工程師個人曾發(fā)出警告：主動關(guān)閉 STS 功能

那要問有沒有解決方法，其實去年一位微軟 Windows 高級工程師 Ryan Ries 發(fā)過推文提供過用戶，其寫到“大家好，如果你們管理 Active Directory 域控制器，我想給你們一些非官方的建議，這完全是我的個人意見：在您的 DC 上禁用 w32time 的 STS?！?/p>

當有網(wǎng)友進一步詢問原因時，Ryan Ries 表示，「因為在它咬你的屁股之前，這只是一個時間問題」。

這也不禁讓人好奇，連微軟自家工程師都覺得這個功能有問題，為什么官方還有做保留。

就在眾人存疑時，微軟在給 Ars Technica 的一份聲明中寫道：

STS 功能是一種基于啟發(fā)式的計時方法，在某些軟件/固件/硬件計時失效的情況下也有助于校正系統(tǒng)時間。該功能已在所有默認 Windows 配置中默認啟用，并已證明在默認配置中發(fā)揮了預(yù)期功能。

每次部署的時間分配都是獨一無二的，客戶通常會根據(jù)自己的特殊需求來配置機器。鑒于 "STS"的啟發(fā)式性質(zhì)以及客戶可能使用的各種部署，我們提供了禁用該功能的選項，以滿足客戶的需求。我們的理解是，在客戶遇到 STS 問題的部署中，很可能存在獨特、專有、復(fù)雜的因素，而這些客戶并不能從目前實施的這一功能中受益。在這些個別情況下，我們只能建議在部署中禁用該功能。

具體來看，要禁用 STS，可以在受影響的機器上設(shè)置一個注冊表項。這是 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config 目錄中的 UtilizeSslTimeData 密鑰，其類型為 REG_DWORD。如果設(shè)置為 0，則停用 STS。如果設(shè)置為 1，則可以重新激活該功能。

STS 的異常，有沒有解決方案？

截至目前，似乎除了關(guān)閉此功能之外，并沒有太過合適的解決方案，因此，很多人對于微軟的回應(yīng)并不買賬。在 HN 上，網(wǎng)友也展開了激烈的討論，甚至有人吐槽：是時候應(yīng)該買塊手表來核對服務(wù)器上的時間了！

另外，有網(wǎng)友 @theqmann 分析認為，「這聽起來像是一種統(tǒng)計方法，如果在給定時間內(nèi)收到 N 個時間戳相似的數(shù)據(jù)包/連接，就會改變時鐘。我可以看到這樣一個問題：一臺 Windows Server 每分鐘全天候提供數(shù)千或數(shù)百萬個 OpenSSL 數(shù)據(jù)包，而它恰好隨機接收到 N 個數(shù)據(jù)包，這些數(shù)據(jù)包彼此非常接近，足以滿足統(tǒng)計閾值的要求。通過隨機跳轉(zhuǎn)，連續(xù)跳轉(zhuǎn)十多次時間都是有可能的」。

@jmuguy 則表示：

在我做 IT 人員的這些年里，Windows Time 是我處理過的最煩人的事情之一。注冊和取消注冊 w32time，嘗試不同的 NTP 服務(wù)器。試圖弄明白為什么域系統(tǒng)無法從 DC 獲取時間。這總讓人感覺很......愚蠢。在設(shè)備上設(shè)置正確的時間肯定沒那么復(fù)雜。事實證明，并不復(fù)雜，除非你使用的是 Windows 系統(tǒng)。有點諷刺的是，如今我唯一需要處理的 Windows 系統(tǒng)就是我的游戲電腦。它拒絕與 time.windows.com 同步。

除了 Windows 系統(tǒng)之外，還有人稱在 Linux 中也遇到了同樣的問題。

@nicolaslem 表示： 

我的 Linux 筆記本電腦有時也會遇到類似的問題，把電腦從睡眠中喚醒時，時間會跳到 2077 年。我猜這是硬件故障，因為它并不經(jīng)常發(fā)生，但一旦發(fā)生就會造成很大影響。我無法想象在生產(chǎn)服務(wù)器上發(fā)生類似情況會有多大影響。

你是否遇到過類似的問題？

原文鏈接：https://blog.csdn.net/csdnnews/article/details/132373095

————————————————

版權(quán)聲明：本文為CSDN博主「CSDN資訊」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/csdnnews/article/details/132373095