穩定版核心版本和更新

Linux 核心穩定版本發布模式自 2005 年開始,當時我們判斷現有的核心開發模式 (每 2 至 3 個月發布一次新版本) 無法滿足大多數使用者的需求。使用者希望在 2 到 3 個月內完成錯誤修正,而 Linux 發行版本發現,如果沒有核心社群的意見回饋,就很難讓核心保持最新狀態。一般來說,嘗試讓個別核心保持安全,並採用最新的錯誤修正,是許多不同人士所做的龐大且令人困惑的工作。

穩定版核心版本會直接根據 Linus Torvalds 的版本發布,並視各種外部因素 (時節、可用的修補程式、維護者工作量等) 每週或每隔一週發布。穩定版的編號會從核心版本的編號開始,並在結尾加上額外的編號。舉例來說,Linus 發布了 4.4 版核心,而以此核心為基礎的穩定版核心則會以 4.4.1、4.4.2、4.4.3 等編號發布。當您參照穩定的核心版本樹狀結構時,這個序列通常會縮短為 4.4.y。每個穩定的核心版本樹狀結構都由單一核心開發人員維護,他們負責為版本挑選所需的修補程式,並管理審查/發布程序。

穩定版核心會在目前的開發週期內維持。Linus 發布新核心後,先前穩定的核心版本樹狀結構就會停止,使用者必須改用較新的核心版本。

長期穩定的核心

在這個新的穩定版本發布程序實施一年後,我們發現許多不同的 Linux 使用者希望核心的支援時間超過幾個月。為因應這項需求,我們推出了長期支援 (LTS) 核心版本,第一個 LTS 核心 (2.6.16) 於 2006 年發行。自此之後,我們每年都會選出新的 LTS 核心,核心社群也會至少維護 2 年的核心。

撰寫本文時,LTS 核心為 4.4.y、4.9.y、4.14.y、4.19.y、5.4.y 和 5.10.y 版本。每週都會發布新的核心。基於部分使用者和發行版本的需求,核心開發人員會以較慢的發布週期維護一些較舊的核心。如要瞭解所有長期穩定版核心、負責人員,以及維護時間長度,請參閱 kernel.org 發布版本頁面。

LTS 核心版本平均每天接受 6 到 8 個修補程式,而一般穩定核心版本每天則包含 10 到 15 個修補程式。根據對應的開發核心版本目前時間和其他外部變數,每個版本的修補程式數量會有所波動。LTS 核心越舊,適用的修補程式就越少,因為許多近期的錯誤修正與舊版核心無關。不過,由於核心版本越舊,就越難將所需的變更回溯至舊版,因為程式碼庫會有所變更。因此,雖然整體修補程式數量可能較少,但維護 LTS 核心所需的努力,會比維護一般穩定核心還要多。

穩定版核心修補程式規則

自推出以來,可新增至穩定版核心的規則幾乎沒有改變,以下列舉這些規則:

  • 必須經過測試且明顯正確。
  • 不得超過 100 行。
  • 必須只修正一個問題。
  • 必須修正已回報為問題的項目。
  • 可以是新裝置 ID 或硬體的怪癖,但不能新增主要新功能。
  • 必須已合併至 Linus Torvalds 的樹狀結構。

最後一個規則「必須已合併至 Linus Torvalds 的樹狀結構」可防止核心社群遺漏修正項目。社群絕不會希望修補程式進入 Linus Torvalds 樹狀結構中未發布的穩定版核心,這樣一來,任何升級的使用者都不會遇到回溯問題。這可避免其他維護穩定版和開發版分支的專案發生許多問題。

核心更新

Linux 核心社群向使用者保證,升級作業不會破壞先前版本中運作的任何內容。這項承諾至今仍是有效的。確實會發生回歸現象,但這些都是最高優先順序的錯誤,而且會迅速修正,或是從 Linux 核心樹狀結構中快速還原導致回歸的變更。

這項承諾適用於穩定版核心的漸進式更新,以及每三個月一次的重大更新。不過,核心社群只能對已合併至 Linux 核心樹狀結構的程式碼做出這項承諾。任何合併至裝置核心的程式碼,如果不在 kernel.org 版本中,就無法得知,因此無法規劃或考量與該程式碼的互動情形。

由於各版本之間的變更次數眾多 (每個版本有 10,000 到 14,000 次變更),因此採用 Linux 且有大量修補程式集的裝置在更新至較新版核心時,可能會發生重大問題。由於 SoC 修補集的大小龐大,且會大幅修改架構特定 (有時是核心) 核心程式碼,因此特別容易發生更新至較新核心的問題。因此,大多數 SoC 供應商開始將 LTS 版本用於裝置,讓這些裝置可直接從 Linux 核心社群接收錯誤和安全性更新。

安全性

在發布核心時,Linux 核心社群幾乎不會將特定變更宣告為安全性修正。這是因為在建立時,很難判斷錯誤修正是否為安全性修正。此外,許多錯誤修正都是在一段時間過後才判定與安全性相關,因此核心社群強烈建議您一律採用所有發布的錯誤修正。

當安全性問題回報給核心社群時,我們會盡快修正問題,並公開推送至開發樹狀結構和穩定版本。如上所述,變更幾乎不會被描述為「安全性修補」,而是像是任何其他核心錯誤修正。這樣一來,受影響的使用者就能在問題回報者發布問題前更新系統。

如要進一步瞭解如何向核心社群回報安全性錯誤,以便盡快解決及修正這些錯誤,請參閱 Linux 核心使用者和管理員指南中的「安全性錯誤」一節,網址為 www.kernel.org

由於核心團隊不會向大眾公布安全性錯誤,因此 Linux 核心相關問題的 CVE 編號通常會在修正項目合併至穩定版和開發版分支後數週、數月,甚至數年後才會發布。

維持安全的系統

部署使用 Linux 的裝置時,我們強烈建議製造商取得所有 LTS 核心更新,並在經過適當測試證明更新運作良好後,推送給使用者。這麼做有幾個優點:

  • 核心開發人員已審查整個版本,而非個別部分。
  • 很難判斷哪些修補程式可修正「安全性」問題,哪些則無法修正。幾乎每個 LTS 版本都包含至少一個已知的安全性修復項目,以及許多「未知」項目。
  • 如果測試顯示問題,核心開發人員社群會迅速做出反應,解決問題。
  • 嘗試只篩選您執行的變更,結果會產生無法與日後上游版本正確合併的核心樹狀結構。