VPSのライブカーネルパッチと再起動の違い

VPS でライブカーネルパッチが行うこと

ライブカーネルパッチは、再起動せず、接続を切断せずに、稼働中のマシンへカーネルのセキュリティ修正を適用します。修正済みの関数をカーネルモジュールとして読み込み、サーバーがネットワークトラフィックを処理し続ける間、旧関数へのすべての呼び出しを新しいコピーへリダイレクトします。この仕組みにより、ライブパッチが有効な場面と、対応できない場面の両方が決まります。

ライブパッチは時間を稼ぎます。再起動を不要にするものではありません。6か月間ライブパッチを適用しているサーバーでも、ディスク上の古いカーネルイメージで起動したままです。また、それらのパッチはすべてメモリ上にしか存在しません。

ライブパッチは、マネージドプランの機能として提供されることがよくあります。アンマネージドのサーバーでは、2つのコマンドを使って自分で有効にできます。マネージド VPS とアンマネージド VPSの料金差を支払う前に、この点を知っておくとよいでしょう。

ライブカーネルパッチはどのように動作しますか？

カーネルには、CONFIG_LIVEPATCH とともに組み込まれるライブパッチ機能のコアがあります。実行中のカーネルで確認してください。

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

CONFIG_LIVEPATCH=y と表示される行があれば、実行中のカーネルはこのコアを有効にしてビルドされています。これがなければ、そのマシンではどのライブパッチサービスも動作しません。

このリダイレクトには、カーネルの関数トレーサーである ftrace を使用します。ほとんどのカーネル関数は、関数の先頭に call 命令を置いてコンパイルされます。この命令は、引数やスタックが変更される前に実行されます。ftrace は、この call の位置をフックとして使用します。パッチを適用すると、ライブパッチ機能のコアが対象関数に ftrace ハンドラーを登録し、そのハンドラーが実行を置換関数へ転送します。カーネルのドキュメントには、次のように明記されています。「Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified.」

この説明から、後で重要になる点が2つ分かります。ftrace でフックできる関数だけがパッチ対象になります。そのため、エントリ時の call がない状態でコンパイルされた関数には、まったくパッチを適用できません。また、パッチの単位は関数全体であり、関数内の1行だけを対象にすることはできません。

より難しいのは、稼働中のシステムを安全に切り替えることです。関数を置き換えた時点で、いずれかの CPU のスタック上で古いコードが実行中だと、古い動作と新しい動作が混在します。Upstream Linux は、タスク単位の整合性モデルでこの問題に対処します。カーネルのドキュメントでは、これを次のようなハイブリッド方式と説明しています。「it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching.」タスクは、カーネルがそのタスクがパッチ対象関数内にいないことを確認できた場合に限り、1つずつ新しいコードへ移行します。すべてのタスクが移行するまで、パッチは移行中の状態です。

結果は自分で確認できます。適用済みのパッチは /sys/kernel/livepatch の下に表示されます。パッチごとに1つのディレクトリがあり、その中にパッチが適用された関数が一覧表示されます。

ls /sys/kernel/livepatch/

一覧が空の場合、メモリ上にライブパッチは読み込まれていません。新しいサーバーでは、これが通常の初期状態です。

ライブカーネルパッチで修正できないもの

修正されるのは関数本体です。それ以外は修正されません。

• 変更されたデータ構造。 上流の修正で struct にフィールドが追加されたり、既存のフィールドの意味が変わったりする場合、すでに割り当てられて使用中のオブジェクトを書き換える安全な方法はありません。kpatch project も同等のケースについて、「静的に割り当てられたデータを変更するパッチは、直接サポートされません」と明記しています。回避策として shadow variables と callbacks は存在しますが、パッチごとに手作業で記述する必要があり、自動ではありません。
• 複数の関数に同時にまたがる修正。 複数の関数間でロックの取得順序を変更する修正では、すべての関数を同時に変更する必要があります。また、一貫性モデルはマシン全体を単一の時点で停止するのではなく、タスクを切り替えます。
• 初期化コード。 __init とマークされた関数は、サーバーが稼働する時点ですでに実行され、解放されています。そのため、リダイレクトする対象が残っていません。
• 新しいカーネルバージョンと新機能。 ライブパッチは、1 つのカーネル系列内でパッチレベルを移行させます。別の系列へ移行することはなく、新機能を追加することもありません。Linux 7.1 で取り込まれた変更など、新しい系列の機能が必要な場合は、そのカーネルをインストールして起動します。
• ユーザー空間。 Canonical は境界を明確に示しています。「Canonical Livepatch は OpenSSL や glibc などのユーザー空間ライブラリにはパッチを適用しません。これは unattended-upgrades またはシステム管理ツールの責任だからです。」ライブパッチを適用したカーネルでも、隣に古い OpenSSL が残っていれば、サーバー全体にパッチが適用されたことにはなりません。そのため、同じホスト上ではunattended upgrades にユーザー空間パッケージを処理させてください。

