Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

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

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 件のパッチを受け入れますが、通常の安定版カーネル リリースでは 1 日 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 guideSecurity bugs を参照してください。

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

システムを安全に保つ

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

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