1991Linux 0.01

小さな実験を公開

9月17日付の0.01は10,239行。i386向けから始まりました。10月5日には、0.02を公開したことをcomp.os.minixへ投稿しました。

1994Linux 1.0

最初の安定リリース

TCP/IPを備え、実用のUnix系OSとして節目を迎えます。ソースは176,250行でした。

1996Linux 2.0

複数CPUへ

SMP対応が導入され、複数のCPUでプロセスを実行できるようになりました。

2001Linux 2.4

PCデバイスへの対応が広がる

USBやPC Cardなどへの対応が進みました。PAEも2.4系列の機能です。

2003Linux 2.6

長期の開発系列から短い周期へ

2.6.0にはO(1)スケジューラ、LSM、ALSAなど、2.5開発期の成果がまとまります。

LSMLSMカーネル内の操作へ、アクセス制御を呼び出すhookを用意する共通の枠組み。
2007Linux 2.6.23

CFSへ交代

通常のタスクを選ぶ仕組みがO(1)スケジューラからCFSへ変わり、仮想実行時間を基準にCPU時間を配るようになりました。

仮想実行時間仮想実行時間各タスクがどれだけCPUを使ったか比べるための時計。
2007Linux 2.6.20–24

仮想化とコンテナ

KVM、virtio、PID・network namespace、cgroupが相次いでメインラインへ取り込まれました。

KVMKVMLinuxをハイパーバイザとして使うための、カーネル内の仮想化サブシステム。virtiovirtio仮想マシン向けに標準化されたI/Oデバイスの仕様。namespacenamespacePID、マウント、ネットワーク、ホスト名などの参照範囲を、プロセス群ごとに分ける仕組み。cgroupcgroupプロセス群ごとに、CPU時間、メモリ、I/Oの使用量や優先度を管理する仕組み。
2011Linux 3.0

20周年と3.0

2.6.39の次を3.0とし、長くなったバージョン番号を整理しました。

2015Linux 4.0

止めずに直す

稼働中のカーネルへ修正を適用する、ライブパッチの共通基盤が導入されました。

2019–20Linux 5.1 / 5.6

新しいI/OとVPN

io_uringは5.1、WireGuardは5.6でメインラインへ統合されました。

2022–24Linux 6.1–6.12

Rust、EEVDF、RT

Rust基盤は6.1、EEVDFは6.6で導入されました。6.12ではPREEMPT_RTの主要部分がメインラインへ統合され、LTSにも指定されました。

EEVDFEEVDF選択対象になったタスクから、仮想デッドラインが最も早いものを選ぶアルゴリズム。PREEMPT_RTPREEMPT_RTカーネル処理の最大遅延を小さくし、ばらつきを抑えるリアルタイム対応。
2026Linux 7.0–7.2

7の時代へ

6.19の次を7.0として4月13日に公開しました。8月17日には7.2が公開されました。

マージウィンドウから正式リリースまでの循環約9–10週一周で次の正式リリースへ毎週 -rc を更新
1–2週新機能を取り込む
-rc1安定化へ切り替え
-rc6–9状態を見て正式リリースへ
現在の開発リズム

取り込む期間と、直す期間

新機能は約2週間のマージウィンドウマージウィンドウ次のリリースへ新機能を取り込む、約2週間の期間。で取り込みます。続いてリリース候補(-rc)リリース候補(-rc)正式リリース前に、広く試して不具合を直す候補。をほぼ毎週公開します。正式リリースまで全体で約9–10週間です。

近年のメジャー番号は、5.19から6.0、6.19から7.0のように、長くなった番号を整理するタイミングで更新されています。

01.1
セキュリティリスクとの戦い

歴史に残る脆弱性から学ぶ

使われ続けるコードには、脆弱性も長く潜みます。ここでは、Linuxカーネルとその周辺で特に大きな影響を与えた事例を年代順に見ます。公開された脆弱性はCVECVE公開された脆弱性に、世界で共通の識別番号を付ける仕組み。の番号で識別され、修正とその後の対応を追跡できます。

注目するのは、脆弱性が「どこ」にあったか(カーネル、ユーザー空間の基盤、CPU、開発と配布の経路)と、発見まで「どれだけ長く」残っていたかです。この二つの観点が、第9章で見る防御の設計につながります。

約25年Shellshockbashに1989年から
約12年半PwnKitpkexecの初版から
約9年Dirty COWLinux 2.6.22から
2014CVE-2014-0160

Heartbleed

OpenSSL潜伏 約2年

TLSのheartbeat拡張が、受け取った長さを検証せずにメモリを読み出して返すため、サーバーの秘密鍵やパスワードを含む内容が漏えいし得ました。OpenSSL 1.0.1から1.0.1fが対象で、Linux上の膨大な数のWebサーバーが影響を受けました。

数人の開発者が支えるOpenSSLの資金不足が広く知られ、Linux FoundationがCore Infrastructure Initiativeを設立するきっかけになりました。

2014CVE-2014-6271

Shellshock

bash潜伏 約25年

環境変数の値として渡された関数定義を解釈するとき、bashがその後ろに続くコマンドまで実行してしまいました。CGIなど外部入力が環境変数へ入る経路からリモートで悪用でき、公表直後から攻撃が広がりました。CDN事業者のCloudflareは、公表から6日間で110万件を超える攻撃を遮断したと報告しています。バグは1989年のBash 1.03から存在していました。