Ubuntu のサービスには、重要度に関する境界もあります。Canonical は、「Critical および High の Common Vulnerability Scoring System (CVSS) と Ubuntu Priority の評価を持つカーネル脆弱性にパッチを適用します」と説明しています。CVE (common vulnerabilities and exposures) 識別子は 1 件の脆弱性を示し、CVSS はその脆弱性に付与されたスコアです。Medium と評価されたカーネル CVE はディスク上のパッケージでは修正されますが、ライブパッチは適用されません。そのため、実行中のカーネルに反映されるのは次回の再起動時であり、それより前ではありません。

ライブカーネルパッチの選択肢は何ですか？

一般的に使われている系統は3つあり、いずれも同じカーネル機構を利用します。

Canonical Livepatch は Ubuntu Pro を通じて提供されます。Ubuntu Pro は個人利用では無料です。Canonical は「最大5台の物理マシンでの個人利用について、現在も将来も無料」と説明しています。公式の Ubuntu Community メンバーは最大50台まで利用できます。これは2026年8月時点で文書化されている上限です。商用利用には有料サブスクリプションが必要です。対応範囲はカーネル系列および flavour ごとに付与されます。サポート対象の long term support (LTS) リリースにおける general availability (GA) カーネルと、その hardware enablement (HWE) カーネルが対象です。generic、aws、azure、gcp、oracle、ibm、lowlatency などの flavour に対応します。利用を前提にする前に、使用中のカーネルが Canonical の公開カーネル一覧に含まれているか確認してください。

KernelCare は TuxCare が提供する商用エージェントです。ファーストパーティーのサービスがないディストリビューションを含め、多くのディストリビューションに対応します。文書化されているインストール手順では、ベンダーのスクリプト curl -s -L https://kernelcare.com/installer | bash を実行し、続いてキー方式のライセンス用に /usr/bin/kcarectl --register KEY を実行します。エージェントは独自のスケジュールで新しいパッチを確認します。/usr/bin/kcarectl --update を実行すると確認を強制できます。サーバーに対してシェルへ直接パイプする前に、インストーラーの内容を確認してください。

kpatch と kGraft は先行する実装です。kGraft は SUSE、kpatch は Red Hat から登場しました。現在の upstream Linux にあるライブパッチの中核は、両方の設計を統合したものです。kpatch 自体は終了に向かっています。README には、Linux 6.19 以降「kpatch project is deprecated and in maintenance mode」と記載されています。upstream kernel では kpatch-build が klp-build に置き換えられます。RHEL とその再構築版では、パッチを手作業でビルドするのではなく、ディストリビューション独自のサービスを使用してください。

選択する際は、ディストリビューションがサポートしているものと、ライセンスで許可されているものを基準にしてください。カーネルレベルでの結果は、どの場合も同じです。

Ubuntu で Canonical Livepatch を有効にする方法

最初に、Ubuntu Pro のアカウントページから token を取得します。以下の両方のコマンドでは、外向きのネットワークアクセスが機能している必要があります。client は Canonical のサーバーと通信して attach し、patch を取得するためです。

sudo pro attach TOKEN
sudo pro status

token を指定せずに sudo pro attach を実行すると、代わりにブラウザーを使うフローが開始され、Canonical のサイトで入力する code が表示されます。attach が完了すると、推奨される service が自動的に有効になります。現在の LTS release では、Livepatch も含まれます。service を自分で選択する場合は sudo pro attach --no-auto-enable を使用します。

Livepatch がまだ有効でない場合は、次を実行します。

sudo pro enable livepatch
sudo canonical-livepatch status

service は canonical-livepatch snap から実行されるため、enable 処理を完了するには snapd が正常に動作している必要があります。pro status では、entitlement と status を含む service の一覧が表形式で表示されます。canonical-livepatch status では kernel ごとの詳細が表示されます。Canonical のドキュメントには、次の形式の出力例があります。

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

