ミニカーネル・テクニカルノート

既存のクラッシュダンプの問題点

標準のLinuxカーネルでは、クッラシュダンプ機能は入ってい ません。
そこで、Linuxにクラッシュダンプ機能を追加するために LKCD[1]、 netdump[2]、diskdump[3]等のツールの開発が行われてい ます。
しかし、これらの既存のクラッシュダンプ機能には、ダンプ採取の確実性の観点から、大きく二つの問題点が存在 します。

一つ目は、資源の問題です。特に資源のロックに問題があ ります。
いずれのクラッシュダンプ・システムもデバイスへの出力は、 既存のドライバを使用します。ドライバは、通常のカーネルサービスを使用 しますが、もし仮にクラッシュを引き起こした処理が、ダンプ出力のために必要な資源をロックしていた場合、ダンプ処理はデッドロックに陥ることにな ります。また、マルチプロセッサ・システムにおいては、クラッシュダンプの開始時に他のCPUで実行中の処理については強制的に中断させられるため、ダンプ出力にために必要な資源を ロックしていれば、ダンプ処理はデッドロックに陥ります。
ロックはしていなくても、資源不足のためにダンプ処理が失敗する可能性もあ ります。

二つ目は、制御表の信頼性の問題です。カーネルがクラッシュするということは、カーネル内に何らかの矛盾が生じているということであり、 制御表が破壊されてる可能性が高いわけです。既存のクラッシュダンプでは、 ダンプの出力にカーネルの通常の機能を使用しているために、破壊されている制御表を参照する可能性が高くな ります。

元々、クラッシュダンプ機能は、カーネルがもはや信用できないという前提で、必要最小限かつ動くルートを完全に把握して設計されていなければな りません。

Linuxの既存のクラッシュダンプ機能の問題点は、カーネルが正常に動くことを前提として設計されていることであると言え ます（特にLKCD）。

Linux カーネルは、複雑化の一途をたどっており、SCSIサブシステムを取り上げても、その動きを完全に把握することは 困難です。既存の Linuxカーネルの中に制御可能なダンプルートを設けることは難しいと考えられ ます。したがって、既存のカーネルと無依存にダンプを採取できる機能を考える必要が出てくるので す。

ミニカーネルダンプ

VA Linuxは、ミニカーネルダンプと呼ぶ手法により、ダンプ採取の確実性を向上させ ました。ミニカーネルダンプの基本的なアイデアは、クラッシュ時に別のカーネルを立ち上げてダンプを採取することで す。ミニカーネルダンプの処理の流れは以下のように なります。

1.の処理は、システムを起動した後になるべく早い段階で行ってお きます。
ミニカーネルが動作するのに必要な領域は、4MBもあれば十分で す。
数GBも搭載するシステムにおいて、ダンプ採取のために4MBの領域を消費することは、実用上問題にならないと考え られます。ミニカーネルは、クラッシュしたカーネルの資源とは全く無関係に動作するため、【前述、既存のクラッシュダンプの問題点】で述べた問題は ありません。

mkexec

ミニカーネルの起動は、kexec[4]と同じ仕組みを使ってい ます。コードもkexecのコードを改造して使っています。ミニカーネル用kexec（mkexec）とkexecの大きな違いは、以下の通りで す。

ミニカーネル用に確保する領域は、複数の領域とすることも可能で す。
しかし、ダンプ処理だけを行うのであれば、4MB あれば十分であり、 一つの領域として確保した方が単純です。

mkexecは、カーネルモジュールにもできるようになって します。ただし、わずかでありますが、カーネルにパッチが必要で す。もし、kexecが標準カーネルに取り込まれれば、mkexecで必要なカーネルパッチは、クラッシュ時のダンプ処理呼び出しフックだけと なります。mkexecは、kexecと共存可能です。

mkexecでは、ミニカーネルをロードした後に確保した領域をリードオンリーに設定 します。カーネルクラッシュの影響でミニカーネルが破壊される可能性を少しでも低くすることができ ます。

ミニカーネル

ミニカーネルは、ダンプ取得専用のカーネルであり、通常のカーネルとは異な ります。しかし、通常のカーネルのコードを使用して作成 します。

ミニカーネルを作るためには、まず、通常のカーネルの以下の二つのパッチを適用 します。

初期化終了後、ダンプ採取処理を実行し、リブートするだけで す。
ルートファイルシステムのマウントも行いません。次にコンフィグレーションを実施し、カーネルのmakeを行 います。このとき、必要最小限のドライバのみを静的に組み込むように します。

ダンプを確実に採取する観点から、余分な処理は極力実行しないようにすべきで す。特にファイルシステムに関しては、システムクラッシュ時に破壊されている可能性があるため、マウントすべきでは ありません。

ミニカーネルで行える作業の柔軟性を高めるために、initrd と同じ仕組みで、ルートファイルシステムをあらかじめ用意し、ミニカーネルと同時にメモリに格納しておき、RAMディスクとしてマウントする機能のサポートを予定してい ます。ただし、ダンプを確実に採取することが重要であり、何でもしてよいというわけではないことに注意して ください。

ミニカーネルには、デバイスドライバの修正が全く入ってい ません。
そのため、標準のカーネルでサポートしているデバイスはすべて使用でき ます。
これは、HBAドライバに修正が必要であるdiskdumpと比較して、大きな長所で す。

ダンプデバイスとしては、ディスク装置のみに対応してい ます。
ネットワークに対応することももちろん可能ですが、ダンプ採取の確実性の観点からは、ネットワークダンプは望ましくないと考え ます。

ダンプフォーマット

システムクラッシュ時には、ミニカーネルの起動前にコンテキストの保存を行 います。ミニカーネルでは、基本的にメモリをそのままダンプデバイスに出力 します。システムクラッシュ時には、カーネルの制御表は信頼できないため、メモリはそのまま出力すべきで す。

ダンプの解析には、lcrash または、crashコマンドを使用します。
出力したダンプを LKCD形式または、netdump形式に変換するツールを用意してあ ります。変換は容易です。なお、解析ツールの改善にも 取り組んでいます。

総括

参考：