【第13回】Ubuntuの商用サポートと、無償で使える「Kernel Livepatch」機能

Ubuntuの商用サポートは「Ubuntu Advantage」から「Ubuntu Pro」という名前に変更になった

　2022年10月5日にUbuntuを支援しているCanonicalが、新しい商用サポートサービス 「Ubuntu Pro」 の概要を公開した。今回はこのサポートサービスの内容と、無料でも利用できる機能、特に再起動することなくカーネルを更新できる「Kernel Livepatch」について紹介しよう。

Ubuntu ProとUbuntu Advantage

　まず最初に、Ubuntuは第1回「Ubuntuのススメ」も紹介したように、「誰でも使える」ことを目指したLinuxディストリビューションだ。この「誰でも」の中には「できるだけお金を払いたくない人」も当然含まれる。2004年に登場して以来ずっとUbuntuは無償で提供されてきたし、これからも提供され続ける。

　しかしながら数々の開発インフラを維持し続けるのはそれなりに費用がかかる。よって何らかの方法でその維持費用を確保しなければいけない。Debianのように特定の企業に依存せず、ほぼ寄付だけで大規模な開発コミュニティを維持し続けられているのは稀有な例なのだ。そこで出てくるのがUbuntuのサポート企業であるCanonicalによる商用サポートサービスである。

　実はCanonical自身は、創業である2004年からグループ全体としては赤字が続いていた。この間は、Ubuntuの生みの親でもあるマーク・シャトルワースの個人資産によって事業を続けてこれたと言っても過言ではない。業績が改善したのは、やはりサーバーのシェアが増え、そのサポートサービスが順調に増えていったことによる。Ubuntu自体が2009年ぐらいからEucalyptusベースのクラウド環境の構築を提案し、2011年ぐらいからプライベートクラウドとしてOpenStackに注力するようになり、その数年後にはOpenStack実行環境の半分以上がUbuntuとなっていた。結果、CanonicalとしてもOpenStack関連の部門だけなら2015年ぐらいまでには黒字になっていたようだ。

　その後、デスクトップ・スマートフォン関連部門の整理などを経て、2018年度にはグループとしての経常利益が黒字になっている。つまりCanonicalとしても「ようやく軌道に乗った」というのが現在の状況だ。

　いずれにせよCanonicalにとってUbuntuのサポートサービスは事業の根幹に関わる部分であり、今ここの仕組みを見直した事実は大きい。

　少しややこしいのだが、もともとCanonicalのサポートサービスは「Ubuntu Advantage」という名前だった。その後、2019年の年末にUbuntu Advantageがバンドルされた特殊なクラウドイメージとして「Ubuntu Pro」が登場する。今回のアナウンスはこのUbuntu AdvantageをUbuntu Proにリブランディングして、さらにUbuntu Proの中でデスクトップ向け・物理サーバー向けやサポート範囲などを細分化して料金が決まる形態に変更されたというわけだ。

Ubuntu Proの価格プラン

　Ubuntu Advantage時代は物理マシン/仮想マシン/デスクトップごとにEssential/Standard/Advancedというプランが用意されていた。Ubuntu Proでは仮想マシンという概念がなくなり、プランもサポート範囲/サポートチケットの有無/対応時間によって細分化されることとなった。詳細はUbuntu Proの価格プランのページを確認して欲しいが、ざっくりまとめると次のようなリストとなる。

Kernel Livepatchの仕組み

　さて、今回の本題である Kernel Livepatch の話に移ろう。

　世にあるほとんどのLinuxディストリビューションは、ハードウェアとソフトウェアの仲立ちをするシステムのコア機能として「Linuxカーネル(Linux Kernel)」を採用している。Linuxカーネルは大きなソフトウェアであり、なおかつ特権で動作するプログラムであるため、それなりの頻度で脆弱性が見つかるし、影響範囲が大きなものもそこそこ存在する。よってシステムをセキュアに保つためには、短い頻度でカーネルを更新することが求められる。

　ところがLinuxカーネルを更新する場合、更新結果を反映するためにはシステムの再起動が必要になってしまう。できるだけ安定運用しダウンタイムを減らしたいサーバー用途では、頻繁な再起動は避けたいところだ。ここでセキュリティパッチは早く適用したいけれども、それに伴う再起動は避けたいというジレンマが発生する。

