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

VPS でのライブカーネルパッチ適用とは

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

ライブパッチ適用により、時間を確保できます。ただし、再起動が不要になるわけではありません。6か月間ライブパッチを適用しているサーバーでも、ディスク上の古いカーネルイメージで起動した状態が続いており、適用したパッチはすべてメモリ上にしか存在しません。

ライブパッチ適用は、マネージドプランの機能として提供されることがよくあります。アンマネージド環境では、2つのコマンドを実行して自分で有効化できます。マネージド VPS とアンマネージド VPS の違いに料金を支払う前に、この点を知っておく価値があります。

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

カーネルには、CONFIG_LIVEPATCH を指定して組み込まれるライブパッチ機能のコアが組み込まれています。実行中のカーネルにこの機能があるか確認します。

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

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

コードの転送には、カーネルの関数トレーサーである ftrace を使用します。ほとんどのカーネル関数は、関数の最上部に call 命令を配置してコンパイルされます。引数やスタックが変更される前の位置です。ftrace は、この call の位置をフックとして使用します。パッチを適用すると、ライブパッチ機能のコアが対象関数に ftrace ハンドラーを登録します。ハンドラーは、代わりに置換関数へ処理を転送します。カーネルのドキュメントにも、次のように明記されています。「ライブパッチでは通常、関数の引数やスタックが何らかの形で変更される前に、関数エントリの最初の位置でコードを転送する必要があります。」

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

より難しいのは、実行中のシステムで安全に切り替えることです。関数を置き換えた時点で、いずれかの CPU のスタック上で古いコードが実行中だと、古い動作と新しい動作が混在します。上流の Linux は、タスク単位の整合性モデルによってこの問題に対処します。カーネルのドキュメントでは、これをハイブリッド方式と説明しています。「kGraft のタスク単位の整合性と syscall barrier の切り替えを、kpatch のスタックトレース切り替えと組み合わせて使用します。」カーネルが、そのタスクが現在パッチ対象の関数内にいないことを確認できた場合に限り、タスクを 1 つずつ新しいコードへ移行します。すべてのタスクの移行が完了するまで、パッチは移行中の状態です。

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

ls /sys/kernel/livepatch/

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

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

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

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

Ubuntu のサービスには、深刻度に関する境界もあります。Canonical は、このサービスが「Common Vulnerability Scoring System (CVSS) と Ubuntu Priority の評価で critical および high のカーネル脆弱性にパッチを適用する」と説明しています。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 が提供する商用エージェントです。first-party サービスのないディストリビューションを含む、多数のディストリビューションに対応します。公式のインストール方法では、ベンダーのスクリプト curl -s -L https://kernelcare.com/installer | bash を実行し、続いてキー方式のライセンス用に /usr/bin/kcarectl --register KEY を実行します。エージェントは独自のスケジュールで新しいパッチを確認し、/usr/bin/kcarectl --update を実行すると確認を強制できます。重要なサーバーでスクリプトを shell にパイプする前に、インストーラーの内容を確認してください。

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 アカウントページからトークンを取得します。以下の 2 つのコマンドでは、クライアントが Canonical のサーバーに接続してアタッチとパッチの取得を行うため、外向きネットワーク接続が正常に機能している必要があります。

sudo pro attach TOKEN
sudo pro status

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

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

sudo pro enable livepatch
sudo canonical-livepatch status

このサービスは canonical-livepatch snap から実行されるため、有効化を完了するには snapd が正常に動作している必要があります。pro status では、各サービスの利用権と状態を表形式で表示します。canonical-livepatch status ではカーネルごとの詳細を表示します。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 は、現在実行しているカーネル系列がサービスの対象になっているかどうかを示します。Livepatch がサポートしていないカーネルで起動すると、この行が問題を示す状態になります。patch state は、そのカーネルに適用できるパッチが実際に読み込まれているかどうかを示します。対象カーネルなのにパッチが適用されていない場合は、クライアント側の問題です。対象外のカーネルの場合は、カーネル側の問題であり、クライアント設定では解決できません。

再起動が保留されているか確認するには

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

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

同じ確認の userspace 側では、needrestart が Ubuntu Server にデフォルトでインストールされており、削除済みのライブラリファイルを保持している実行中のサービスを一覧表示します。

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 に更新することです。つまり、再起動が必要です。

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

長時間稼働している kernel には、パッチ適用では消去されない状態も蓄積します。Canonical 自身の見解は率直で、引用する価値があります。Livepatch は「再起動の代替ではありません。予定外の再起動を防ぐことで、再起動のタイミングをより適切に管理できるツールです」。ここで重要なのは「予定外」という言葉です。再起動は必要です。実行するタイミングを選べるだけです。

再起動後に復旧するよう再起動を予約する方法

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

• プロバイダーのコントロールパネルで、シリアルコンソールまたは VNC（仮想ネットワークコンピューティング）画面を利用できることを確認し、障害発生時ではなく今のうちに開いておきます。
• df -h /bootで空き容量を確認します。/bootが満杯になると、カーネルパッケージが initramfs（初期 RAM ファイルシステム）を書き込めずに失敗することがあります。その結果、完成していないイメージを指すブートローダーのエントリが残る場合があります。
• 既知の正常な古いカーネルを少なくとも1つ残しておきます。GRUB では「Advanced options for Ubuntu」の下に表示されます。新しいカーネルで起動できない場合は、これを起動するのが最も速い復旧方法です。
• 必要になる前に、プロバイダーのレスキューモードを確認しておきます。再起動後にコンソールへ initramfs のプロンプトが表示された場合は、そこで修復します。

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

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

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

uname -r
sudo canonical-livepatch status

uname -rで新しいカーネルが表示され、ステータス出力で新しいシリーズが適用対象になっていることを確認できます。マシンがまったく復旧しない場合、原因はほぼ常にネットワークではなくブート経路にあります。その場合の復旧手順は、カーネル更新後に起動しない VPS のガイドに記載しています。

古い kernel の削除が必要な理由

Live patching はこの問題を改善するどころか、悪化させます。linux-image パッケージのインストールが続いても、再起動する必要性が薄れるためです。各 kernel は boot image、initramfs、modules tree、および通常は headers パッケージをインストールします。数百メガバイトしかない専用の /boot パーティションを使用する小規模な VPS では、3 つか 4 つの kernel で容量を使い切ります。

/boot が満杯になると、次の kernel のインストールに失敗します。その結果、マシンは必要な更新自体を適用できなくなります。apt autoremove は、削除可能になった古い kernel を削除します。ただし、再起動しないマシンでは、まだ削除対象にならないことがあります。パッケージマネージャーは、現在も使用している可能性がある 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 関数にもパッチを適用できません。