Gnu-Linux on よ〜んの雑記

Kernel Live Patching ってなんだ？

Wed, 06 May 2026 17:13:04 +0900

よ〜んです。

AL2023 Deep Dive シリーズの一環…なんですが、今回はちょっと毛色を変えて Kernel Live Patching の話です。Amazon Linux 2023 そのものの深掘りというより、Amazon Linux 2023でも使えるLinuxカーネルのお話になります。

最近クリティカルな CVE が多いですね。カーネルの更新となると再起動を伴うわけですが、本番で動いてるサーバーを気軽に再起動できるわけもなく、かといってセキュリティパッチを放置するのも気持ち悪い。

そんなときに使えるのが Kernel Live Patching ですね。

Kernel Live Patching

一言でいうと、動いてるカーネルに対して、再起動なしでパッチを当てる仕組みです。

Linux カーネル 4.0 から入った livepatch という機能がベースになっていて、内部的には functoin tracer(ftrace) を使ってカーネル関数の呼び出し先を差し替えます。

つまり、脆弱性のある関数が呼ばれたとき、ftrace が「いや、こっちの修正済み関数を使ってね」と差し替えてくれるわけですね、素晴らしい

パッチ適用後、当該環境は不安定にならないのか。

Kernel Live Patchingはあくまで「再起動までの繋ぎ」

パッチが蓄積していくとカーネル内部の関数リダイレクトが増えていくので、長期間再起動なしで運用し続けるのは推奨されていません。

AWS は、AL2023 カーネルバージョンのリリースから 3 か月間、カーネルライブパッチを提供します。その後、カーネルライブパッチを引き続き入手するには、新しいカーネルバージョンに更新する必要があります。 Kernel Live Patching on AL2023 - Amazon Linux 2023 より

とあるので、「3 ヶ月目安でカーネルを更新してね」というサイクル推奨しているように見えます。

AL2023 での Live Patching

AL2023 でも Kernel Live Patching が公式にサポートされています。

対応環境

アーキテクチャ: x86_64 / ARM64
動作環境: EC2、オンプレミスの VM
コスト: 追加料金なし（ここ大事）

ちなみに他の OS だとライブパッチは有料だったりします。Ubuntu は Livepatch が Ubuntu Pro（商用利用は有料）の一部の機能だったりします、AL2023 なら追加料金なしで使えるのはありがたいですね。

systemd timer が結構いい

Tue, 17 Mar 2026 20:00:46 +0900

お久しぶりです、よ〜んです。

UNIXやGNU/Linuxのジョブの定時実行といえばcronですが、Amazon Linux 2023 （AL2023）では定時実行をsystemd timerで行うことが推奨されているようです。

AL2023 で廃止 - Amazon Linux 2023

なぜ`systemd timer` が推されているのか

GNU/Linuxでは、サービス管理、起動順序、ログ、失敗時の扱いがsystemd に集約されています。

だったら、定期実行も同じ世界に載せたほうが運用しやすい、ということだと私は考えます。

デフォルトでログが記録される

cronはログを保存しません。

なので、ログを残す場合、以下のようなおまじないをしてあげる必要がありました。

* * * * * command >> /var/log/job.log 2>&1

コーディングエージェントが良くやるやつですね

ステートがある

もちろんcronでもログを残したり、終了したらDBに状態を格納したり、Discordなどに通知する仕組みを入れておくことで状態を持たせることは可能です。

一方、systemd timer(というかsystemd)では、↑のような一手間を加えずに状態を持ちます。

リトライがある

そして、systemd側で状態を持っているということは、リトライが可能になります。

cronでも実行するジョブ側に自前実装でリトライさせることは可能です。

systemd service (NOT systemd timer)なら、失敗時の扱いを記述し、リトライさせることが可能です。

Restart=on-failure
RestartSec=30s
OnFailure=

systemd timerの機能の一つであるPersistent を使うことで、例えば10時に実行するjobがあったときに、ジョブ実行を行なっている計算機がシャットダウンしていても、計算機起動後にジョブを実行してくれます。

実行時間に厳密である必要はないが、大体このぐらいの時間に実行してほしいといったパターンにめっちゃ便利だなと思いました。

上記のような点から、systemd timerではcronで自前実装・不便だったポイントが標準で揃っていることがわかりました。

`cron`から`systemd timer`に移行するには

たとえば、こういう cron があったとします。

0 3 * * * /usr/local/bin/daily.sh

まずは何を実行するか を .service に、いつ実行するか を .timer に書いていきます。