　そこで出てくるのが「Kernel Livepatch」だ。これはざっくり言うと、修正が必要な部分を「モジュール」として構築し、そのモジュールをロードすると本来の処理をフックして(脆弱性対応済みの)モジュール側で処理を肩代わりするというものだ。カーネルモジュールはシステムを再起動することなくロード・アンロードできるので、カーネルを動かしたまま脆弱性へのパッチを適用できる。

Livepatchでは、カーネル内関数をトレースするftrace機能を使って処理を差し替えている。Livepatchモジュールをロードするとftraceに追加した処理の上書き対象を登録する。上書き対象の処理が呼び出されたら、ftraceがそれを検知し、登録済みの処理にリダイレクトすることで新しい処理が実行される。これによりLivepatchモジュールをロードするだけで、呼び出し元の処理を変更することなく、任意の処理を修正できるのだ

　Livepatch機能そのものは、Linux Kernel 4.0で実装されたカーネルの標準的な機能である。よってUbuntu Proを有効化するかどうかや、Ubuntuを使うかどうかに関係なくLivepatch機能を利用できる。Ubuntu Proが提供しているのは「個々のセキュリティ修正ごとに作られ、カーネルバージョンごとにCanonicalで検証された、Livepatch機能でロード可能なカーネルモジュール」とそれを配信する仕組みであり、さらに必要に応じて適切なモジュールを取得するクライアントプログラムなのだ。

　ちなみにLivepatchの仕組み上、すべての修正に対応できるわけではない。たとえば関数の内部処理が少し変わる程度だと、それを差し替えれば問題ないことがわかるだろう。しかしながら複数の関数が絡み合うと途端に話は複雑になる。たとえば関係するすべての関数群が誰からも呼び出されていないタイミングを見計らって、一度に差し替える対応が必要になるかもしれない。そこでLivepatch機能では、修正モジュールをロードしたあともすぐに適用されるわけではなく、内部的なステートマシンが状況を確認しつつ置き換えることになる。

　そしてそのような複雑な方法でも動くパッチを作らなくてはならないため、「すべての修正が再起動不要になる」わけではない点に注意が必要になる。Canonicalのサービスでも、脆弱性の脅威度がHighかCriticalなもののうち、Livepatchで対応可能なものだけが提供される。脆弱性の脅威度がMedium以下と低かったり、ただの不具合修正・機能の追加に関してはLivepatchは提供されない。このような修正を適用するためには、従来と同じようにカーネルパッケージを更新し、再起動が必要となる。

　また、Ubuntuでサポートしているamd64アーキテクチャー向けのカーネルでしか利用できない点にも注意しよう。具体的にはLTS(長期サポート版)で採用されているGA(General Availability)カーネルと、HWE(Hardware Enablement)カーネルの2種類だけになる。前者がLTSがリリースされた時に採用されたカーネルバージョンで、後者が半年ごとのポイントリリースで採用されるカーネルだ。独自ビルドはKernel PPAのカーネルは使えないので注意して欲しい。ほかにもRaspberry Piをサーバーとして運用する場合にもLivepatchは使えない。詳しいサポートリストはUbuntuのドキュメントに掲載されている。

Ubuntu ProでLivepatchを有効化する

　実際にLivepatchを有効化する手順を説明しよう。最初に説明したようにCanonicalのLivepatchサービスは、商用サポートサービスの一環として提供される。しかしながら 個人で5台のマシンまでなら無料で利用可能 だ。ちなみにUbuntuの公式メンバー(参照:ubuntu.comのメールアドレスが付与されたメンバー、@ubuntu.comのメールアドレスが付与されたメンバー)なら、50台まで無料だったりする。

　なぜ無償で提供されるかと言うと、Livepatchはカーネルモジュールというクリティカルなプログラムとして提供される以上、できる限り幅広い利用者が動作確認し、問題を報告してもらう必要があるからだ。よって無料プランでLivepatchを有効化すると、ステータス上は「Livepatchのベータテスター」扱いとなる。もちろんCanonical側でテストしたモジュールが配信される以上、問題が起きることはそうそうないので安心して使ってほしい。

