新年伊始，萬象更新，今天不發那些網絡安全新聞，聊聊輕松點的話題，給大家在元旦假期里解解悶。業內一直盛傳的Unix時間的雷，真的會讓全球電子設備癱瘓嗎？

昨天，幾個安全圈好友聚在一起喝酒，不知怎么就聊到了“千年蟲”的問題。當年開發計算機操作系統的那幫大神們親手埋下的雷，在時間的流逝下慢慢爆出了各種匪夷所思的安全BUG。千禧年Y2K的雷是Windows，而Unix的雷則是在2038年爆發。

Unix的雷是怎么埋下的？

話說再1969年，貝爾實驗室的大神Ken Thompson曾利用老婆回娘家的假期，開發了一個操作系統，它叫Unix。沒錯，就是咱們現在使用的那個Unix，開發它大概用了三周（夸張）。看來，老婆回娘家可以大幅提升已婚男人創造力，這在全球范是統一的。

在開發過程中，他遇到了一個嚴重的問題：如何在Unix中表示日期和時間？最簡單的辦法是用一個字符串來表示，例如1970-09-17 00:00:30.751，但這明顯不是最好的辦法。最后Ken決定用一個整數來表示日期和時間，也就是Unix 紀元時間，并將1970年1月1日00:00:00設定為開始時間。

所以Unix 系統的時間計算方法其實是用秒數來表示系統時間。換句話說當下的時間（2024年1月1日00:00:00）是從1970年1月1日00:00:00走過多少秒的時間，即系統時間 = 基準時間+秒數。感興趣的朋友，可以訪問time.is/Unix網站，可以知道從1970年1月1日00:00:00到現在一共過去了多少秒。

由于Ken將Unix時間確定為32位整數，這就導致一個很嚴重的系統BUG，32位的有符號整數最大值是2147483647（距離1970年1月1日00:00:00走過了2147483647秒），簡單換算下Unix時間為2038年1月19號 03:14:07 UTC，再往后就沒了。

一旦越過這個時間最大值，Unix系統時間將會在內部被表示為一個負數，并造成程序無法工作，因為它們無法將此時間識別為 2038 年，甚至還有可能調回到 1970 年。這讓很多人想起了千禧年的“千年蟲（Y2K）”事件，因此Unix系統時間問題也被稱為Y2K38。

當然這也不能完全怪Ken。畢竟那時候主流計算機還都是使用16位，所以使用32位整數來設定時間已經夠夠的了。在他看來，Unix系統能不能活到2000年都是個問題，更別提2038年。但誰能想到，Unix系統竟是如此的強悍，不僅可以和Windows相抗衡，還統治了服務器端的OS市場，在計算機操作系統的發展史上占有重要的地位，此后“簡潔，一致性，易使用”被很多開發人員奉為圭臬。

問題很嚴重嗎？

扯遠了。。

其實解決方案也不復雜，將32 位有符號整數修改成 64 位有符號整數（時間長度近300億）。目前Linux內核開始全面支持64位時間戳的系統調用，記得在升級之后看看原來的程序和庫是否使用32位編譯，如果是則需改成64位，否則依然會產生溢出問題。

雖然很多文章將這一問題描述地很嚴重，甚至會導致大部分電腦癱瘓無法工作。但我們認為，這樣的情況并不會出現。距離2038年還有整整14年的時間，以現在電子設備迭代的速度來看，那時候還有沒有32位的電腦都是個未知數。

其次，從千年蟲事件來看，最終結果沒有產生非常嚴重的影響，部分安全問題都控制在小范圍內，尤其是并且對現實世界產生嚴重影響，相信Y2K38也不會有太過嚴重的后果。Unix對這一BUG也是心知肚明，不可能找不到一個妥善的解決辦法。

最后，祝大家元旦快樂。2024年，你我皆是黑馬！（狗頭保命）

資源來源于互聯網