最初の修正では塞ぎ切れず、関連するCVEの報告と修正が続きました。広く使われる古いコードの怖さを示した事例です。

2016CVE-2016-5195

Dirty COW

Linuxカーネル潜伏 約9年

copy-on-write処理の競合状態(race condition)により、読み取り専用でmapしたファイルへ書き込めました。一般ユーザーからのroot権限奪取に使え、実際の攻撃の通信記録から発見されました。2007年の2.6.22で入り、発見まで約9年かかりました。

修正コミットには、11年前に一度直そうとして失敗した箇所だとLinus Torvalds自身が記しています。

forkfork呼び出したプロセスをもとに、子プロセスを作るためのUnix系OSのAPI。ページフォールトページフォールト現在のページテーブルだけではメモリアクセスを完了できないときにCPUが起こす例外。
2018CVE-2017-5754 ほか

Meltdown / Spectre

CPUの投機実行設計に起因

ソフトウェアのバグではなく、CPUの投機実行という高速化機構を悪用し、本来読めないメモリの内容をside channel経由で読み出します。Meltdown(CVE-2017-5754)とSpectre(CVE-2017-5753、CVE-2017-5715)は複数のチームが独立に発見し、カーネルは4.15でKPTIとretpolineという緩和策を導入しました。

以後も投機実行に起因する脆弱性の公表が続き、カーネルには適用中の緩和策を確認できる仕組み(/sys/devices/system/cpu/vulnerabilities)が加わりました。

カーネル空間カーネル空間Linuxカーネルのコードとデータが置かれ、OSの中核処理が動く範囲。
2022CVE-2021-4034

PwnKit

polkit pkexec潜伏 約12年半

主要なディストリビューションに標準で入るpkexecが、コマンドライン引数の数が0の場合の処理を誤り、環境変数の書き換えを通してroot権限でコードを実行できました。2009年5月の初版から12年以上、悪用可能なまま残っていました。

カーネルの外でも、標準構成に含まれるsetuidプログラムが攻撃対象であり続けることを示しました。

2022CVE-2022-0847

Dirty Pipe

Linuxカーネル潜伏 約1年半

pipeの実装がflagの初期化を怠り、読み取り専用ファイルのpage cacheを直接上書きできました。5.8で入った変更に由来し、5.16.11、5.15.25、5.10.102で修正されました。名前はDirty COWへの連想です。

発見の起点は、顧客のログファイルがまれに壊れるという地味な不具合の調査でした。表面的なデータ破損の裏に、権限昇格へつながる欠陥が隠れていました。

page cachepage cacheファイルの内容をRAMへ保持し、読み書きを速くする仕組み。
2024CVE-2024-3094

XZ Utilsバックドア

xz utils / 供給網採用が広がる前に発見

公開されたxz 5.6.0と5.6.1のリリースに、sshdの認証処理へ割り込むバックドアが含まれていました。多くのディストリビューションで、sshdがlibsystemd経由でliblzmaを読み込む構成が狙われました。PostgreSQL開発者のAndres Freundがsshのわずかな遅延などの異常から調べて報告し、主要ディストリビューションの安定版へ広く採用される前に発見されました。

最初の報告は、担当者本人の関与とアカウント侵害の両方の可能性を挙げており、混入の経緯そのものが調査対象になりました。少人数が支える基盤ソフトウェアの持続可能性が、あらためて世界的な課題になりました。

サプライチェーン攻撃サプライチェーン攻撃利用者を直接攻撃せず、依存するソフトウェアの開発・配布の経路へ不正なコードを混ぜる攻撃。
01.2
守る側の変化

脆弱性への対応を支える仕組み

個別の修正と並行して、資金、設計、テスト、運用のそれぞれで、脆弱性への対応を支える仕組みが育っています。Heartbleedを受けて設立されたCore Infrastructure Initiativeのように事件が直接のきっかけになったものもあれば、独立に始まり継続しているものもあります。

2014

基盤ソフトウェアへ資金を集める

Heartbleedを受けて、Linux FoundationはCore Infrastructure Initiativeを設立しました。OpenSSL、OpenSSH、NTPなど、広く使われながら支えの薄かったプロジェクトへの資金提供が始まりました。

2015

バグのクラスごと悪用を難しくする

Kernel Self-Protection Projectは、個々の修正を超えて、同じ種類のバグ全体の悪用を難しくする防御に取り組む活動です。第9章で見るKASLRやstack canaryのようにKSPP以前からある防御の改善と、新しい防御のメインラインへの導入を続けています。

常時

自動でバグを見つけ続ける

オープンソースのkernel fuzzerであるsyzkallerは、システムコールの組み合わせを自動生成してカーネルを試験します。報告システムのsyzbotが主要ブランチを常時テストし、見つかったバグと修正を追跡します。

2024

修正へ自らCVEを割り当てる

LinuxカーネルプロジェクトはCVE Numbering Authorityになりました。割り当てはLinux kernel CVE assignment teamが担い、どの修正が悪用可能かを事前に見分けるのは難しいという立場から、安定版へ入った修正を基準に幅広くCVEを割り当てています。

第9章で、これらの防御の仕組みを見る