　Livepatchを使うためにはまずはUbuntu Proを有効化する必要があるため、Ubuntu Oneのアカウントが必要になる。これはUbuntuの各種サービスで使えるシングルサインオンのアカウントで、作成だけなら誰でも可能だ。アカウントを持っていない場合は「Ubuntu Oneのページ」からアカウントを作成しよう。

Ubuntu Oneのログイン画面で「I don’t have an Ubuntu One accoun」を選択すればアカウントも作成できる。このアカウントはUbuntuコミュニティやチケットトラッキング等でも使えるので、開発に参加する予定があるなら取得しておくと良いだろう

　ログインしたら「Ubuntu Pro」のページに移動する。そうすると「Free Personal Token」の項目に「Token」文字列が表示されるのでこれをコピーしておこう。

Ubuntu Proのトークンページ。トークンは秘密情報なので管理には気をつけよう

　次に「ソフトウェアとアップデート」を起動しよう。「Superキー(Windowsキー)+A」を押して「repository」で検索すれば「ソフトウェアと」とラベルのついた青いアイコンが表示されるはずだ。起動したら「Livepatch」タブに移動する。

「ソフトウェアとアップデート」のLivepatch設定ページ

　ここで「このマシンのアタッチ」を選択する。「Ubuntu Advantageのトークン」を入力する画面があらわれるので、先ほど表示したトークンを入力しよう。もし「アタッチに失敗した」と表示された場合はいったん「キャンセル」を押して元の画面に戻ってみよう。「このマシンのアタッチ」が「このマシンをデタッチ」に変わっていたら成功した状態だ。

アタッチするとLivepatchも自動的に有効化される

　ちなみにアタッチすると自動的に「calonical-livepatch」パッケージがインストールされ、デスクトップの場合はトップバーにステータスが表示されるようになる。これでLivepatchの設定完了だ。Ubuntu Proのページを再読込すると、「Active machines」の数が増えていることが分かる。もしマシンをデタッチしたいなら、同じ設定画面から「このマシンをデタッチ」ボタンを押すと良いだろう。

あえて古いカーネルからLivepatchを動かしてみる

　おそらくLivepatchを有効化した状態だと最新のカーネルになっているため、動作確認ができないだろう。そこで今回はあえて古いカーネルをインストールしてそれで起動する方法も紹介しておこう。

　Ubuntuの場合、カーネルは最後に更新したものとその1個前のバージョンのみが残っている。よってGRUBから1個前のバージョンに戻すことは可能なのだが、1個前だとLivepatch可能な差分かどうかが怪しいところだ。そこでUbuntuのリリース時のバージョンに戻してみよう。これはUbuntuのリリースごとに異なる。

Ubuntu 22.04 LTSの場合
$ sudo apt install linux-image-5.15.0-25-generic linux-modules-extra-5.15.0-25-generic

Ubuntu 20.04 LTSの場合
$ sudo apt install linux-image-5.4.0-26.30-generic linux-modules-extra-5.4.0-26.30-generic

　さらに再起動後は古いカーネルを選択するように設定を変更する。これにはいくつかの方法がある。

• 起動時にPCのロゴがでてきたら、ESCを連打してGRUBメニューを表示する
• /etc/default/grubを変更しタイムアウト時間を延ばす
• grub-rebootコマンドで一時的に起動エントリーを変更する

　1番目が簡単で確実ではあるが、ESCキーを連打するタイミングが結構難しい。Ubuntuをうまく起動できなくなった時に必要になることもあるため、ここであえて試してみるのもいいだろう。ESCキーを連打すれば次のようなメニューが表示されるので、「Advanced options for Ubuntu」を選択し、「Linux 5.15.0-25-generic(上記でインストールしたバージョン)」を選択しよう。「recovery mode」は起動できなくなった時のオプションなので今回は無視して良い。

GRUBメニューはカーソルキーで移動しEnterキーで選択だ

　もし次のようなGRUBプロンプトになってしまった場合は「normal」と入力し、Enterキーを押したらすぐに1度だけESCキーを押せば、メニュー画面になるはずだ。

ESCキーを押しすぎるとGRUBプロンプトに遷移してしまう

　確実にメニューを表示したいなら2番目の方法となる。これは「/etc/default/grub」の中を「GRUB_TIMEOUT_STYLE=」の値を「menu」にし、「GRUB_TIMEOUT=」の値を「10」にすることで対応可能だ。ただしこのファイルを編集するには管理者権限が必要になる。単純に次のようなコマンドを実行すると変更可能だ。

