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

可以看到影響層面相當廣, 小至 filesystem timestamps error, 大至 kernel panic, application segmentation fault 都有可能發生.

此問題需要kernel/ driver/ glibc/ AP 一起修正以避免 y2038 issue.

但Linux 有許多兼容上的議題, 所以完整 patch 還在討論, 尚未定案.

即便如此, 有些 action 還是可以先行進行

更換不安全的變數以及資料結構
- 將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.

GLIBC 目前出了第三版的草稿 for glibc y2038 design, 可持續關注:
- https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=63#Support_for_non-Y2038-safe_kernels
User application 避免用 y2038 unsafe 的變數來承接或者計算時間

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

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

~~畢竟到時我也還沒退休XD~~

SZ Lin with Cybersecurity & Embedded Linux