HA Clustering (SAF based)
3.3 ライブパッチ方式による既製コンピュータでのオンライン 修正修正
表3.1.既存のオンライン修正方法の比較
方式 既製コンピュータへ
の適用
高速性 修正可能エリア
専用コンピュータを 用いる交換システム のオンライン修正
×:専用コンピュータ のみで実現可能
○:オンライン修正で あり高速
○:ユーザソフトウェ ア，カーネルに適用 可能
Java Hotswap
○:Linuxで使用可能 ○:オンライン修正で あり高速
×:JavaVMプロセス 内のユーザタスクの み適用可能
kexec による kenrel の高速再起動
○:Linuxで使用可能 ×:高速再起動である が初期化が必要
△:カーネルへのみ適 用可能
Hotswap機能は既製コンピュータに適用可能であるが，修正可能なソフトウェアがJavaVM
上で動作するプログラムに限定される．JavaVM自体及びOS等，サービスに使用されるソフ トウェア全域を修正することができない．
kexecによるカーネルの高速再起動
00000000004004a8 <print_test>:
4004a8: push %rbp 4004a9: mov %rsp,%rbp 4004ac: mov $0x4005bc,%edi 4004b1: mov $0x0,%eax
4004b6: callq 4003e0 <printf@plt>
4004bb: leaveq 4004bc: retq
00000000004004bd <main>:
4004bd: push %rbp 4004be: mov %rsp,%rbp
4004c1: callq 4004a8 <print_test>
4004c6: leaveq 4004c7: retq 4004c8: nop
00000000000006cc <print_plug>:
6cc: push %rbp 6cd: mov %rsp,%rbp 6d0: lea 95(%rip),%rdi 6d7: mov $0x0,%eax 6dc: callq 608 <printf@plt>
6e1: leaveq 6e2: retq 6e3: nop
The instruction pointer of the task is changed to a modified function address without pushing the stack by overwriting the first instruction using a jump instruction and CPU executes the overwriting instruction.
The task pops the stack and returns to the status after print_test() is invoked by executing a return instruction.
Start point
図3.1.jump命令上書きによる修正関数の実行例
る電話サービスでは，あらかじめ以下の手順でサービスの開発，導入，運用を行う(図3.2)．
• 開発者がサービスソフトウェアのソースコード，ロードモジュールを作成する．
• 作成されたロードモジュールとライブパッチ方式を有したカーネルを使用してサービス を開始する．
• 保守者はサービスを実施するシステムの正常性を監視し，何らかの異常を発見した場 合，開発者へ連絡を行う．
• 開発者は問題を解析し，ソフトウェアに不具合がある場合，ソースコードの修正を行う．
その後，以下の手順にてオンライン修正を実施する(図3.3)．
(1) 修正用ロードモジュールの作成：開発者は修正されたソースコードから修正された変更 部分を取り出し，修正用ロードモジュールを作成し，保守者に提供する．
(2) 修正用ロードモジュールのロード：保守者は修正用ロードモジュールをサービス提供シ ステムに投入する．サービス提供システム上には，ライブパッチによる修正を行うラ イブパッチプロセスが存在する．ライブパッチプロセスは投入された修正用ロードモ ジュールを修正対象のプロセスまたはカーネルのメモリ空間にロードし，アドレス解決 を行う．
(3) 修正用ロードモジュールへの実行遷移：保守者はロードされた修正用ロードモジュール を有効化する．有効化の指示を受けたライブパッチプロセスは修正用の処理が実施され るよう修正対象のプロセスまたはカーネルに修正を実施する．具体的には，修正対象の 処理が呼び出される際に，修正用ロードモジュールに含まれる修正用の処理が実行され るよう，実行アドレスを遷移するための修正を行う．この遷移を実施させるためには次 に示す２点を考慮する必要がある．
(3-a) 実行アドレスの遷移方法：修正対象関数の実行アドレスをどのような命令を用いて
修正関数へ遷移させるか．
(3-b) メモリ上への遷移命令の書込み方法：（3-a）で提案した遷移命令を汎用マルチプロ
セッサ上でいかにメモリ上に安全に書込むか．
本シーケンスは，実際の運用システムのいずれか，若しくは検証用のシステムに障害が生じ た後にライブパッチにより他の運用システムへ修正を行なうシーケンスである．ネットワーク サービスでは一定のユーザ数単位で交換システムが存在し，通常サービス毎に数十台〜数百台 単位のシステムが存在する．ある１つのシステムで発生した障害の修正を，他システムにてそ の障害が生じる前にオンライン修正することはきわめて重要である．
ライブパッチ方式においては，関数の修正及びデータの修正を実現するが，以下では説明の 簡易化のため，C言語の関数を修正する場合について説明する．データの修正は関数の修正 を行なう際に分岐命令を上書きする手法と同じ手法でデータを上書きする．またプロセスに対 するライブパッチをプロセスライブパッチ，カーネルに対するライブパッチをカーネルライブ パッチと呼ぶ．
なお悪意をもったプログラムがライブパッチ方式を有したシステム上に存在すれば，脆弱性
が高まるおそれもある．ライブパッチ方式は電話サービスを提供するシステムのように，極め て高度に管理された環境で運用されるシステムに適用されるべきであり，ユーザが直接ログイ ンする種のシステム等には適用すべきではない．
次に上述した(1)〜(3)の方式を説明する．
3.3.1 修正用ロードモジュールの作成
ライブパッチ方式の修正用ロードモジュールは，再配置可能な共有オブジェクト形式でコン パイルする(図3.2の8，図3.3の1)．本オブジェクト形式は広くLinuxで使用されている．
3.3.2 修正用ロードモジュールのロード
プロセスライブパッチでの修正用ロードモジュールのロード プロセスライブパッチでは，ラ イブパッチプロセスが修正用ロードモジュールを修正対象プロセスのメモリ空間にロードする (図3.2の10，図3.3の2)．
しかしLinuxでは仮想記憶を用いており，個々のプロセスが独立した仮想アドレス空間を
もつ．このため修正対象プロセスの任意のアドレス空間に外部のプロセスからアクセスするこ とができない問題が存在する．この仮想アドレス空間はカーネルの仮想記憶管理によって制御 され，各プロセスのメモリの使用状況に応じて物理アドレスの割付が行われる．
この問題を解決するためにプロセスライブパッチでは，カーネルの仮想記憶管理を介して，
対象プロセスの仮想アドレス空間にアクセスすることで，修正用ロードモジュールのロードを 行う方式を提案する（図3.4）．
一方，修正用ロードモジュールをロードする方法として，個々の修正対象プロセスにライブ パッチプロセスと通信し，任意のアドレスへのアクセスを可能とする機能をもたせることも可 能であるが，数多くのユーザ空間のソフトウェアの変更が必要となり，効率的ではない[50]． カーネルパッチでの修正用ロードモジュールのロード カーネルライブパッチでも同様にライ ブパッチプロセスが修正用ロードモジュールをカーネルのメモリ空間にロードする(図3.2の 10，図3.3の2)．しかしカーネルのアドレス空間もまた，カーネルの記憶管理によって管理 されており，外部のプロセスからカーネルの任意のアドレスにアクセスすることはできない．
カーネルライブパッチではカーネルアドレス空間を管理するカーネルの記憶管理を介してカー ネルの修正アドレスにアクセスする方式を提案する．
3.3.3 修正用ロードモジュールへの実行遷移
ライブパッチ方式では修正対象の関数が実行された際に，修正用ロードモジュールに含まれ る修正関数へ実行アドレスを遷移させる．
以下では3.3で示した(3-a)，(3-b)の課題解決について示す(図3.2の10，図3.3の3-1， 図3.3の3-2)．