確認すべき行は 2 行です。kernel state は、現在実行している series が service の対象かどうかを示します。Livepatch がサポートしていない kernel で起動した場合、この行が問題の状態になります。patch state は、その kernel に適用可能な patch が実際にロードされているかどうかを示します。対象の kernel なのに patch が適用されていない場合は、client の問題です。対象外の kernel の場合は、kernel の問題であり、client の設定では解決できません。

再起動が保留中かどうかを確認するには

ライブパッチにより緊急性がなくなるため、再起動の保留状態は分かりにくくなります。自分で確認する必要があります。

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

パッケージマネージャーは、インストール済みパッケージを有効にするために再起動が必要になると /var/run/reboot-required を作成します。また、新しい linux-image パッケージをインストールすると、必ずこのファイルが作成されます。.pkgs ファイルには、再起動を要求したパッケージが一覧表示されます。最初のコマンドの結果が No such file or directory なら、最後にマシンを起動してから再起動を要求したパッケージはありません。現在の Ubuntu では /var/run は /run へのシンボリックリンクなので、どちらのパスでも同じファイルを参照できます。

このフラグは tmpfs 上にあり、起動のたびにリセットされます。そのため、カーネル自体を確認してください。

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r は、現在実行中のカーネルを表示します。2 番目のコマンドは、ディスクにインストールされているカーネルパッケージを表示します。その一覧にある uname -r の報告より新しい linux-image がある場合、Livepatch の状態にかかわらず、マシンは古いカーネルで動作しています。これが重要な確認です。ライブパッチは実行中のカーネルを安全にするためのものであり、最新の状態にするためのものではありません。

同じ問題のユーザー空間側を確認するには、Ubuntu Server にデフォルトでインストールされている needrestart を使用します。削除済みのライブラリファイルを保持している実行中のサービスを一覧表示できます。

sudo needrestart -r l

-r l のフラグの組み合わせは「一覧表示のみ」を意味します。そのため、状態を表示するだけで変更は行いません。

再起動がなくならない理由

ディスク上の kernel は変更されていません。Livepatch は実行中の kernel にライブパッチを適用しますが、boot image には書き込まれません。そのため再起動すると、bootloader が選択した linux-image で起動し、Livepatch client が適用可能なパッチを再適用します。この2つの間は、パッチが適用されていないコードを実行することになります。古い kernel ではなく、現行の kernel で起動すべき理由がもう1つ増えます。

適用範囲は kernel series ごとに決まり、series はサポート対象外になります。実行中の series がサポート対象リストから外れると、kernel state の行で適用範囲が報告されなくなります。解決策は新しい kernel だけです。つまり、再起動が必要になります。LTS release では通常、新しい series は 26.04.1 などの point release に hardware enablement kernel としてまとめられて提供されます。そのため、置き換え用の kernel はすでに archive にあり、必要なのは予定したタイミングでの起動だけです。

Medium および low severity の kernel 修正は、ライブパッチの対象になりません。これらはディスク上の package に含まれ、起動時にのみ適用されます。

長期間稼働している kernel には、パッチ適用では消去されない状態も蓄積します。Canonical 自身の見解は、率直な説明として引用する価値があります。Livepatch は「再起動の代替ではありません。予定外の再起動を防ぐことで、より細かく制御できるツールです」。ここで意味を担う語は unscheduled です。再起動そのものは必要です。実行するタイミングを選べるだけです。

再起動後に正常復帰する再起動を予約する

コンソールに接続できない場合、VPS の再起動は一方通行になります。reboot を実行する前に、マシンが復帰しなかった場合でも再度接続できることを確認してください。

• プロバイダーがコントロールパネルでシリアルコンソールまたは VNC (virtual network computing) を提供していることを確認し、障害発生時ではなく今のうちに開いておきます。
• df -h /boot で空き容量を確認します。/boot が満杯だと、initramfs (initial RAM filesystem) の書き込み中に kernel パッケージの処理が失敗し、未完成のイメージを指す bootloader エントリが残ることがあります。
• 正常に動作することが確認済みの古い kernel を少なくとも 1 つ残します。GRUB では "Advanced options for Ubuntu" の下に表示されます。新しい kernel で起動に失敗した場合、これを起動するのが最も速い復旧方法です。
• 必要になる前に、プロバイダーの rescue mode を確認しておきます。再起動後にコンソールへ initramfs プロンプトが表示された場合は、そこで修復します。

起きている時間帯に、次のコマンドで再起動を予約します。

sudo shutdown -r +5 "Kernel update, back in a moment"

これにより、5 分後の再起動が予約され、ログイン中のユーザーにメッセージが送信されます。sudo shutdown -c でキャンセルできます。マシンが復帰したら、次の 2 点を確認します。