$ sudo sed -i 's/^\(GRUB_TIMEOUT_STYLE=\).*/\1menu/' /etc/default/grub
$ sudo sed -i 's/^\(GRUB_TIMEOUT=\).*/\110/' /etc/default/grub
$ sudo update-grub

　最後の「udpate-grub」で設定を反映している。ただしこの方法は起動時間が純粋に10秒増えてしまう。必要なくなったらもとに戻しておこう。元に戻す場合は上記の「menu」と「10」(110)を「hidden」と「0」(10)に変更して実行しなおすと良いだろう。

　3番目の方法であるgrub-rebootは「次の再起動のときだけ、一時的に起動するカーネルを変えたい」場合に便利なコマンドだ。ただし、Ubuntuの場合、起動エントリーの指定が若干厄介ではある。まず、次のようなコマンドを実行してみよう。

$ grep -oE "^\s*(menuentry|submenu) '[^']*'" /boot/grub/grub.cfg
menuentry 'Ubuntu'
submenu 'Advanced options for Ubuntu'
    menuentry 'Ubuntu, with Linux 5.15.0-50-generic'
    menuentry 'Ubuntu, with Linux 5.15.0-50-generic (recovery mode)'
    menuentry 'Ubuntu, with Linux 5.15.0-25-generic'
    menuentry 'Ubuntu, with Linux 5.15.0-25-generic (recovery mode)'

　この「menuentry」がgrub-rebootで指定するエントリーとなる。しかしながら「submenu」の下にあるエントリは、submenuを選択した上で、その下のメニューを選択することになる。つまり今回の場合、「Ubuntu, with Linux 5.15.0-25-generic」を選択したいわけだが、まず最初にsubmenuの番号(0番から始まるので1)を指定し、次にsubmenuの中のmenuentryの番号(0番から始まるので2)を指定する。

$ sudo grub-reboot '1>2'

　grub-reboot実行後に再起動すれば、一時的に「Ubuntu, with Linux 5.15.0-25-generic」を起動できるというわけだ。grub-rebootは「次の起動方法」だけを変更する。もう一度再起動すれば、変更前のカーネルが選択されるため、一時的に変更したい場合に便利な方法となる。

　いずれにせよ古いカーネルで起動して数分すると自動的にLivepachによりカーネルにパッチが適用される。トップバーのLivepatchステータスアイコンではいくつパッチが適用されたか表示されるが、もっと少し詳しく見たい場合は次のコマンドを実行すると良いだろう。

$ canonical-livepatch status --verbose
last check: 3 minutes ago
kernel: 5.15.0-25.25-generic
server check-in: succeeded
patch state: ✓ all applicable livepatch modules inserted
patch version: 89.1
tier: updates (Free usage; This machine beta tests new patches.)
machine id: 965edc151d8f488bb76843c9b7e5f826
client version: 10.2.3
architecture: x86_64
cpu model: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
boot time: 3 minutes ago
fixes:
  * cve-2013-1798
    Andrew Honig reported a flaw in the way KVM (Kernel-based Virtual
    Machine) emulated the IOAPIC. A privileged guest user could exploit
    this flaw to read host memory or cause a denial of service (crash the
    host).
  * cve-2018-25020
    LP bug:
  * cve-2019-0155
    It was discovered that the Intel i915 graphics chipsets allowed
    userspace to modify page table entries via writes to MMIO from the
    Blitter Command Streamer and expose kernel memory information. A local
    attacker could use this to expose sensitive information or possibly
    elevate privileges.
  * cve-2019-0155:
    LP bug: 1852141
(後略)

　なお、Livepatchのカーネルモジュールは「/sys/kernel/livepatch」以下に展開されている。

　最後に、Livepatch機能はあくまでセキュリティ対応を適用したいけれども即座に再起動するのは厳しいサーバー向け、一時的な回避手段を提供する機能である。もちろんデスクトップで使用しても問題はない。ただしカーネルの更新時には、Livepatchでは解消しない不具合も修正されていることが多いため、「Livepatchは一時的な回避手段である」ことに念頭を置いて、再起動できるタイミングを見つけたらなるべくはやく再起動してカーネルを更新することをおすすめする。