安定版カーネルのリリースとアップデート

Linux カーネルの安定版リリースモデルは 2005 年から始まりました。2~3 か月ごとに新しいリリースを提供するそれまでのカーネル開発モデルは、ほとんどのユーザーのニーズを満たしていないと判断されたためです。ユーザーは 2~3 か月以内のバグ修正を望んでいましたが、Linux ディストリビューションでカーネル コミュニティからのフィードバックなしにカーネルを最新に保つのは困難でした。通常、個々のカーネルでセキュリティを維持し、最新のバグ修正を適用するには、多数の異なる人が大規模で混乱を伴う作業を行う必要がありました。

安定版カーネルのリリースは、リーナス トーバルズ氏のリリースを直接のベースとし、時期や適用可能なパッチ、メンテナの作業負荷などにもよりますが、ほぼ毎週リリースされます。安定版リリースの番号付けは、カーネル リリースの番号から始め、最後に別の番号を追加するというものです。たとえば、トーバルズ氏がリリースしたカーネルの番号が 4.4 であれば、これをベースにした安定版カーネル リリースの番号は 4.4.1、4.4.2、4.4.3 というように続きます。この番号列は、安定版カーネル リリース ツリーを指す場合、通常「4.4.y」と省略されます。各安定版カーネル リリース ツリーは、1 人のカーネル開発者が管理し、この開発者が、そのリリースに対して必要なパッチを選び、レビューやリリースのプロセスを管理する責任を負います。

安定版カーネルは、そのときの開発サイクル全体を通じて維持されます。トーバルズ氏が新しいカーネルをリリースすると、以前の安定版カーネル リリース ツリーは停止となり、ユーザーは新しいカーネルに移行する必要があります。

長期安定版カーネル

この安定版リリース プロセスを 1 年続けたところ、多くの Linux ユーザーが数か月以上のサポートを望んでいることがわかりました。これに応えて、長期サポート(LTS)カーネル リリースが設けられ、2006 年に最初の LTS カーネル(2.6.16)がリリースされました。それ以来、1 年に 1 回、新しい LTS カーネルが選ばれ、最低 2 年間はカーネル コミュニティによって維持されるようになりました。

執筆時点での LTS カーネルは 4.4.y リリース、4.9.y リリース、4.14.y リリースです。新しいカーネルは毎週リリースされています。一部のユーザーとディストリビューションのニーズに応えて、古いカーネルもカーネル デベロッパーよってゆっくりしたリリース サイクルで維持されています。長期安定版カーネルに関する情報、メンテナ、メンテナンス期間については、kernel.org のリリースのページをご覧ください。

LTS カーネル リリースは 1 日に 6~8 件のパッチを受け取りますが、通常の安定版カーネル リリースは 10~15 件です。パッチの数は、対応する開発版カーネル リリースの現在時刻や他の外部要因に応じて変化します。最新のバグ修正の多くは古いカーネルと無関係なため、古い LTS カーネルほど適用できるパッチが少なくなります。しかし、古いカーネルほど、コードベースに変更があるため、適用が必要な変更のバックポートが難しくなります。したがって、LTS カーネルのメンテナンスは、適用されるパッチの総数こそ少なくなりますが、通常の安定版カーネルのメンテナンスよりも手間がかかります。

安定版カーネルのパッチルール

安定版カーネル リリースに何を追加できるかに関するルールは導入以来ほぼ同じであり、次のように要約されます。

  • 明らかに正しく、テスト済みであること。
  • 100 行を超えないこと。
  • 修正する問題は、1 件のみであること。
  • 修正する問題は、問題として報告済みであること。
  • 新しいデバイス ID やハードウェアの癖に対応するのは構わないが、大きな新機能の追加にはならないこと。
  • リーナス トーバルズ氏のツリーにマージ済みであること。