uname -r
sudo canonical-livepatch status

uname -r で新しい kernel が表示され、status 出力で新しい series が対象になっていることを確認できます。マシンがまったく復帰しない場合、原因はほぼ必ずネットワークではなく boot path にあります。復旧手順は kernel 更新後に起動しない VPS のガイドに記載しています。

古い kernel を削除する必要がある理由

Live patching はこの問題を解決するどころか、悪化させます。linux-image パッケージのインストールが続いても、再起動する必要性が薄れるためです。各 kernel は boot image、initramfs、modules tree、通常は headers パッケージもインストールします。数百 megabytes の専用 /boot partition を持つ小容量 VPS では、3 つか 4 つで容量を使い切ります。

/boot が満杯になると、次の kernel のインストールに失敗します。その結果、必要な更新自体を適用できなくなります。apt autoremove は削除可能になった古い kernel を削除します。しかし、再起動しないマシンでは、まだ削除可能になっていない場合があります。package manager は、現在実行中の可能性がある kernel を削除しないためです。

そのため、インストール済みの kernel を確認し、実行中の kernel と動作確認済みの fallback を 1 つ残してください。残りは、Ubuntu で古い kernel を安全に削除する手順を使用して削除します。uname -r が現在報告している kernel は、絶対に削除しないでください。

FAQ

ライブカーネルパッチを適用すれば、VPS を再起動する必要はなくなりますか？

いいえ。ライブパッチは実行中のカーネルに読み込まれますが、ブートイメージには書き込まれません。そのため、ディスク上の linux-image は、起動時に使用したバージョンのままです。Canonical は、「Livepatch は再起動の代替ではありません。予定外の再起動を防ぎ、再起動をより細かく制御できるツールです」と明記しています。カーネルシリーズがサポート終了になると、ライブパッチの適用範囲も終了します。また、中程度の重要度のカーネル修正は、ライブパッチの対象になりません。再起動を強制されるまで待たず、任意の間隔でメンテナンス再起動を予定してください。

ライブカーネルパッチが実際に適用されているか確認するにはどうすればよいですか？

sudo canonical-livepatch status を実行し、2 行を確認します。kernel state は、実行中のカーネルシリーズがサービスの対象かどうかを示します。patch state は、そのカーネル向けのパッチが読み込まれているかどうかを示します。ls /sys/kernel/livepatch/ を使用してカーネル側から直接確認することもできます。このコマンドは、読み込まれたパッチごとに 1 つのディレクトリを一覧表示します。一覧が空の場合、クライアントの表示にかかわらず、現在メモリ上でパッチは適用されていません。

個人利用の VPS では Ubuntu Pro を無料で使用できますか？

はい。ただし、定められた上限があります。Canonical は、Ubuntu Pro について「個人利用で最大 5 台の物理マシンまで、現在も将来も無料」と説明しています。2026 年 8 月時点では、公式の Ubuntu Community メンバーは最大 50 台まで利用できます。商用利用には有料サブスクリプションが必要です。Ubuntu Pro アカウントページのトークンを使用して sudo pro attach TOKEN でマシンを登録し、その後 sudo pro enable livepatch でサービスを有効にします。

Livepatch の実行後も、カーネルの CVE が未修正と表示されるのはなぜですか？

通常は 2 つの理由のいずれかです。1 つ目は、修正が重要度のしきい値を下回っている場合です。Canonical は、Livepatch が「Critical および High の Common Vulnerability Scoring System (CVSS) と Ubuntu Priority の評価を持つカーネル脆弱性」にライブパッチを適用し、それ以外はディスク上のパッケージに任せると説明しています。2 つ目は、関数本体の変更として修正を表現できない場合です。たとえば、上流でデータ構造が変更された場合が該当します。すでに割り当て済みのオブジェクトに対して、安全に変更できないためです。どちらの場合も、更新済みのカーネルパッケージをインストールし、そのカーネルで起動すれば解決します。

ライブカーネルパッチがまったく対象にできないものは何ですか？

ユーザー空間です。Canonical は、Livepatch が「OpenSSL や glibc などのユーザー空間ライブラリにはパッチを適用しません。これらは unattended-upgrades またはシステム管理ツールの責任だからです」と明記しています。また、実行中のカーネルシリーズ内で関数本体を置き換えるだけなので、新しいカーネルバージョンや新機能を提供することもできません。さらに、__init 関数にもパッチを適用できません。これらの関数はサーバーの起動時までに実行を終え、メモリから解放されているためです。