はじめに
この実験では、Linux カーネルの汚染状態 (taint status) を確認する方法を学びます。/proc/sys/kernel/tainted ファイルを調べることで、カーネルが潜在的にサポートされていない状態または変更された状態で実行されているかどうかを判断する方法を探ります。
最初の確認の後、dmesg コマンドを使用してカーネルメッセージバッファを調べることで、カーネルが汚染されている具体的な理由を確認する方法を学びます。最後に、/proc/kallsyms を使用してカーネルシンボルを調べる方法を探ります。これは、カーネルの状態やロードされたモジュールを理解するのに役立ちます。
cat /proc/sys/kernel/tainted で汚染状態（taint status）を確認する
このステップでは、Linux カーネルの「汚染」状態 (taint status) を確認する方法を学びます。非 GPL (General Public License) モジュールがロードされた場合や、問題または非標準の設定を示す特定のイベントが発生した場合、カーネルは「汚染」される可能性があります。汚染状態を確認することは、カーネルが潜在的にサポートされていない状態または変更された状態で実行されているかどうかをすぐに確認する方法です。
/proc ファイルシステム内の特別なファイルの内容を読み取ることで、カーネルの汚染状態を確認できます。/proc ファイルシステムは、プロセスに関する情報やその他のシステム情報を提供する仮想ファイルシステムです。
ターミナルが開いていない場合は、開きましょう。デスクトップの左側にある Xfce Terminal アイコンをクリックすることで、ターミナルを開くことができます。
次に、cat コマンドを使用して /proc/sys/kernel/tainted ファイルの内容を表示します。cat コマンドは、ファイルの内容を連結して表示するために使用されます。
以下のコマンドを入力し、Enter キーを押します。
cat /proc/sys/kernel/tainted
出力は単一の数字になります。
0
0の値は、カーネルが汚染されていないことを意味します。- ゼロ以外の値は、カーネルが汚染されていることを示します。特定の数字はビットマスクで、各ビットは汚染の異なる理由を表します。
たとえば、出力が 1 の場合、独自モジュールがロードされたことを示します。4 の場合、カーネル警告が発生した可能性があります。
私たちの LabEx 環境では、最初はカーネルが汚染されていないはずなので、0 が表示されるはずです。これは、クリーンなカーネル状態を示す良い兆候です。
汚染状態を理解することは、カーネルの問題をデバッグするため、または標準のカーネル設定で実行していることを確認するために重要です。
Continue をクリックして次のステップに進みましょう。
dmesg で汚染の詳細を確認する
前のステップでは、/proc/sys/kernel/tainted を使用してカーネルの汚染状態 (taint status) を確認しました。このファイルは、カーネルが汚染されているかどうかを示す数値コードを提供しますが、カーネルがなぜ汚染されているのかを教えてくれません。カーネルが汚染された理由を含む、カーネルメッセージに関する詳細情報を取得するには、dmesg コマンドを使用できます。
dmesg コマンドは、カーネルリングバッファを調べるために使用されます。このバッファには、デバイスドライバの情報、エラー、警告など、カーネルからのメッセージが格納されています。カーネルが汚染されると、通常、リングバッファにその理由を説明するメッセージが記録されます。
ターミナルが開いていない場合は、開きましょう。
次に、以下のコマンドを入力し、Enter キーを押します。
dmesg
このコマンドは、システム起動以来のすべてのカーネルメッセージを表示する、大量のテキストを出力する可能性があります。
汚染に関連する特定の情報を見つけるために、dmesg と grep コマンドを組み合わせることができます。grep は、テキストパターンを検索するための強力なツールです。「taint」という単語を含む行を検索します。
以下のコマンドを入力し、Enter キーを押します。
dmesg | grep taint
| 記号はパイプと呼ばれます。これは、左側のコマンド (dmesg) の出力を取得し、それを右側のコマンド (grep) の入力として送信します。したがって、このコマンドはまずすべてのカーネルメッセージを取得し、その後、「taint」という単語を含む行のみを表示するようにフィルタリングします。
カーネルが汚染されていない場合 (この環境では予想通り)、このコマンドは何も出力しないかもしれません。これは正常で、汚染イベントが記録されていないことを示しています。
もしカーネルが汚染されていた場合、次のような行が表示されます (正確なメッセージは汚染の理由によって異なります)。
[ ... ] kernel: Linux version ... (tainted: G)
[ ... ] kernel: Disabling lock debugging due to kernel taint
(tainted: G) の部分は、カーネルが汚染されていることを示し、文字 G は具体的には独自モジュールがロードされたことを意味します。他の文字は異なる汚染理由を示します (例えば、P は独自モジュール、F は強制的なモジュールロード、R は制限付きライセンスモジュールなど)。
dmesg | grep taint を使用することは、/proc/sys/kernel/tainted がゼロ以外の値を示した場合に、カーネルの問題を診断する上で重要なステップです。
Continue をクリックして次に進みましょう。
cat /proc/kallsyms でカーネルシンボルを調査する
このステップでは、/proc ファイルシステム内のもう 1 つの重要なファイル /proc/kallsyms を探索します。このファイルには、明示的に static とマークされていないすべてのカーネルシンボル (関数と変数) のアドレスと名前が含まれています。これは、カーネルのデバッグやカーネルの内部動作を理解するための重要なツールです。
/proc/kallsyms ファイルには、各カーネルシンボルのメモリアドレス、タイプ、名前がリストされています。各行の形式は通常次の通りです。
<address> <type> <symbol_name>
<address>: シンボルが配置されているメモリアドレス。<type>: シンボルのタイプを示す 1 文字 (例えば、tまたはTはテキスト/コード、dまたはDはデータ、bまたはBは BSS、rまたはRは読み取り専用データ、wまたはWは弱いシンボル、Uは未定義のシンボル)。小文字はローカルシンボルを示し、大文字はグローバルシンボルを示します。<symbol_name>: カーネル関数または変数の名前。
ターミナルが開いていない場合は、開きましょう。
次に、cat コマンドを使用して /proc/kallsyms の内容を表示しましょう。このファイルは非常に大きいので、出力が素早くスクロールすることに注意してください。
以下のコマンドを入力し、Enter キーを押します。
cat /proc/kallsyms
各行がカーネルシンボルを表す長いリストが表示されます。
...
ffffffff... T sys_read
ffffffff... T sys_write
ffffffff... D jiffies
...
この出力をより管理しやすくし、特定のシンボルを見つけるために、再び grep を使用できます。たとえば、プロセスを管理するためのカーネルのコア関数である「schedule」に関連するシンボルを検索してみましょう。
以下のコマンドを入力し、Enter キーを押します。
cat /proc/kallsyms | grep schedule
これにより、出力がフィルタリングされ、「schedule」という単語を含む行のみが表示されます。
ffffffff... T schedule
ffffffff... T schedule_timeout
ffffffff... T schedule_hrtimeout_range
...
このフィルタリングされた出力は読みやすく、興味のある特定のカーネル関数または変数のアドレスとタイプを見つけることができます。
/proc/kallsyms を探索することで、カーネルの構造と利用可能な関数について貴重な洞察を得ることができます。これは、カーネル開発や高度なデバッグを行う人にとって基本的なリソースです。
これで、/proc ファイルシステムと基本的な Linux コマンドを使用して、カーネルの汚染状態を確認し、カーネルシンボルを調べる方法を学びました。
Continue をクリックしてこの実験を完了しましょう。
まとめ
この実験では、Linux カーネルの汚染状態 (taint status) を確認する方法を学びました。まず、cat /proc/sys/kernel/tainted コマンドを使用して、カーネルが汚染されているかどうかを迅速に判断しました。ここで、値が 0 の場合はクリーンな状態を示し、ゼロ以外の値はカーネルが汚染されていることを意味し、具体的な数値は汚染の理由を表すビットマスクを示します。
次に、dmesg を使用してカーネルメッセージバッファを調べることで、汚染の詳細を確認しました。これにより、カーネルが汚染される原因となったイベントに関連する具体的なメッセージを見ることができ、数値コードだけでは得られない文脈情報を提供します。最後に、cat /proc/kallsyms を使用してカーネルシンボルを調べる方法を探索しました。これは、高度なデバッグやカーネルの内部状態を理解するのに役立ちますが、提供された内容ではこのステップの詳細は完全には記載されていません。