最後のルール「リーナス トーバルズ氏のツリーにマージ済みであること」は、カーネル コミュニティが修正を見落さないようにするためのものです。コミュニティが、まだリーナス トーバルズ氏のツリーにない修正を安定版カーネル リリースに入れようと考えることはありません。アップグレード時のリグレッションがあってはならないためです。こうして、安定版ブランチと開発版ブランチを維持している他のプロジェクトに起こりうる多くの問題を回避しています。

カーネルのアップデート

Linux カーネル コミュニティは、以前のリリースで正しく動作していたものがアップグレード後も正しく動作することをユーザーに約束してきました。この約束は今でも有効です。リグレッションが発生することはあっても、それは最も高い優先度のバグとされ、すぐに修正されるか、リグレッションの原因となった変更が Linux カーネルツリーから元に戻されます。

この約束は、安定版カーネルのインクリメンタル アップデートと、3 か月ごとに行われるメジャー アップデートの両方で有効です。しかし、カーネル コミュニティが約束できるのは、Linux カーネルツリーにマージされたコードについてのみです。デバイスのカーネルにマージされていても、kernel.org のリリースにないコードは認識されず、そのコードへの対応が計画されたり、検討されたりすることはありません。

大きなパッチセットがある Linux のデバイスでは、新しいカーネルに更新する際に大きな問題が発生する可能性があります。各リリース間で多数の変更があるためです(リリースごとに 1 万~1 万 4 千件)。特に SoC のパッチセットでは、新しいカーネルへの更新に問題があることが知られています。これは、アーキテクチャ固有のカーネルコードに(場合によってはコアのカーネルコードにも)大規模かつ重要な修正があるためです。そのため、多くの SoC ベンダーが自社のデバイスに LTS リリースを使用することを標準にしようとしています。Linux カーネル コミュニティからバグ修正やセキュリティ アップデートを直接受け取れるようにするためです。

セキュリティ

カーネルのリリース時に、Linux カーネル コミュニティが特定の変更をセキュリティ修正だと宣言することはほとんどありません。これは、バグ修正の作成時にそれがセキュリティ修正であるかどうかを判断するのが難しいという基本的な問題によるものです。また、かなり時間がたってからセキュリティ関連であると判断されるバグ修正も多いため、カーネル コミュニティはリリースされたバグ修正をすべて適用することを強く推奨しています。

セキュリティ問題がカーネル コミュニティに報告されると、問題はできる限り速やかに修正され、開発ツリーと安定版リリースに組み込まれて公開されます。上で説明したように、この変更は「セキュリティ修正」とは呼ばれず、カーネルに対する他のバグ修正と同じように見えます。これは、問題の報告者がそれを発表する前に、影響を受ける当事者がシステムを更新できるようにするためです。

セキュリティ バグをカーネル コミュニティに報告して、できる限り速やかに解決し修正する方法については、www.kernel.org で「The Linux kernel user's and administrator's guide」の中の「Security bugs」をご覧ください。

セキュリティ バグはカーネルチームから発表されないため、Linux カーネル関連の問題の CVE 番号は通常、安定版ブランチと開発版ブランチに統合されてから数週間、数か月、場合によっては数年後にリリースされます。

システムを安全に保つ

Linux を使用するデバイスをデプロイする際、製造元はすべての LTS カーネルのアップデートを採用し、適切なテストでアップデートの動作を確認してからユーザーに配布することを強くおすすめします。これには次のような利点があります。

  • リリースは、各部分が個別にレビューされるのではなく、カーネル デベロッパーにより全体としてレビューされます。
  • どれが「セキュリティ」の問題を修正するパッチで、どれがそうでないかを判断するのは、不可能とまでは言えないまでも困難なことです。ほとんどの LTS リリースには既知のセキュリティ修正が最低 1 件は含まれていますが、多くは「不明」のままです。
  • テストで問題が発生した場合、カーネル コミュニティはすぐに問題の解決に取り組みます。
  • 自分で行う変更のみを除外しようとすると、カーネルツリーが将来のアップストリーム リリースに正しくマージできないものになってしまいます。