ライブパッチング（kpatch/livepatch）の仕組み

「再起動できない」という制約から逆算する

カーネルに脆弱性が見つかったら、本来は修正版を入れて再起動すれば終わりです。だが数千台のサーバーや、停止コストの高い基幹システムでは、その「再起動」こそが最大の障害になります。パッチ適用のたびにサービスを落とせない——この制約から逆算して生まれたのがライブパッチングです。

発想は単純で、走り続けているカーネルの中で、問題のある関数だけを新しい関数に差し替える。プロセスを止めず、メモリ上の状態を保ったまま、コードの一部分だけをすり替えます。Red Hat の kpatch と SUSE の kGraft が源流で、両者の知見が上流の livepatch（CONFIG_LIVEPATCH）として Linux カーネル本体に統合されました。

ただし「走っているコードを書き換える」は本質的に危うい操作です。差し替えの瞬間に旧関数を実行中のスレッドがいたらどうなるのか。この整合性をどう担保するかが、ライブパッチの技術的な核心になります。

関数リダイレクト：ftraceフックで入口を奪う

ライブパッチが差し替える単位は関数です。命令を1個書き換えるのではなく、対象関数の入口で実行の流れを新版へ丸ごと逸らすのが基本戦略です。これを支えるのが ftrace の仕組みです。

カーネルを -pg（mcount/fentry）付きでビルドすると、各関数の先頭にトレース用のフック呼び出しが埋め込まれます。平時はこの箇所が nop に書き換えられて無効化されていますが、ftrace はここを足場にして任意のハンドラを差し込めます。livepatch はこの ftrace ハンドラを使い、旧関数の入口に来た実行を新関数の先頭へリダイレクトします。

[呼び出し元] ─call→ 旧関数の先頭
                      │ fentryフック(ftrace)
                      ▼
              livepatch ftraceハンドラ
                      │ 復帰アドレス(ip)を新関数へ書き換え
                      ▼
                  新関数の本体を実行 ─return→ 呼び出し元へ

ポイントは、旧関数の本体を実行する前にハンドラへ寄り道し、戻り先（命令ポインタ）を新関数の先頭にすり替えることです。これにより呼び出し元から見れば、何事もなかったように新しいコードが走ります。命令列を直接 jmp で潰す素朴な方式と違い、ftrace 経由なので着脱が安全で、同じ箇所を複数の利用者（トレーサとパッチ）が共有する調停も効きます。フックを置く土台は、関数入口の mcount/fentry を足場に実行を奪う ftrace のトレース機構 そのものです。

整合性の難所：旧関数のスタック上にいるタスク

関数の入口を奪うだけなら簡単です。難しいのは、切り替えの瞬間にすでに旧関数の内部を実行中のタスクの扱いです。入口フックはこれから入る呼び出ししか捕まえられません。すでに旧関数の途中まで進み、コールスタックに旧関数のフレームを積んでいるスレッドは、そのまま旧コードを走り続けます。

新旧が混在しても無害なパッチなら問題ありませんが、新旧で前提が食い違う修正——たとえばロック取得順序の変更や、関数間で受け渡すデータの意味の変更——では、旧版で取ったロックを新版の規約で扱う、といった矛盾が起き得ます。だからライブパッチは「新版だけが、または旧版だけが、首尾一貫して使われている」状態を保証しなければなりません。

ここで使われるのが**タスクの安全点（safe point）**という考え方です。

一貫性モデル：全タスクが安全点を通るのを待つ

上流の livepatch が採る整合性確保は、ハイブリッド一貫性モデルと呼ばれます。kpatch のスタック検査と kGraft のタスク単位切り替えを合わせたもので、概略は次の流れです。

1. パッチを有効化すると、全タスクに「まだ移行（transition）中」の印を付ける。各タスクは個別に KLP_UNPATCHED から KLP_PATCHED へ遷移する状態を持つ。
2. カーネルは各タスクごとに、そのタスクのコールスタックを巻き戻して調べ、パッチ対象の旧関数がスタック上に1つも載っていないことを確認する。載っていなければ、そのタスクを安全に新版側へ切り替える。
3. スタック上に旧関数がまだ載っているタスクは、まだ切り替えない。次にカーネルへ入った折り——システムコール復帰時やスケジューラによる切り替え時など、自然な安全点で再判定し、条件が満たされ次第切り替える。
4. すべてのタスクが切り替わったら移行は完了。以後は全タスクが新版を使う。

つまり瞬時の全体置換ではなく、タスクごとに安全な瞬間を待って徐々に移すわけです。各タスクの切り替え点は、そのタスクが旧関数のフレームを持たない瞬間に限られるため、「新版で動くタスクと旧版で動くタスクが、それぞれ自分の版で一貫している」状態が保たれます。

旧関数を実行中のタスクがいなくなるのを待つこの構図は、旧版を読む者が全員いなくなってから古い版を解放する RCU の grace period と発想がよく似ています。「並行して動く読み手が安全に抜けるのを待つ」というパターンの一族です。

適用範囲の制約：なぜ「何でも直せる」わけではないのか

ライブパッチが関数単位の差し替えであるという原理から、苦手分野が論理的に決まります。

最大の壁はデータ構造です。ライブパッチが差し替えるのはコード（関数）であって、すでにメモリ上に存在するデータのインスタンスではありません。構造体にフィールドを足したくても、稼働中の何千個の既存インスタンスを遡って拡張することはできません。この限界に対しては、既存構造体の外に追加データを括り付ける**シャドウ変数（shadow variable）**という仕組みが用意されていますが、パッチ作成者が手で整合性を設計する必要があり、自動ではありません。

関連技術との位置づけ

ライブパッチは「再起動なしでカーネルを変える」という点で eBPF と並びますが、目的が異なります。eBPF が観測やフック点での振る舞い追加に向くのに対し、ライブパッチは既存関数のバグそのものの修正を狙います。後者は対象が任意のカーネル関数で、しかも挙動を変えてしまうため、前述の一貫性保証が不可欠になります。

なお、差し替えるべき新関数は事前にビルドしてカーネルへ持ち込む必要があり、シンボルの解決には 動的リンク／シンボル解決 と同じく、対象カーネルの正しいシンボルアドレスへ結び付ける作業が伴います。kpatch のツール群は、修正前後のカーネルをビルドして差分のある関数だけを抽出し、それをパッチモジュールへ固める、という流れでこれを自動化します。

まとめ