Linux kernel · Linux misc

y2038 對 32-bit 機器所造成的溢位影響以及處理

問題主因

kernel 計算時間的方式是紀錄從 1970/1/1 (也就是俗稱的 Unix time) 開始的秒數
由於 32-bit 機器上無論 kernel or glibc 上的時間變數 time_t 的型態為 long.
所以只能紀錄2,147,483,647秒.
這代表 32-bit OS 中的timer value將於 2038 年 1/19 overflow. 變成1901 12/31

影響程度

  • kernel (including VFS and filesystem)
  • device driver
  • glibc (including toolchain)
  •  user application
可以看到影響層面相當廣, 小至 filesystem timestamps error, 大至 kernel panic, application segmentation fault 都有可能發生.

處理方式 

此問題需要kernel/ driver/ glibc/ AP 一起修正以避免 y2038 issue.
但Linux 有許多兼容上的議題, 所以完整 patch 還在討論, 尚未定案. 
即便如此,  有些 action 還是可以先行進行

Kernel space

  • 更換不安全的變數以及資料結構
    • 將time_t/ timespec/ timeval 替換成 ktime_t/ timespec64
  • 若須計算 time offset, 請使用 monotonic clock
    • 也就是不用 unix time 而是 system uptime
  • 確認使用的 filesystem 有沒有相關議題
    • 一般而言, filesystem 使用 32-bit 格式來儲存每個檔案的 timestamp, 除了去修改timestamp外, 也要注意如何轉換已使用32-bit timestamp儲存的檔案
    • 以我常用的 EXT4 為例, EXT4 使用 extra 變數(lower 2 bits )來協助儲存 timestamp, 故EXT4 使用 34 bit 來儲存 timestamp, 可支援到2446年. 其餘 30 bit 用來存 nanoseconds.
    • 但 EXT4 有其他 y2038 unsafe 的變數, 所以依然需要 patch. 只是 patch 目前還尚未被接受. linus 大神表示有更好的改法
  • VFS
    • 即便 filesystem 為 y2038 safe, 但 hook 的VFS 也要處理,  因為VFS layer 有自己的 timestamp. 用來處理 in-memory inodes 以及其他 structures.

 

Userspace

其他詳細內容, 可參考下列投影片.

雖然距離 2038 還有 22 年, 但是提早準備總是好事~

畢竟到時我也還沒退休XD

發表迴響