情勢

この議論はLinuxオペレーティングシステムのカーネルに言及しており、このオペレーティングシステム用のカーネルモジュールとドライバーの開発者にとって興味深いものです。 他のすべての人にとって、これらのメモはほとんど関心がありません。

最も簡単なLinuxカーネルモジュールを作成した人は誰でも知っています。また、Linuxドライバーの作成技術に関する既存のすべての書籍に書かれています。 これは、Linuxカーネルドメインの最も複雑な概念の1つであり、カーネルシンボルのエクスポートです。 カーネル空間からの名前を別のモジュールでバインドできるようにするには、この名前について次の2つの条件を満たしている必要があります。 名前にはグローバルスコープが必要です（モジュール内では、そのような名前は静的と宣言しないでください）およびb）。 名前は明示的にエクスポートと宣言する必要があり、マクロパラメータEXPORT_SYMBOL（または結果的には同じではないEXPORT_SYMBOL_GPL）を使用して明示的に記述する必要があります。

カーネルで知られているすべての名前は/ proc / kallsyms疑似ファイルに動的に表示され、その数は膨大です：

$ uname -r 3.13.0-37-generic $ cat /proc/kallsyms | wc -l 108960 

カーネルによってエクスポートされる名前（モジュールのプログラムコードで使用するために提供される）の数は大幅に少なくなります。

 $ cat /lib/modules/`uname -r`/build/Module.symvers | wc -l 17533 

ご覧のとおり、カーネルには（カーネルのバージョンに応じて）数十万の名前が定義されています。 ただし、これらの名前のほんの一部（約10％）のみがエクスポートされていると宣言されており、カーネルモジュールコードで使用（バインド）できます。

カーネルAPI呼び出しは、名前の絶対位置で行われることを思い出してください。 カーネル（またはモジュール）によってエクスポートされた各名前にはアドレスが関連付けられており、この名前を使用してモジュールをロードするときにバインドするために使用されます。 これは、モジュールとカーネル間の相互作用の主なメカニズムです。 システムが実行されると、モジュールは動的にロードされ、カーネルコードの不可欠な部分になります。 これにより、Linuxのカーネルモジュールは特定のカーネル（通常はインストール場所）でのみコンパイルでき、そのようなバイナリモジュールを別のカーネルでロードしようとすると、オペレーティングシステムがクラッシュします。

この短いエクスカーションの結果として、Linuxカーネル開発者は、拡張機能（カーネルモジュール）の開発者向けに、非常に限られた（非常に不十分な文書化された）APIのセットを提供すると述べることができます。 しかし、この意見は、ドライバーの開発者自身の意見と一致しない場合があります。ドライバーの開発者は、カーネルのすべての武器を手にしたいと考えています。 そして、それを使用することはかなり可能です。これについては残りのテキストで説明します。

名前で住所を検索

/ proc / kallsyms内の（108960以降の）カーネル名のレコード行の構造を見てみましょう。

 $ sudo cat /proc/kallsyms | grep ' T ' | grep sys_close c1176ff0 T sys_close 

これは、システムコールハンドラ（POSIX）close（）のエクスポート名です。 （一部のLinuxディストリビューションでは、行のアドレスは、読み取りがルート特権で行われた場合にのみ入力されます。他のユーザーの場合は、アドレスフィールドにゼロ値が表示されます。）

モジュールのコードでsys_close（）関数呼び出しを使用することもできます。 ただし、sys_open（）を完全に対称的に呼び出してこれを行うことはできません。この名前はカーネルによってエクスポートされないためです。 そのようなモジュールを組み立てると、次のような警告が表示されます。

 $ make ... MODPOST 2 modules WARNING: "sys_open" [/home/olej/2011_WORK/LINUX-books/examples.DRAFT/sys_call_table/md_0o.ko] undefined! ... 

ただし、そのようなモジュールをロードしようとすると失敗します。

 $ sudo insmod md_0o.ko insmod: error inserting 'md_0o.ko': -1 Unknown symbol in module $ dmesg md_0o: Unknown symbol sys_open 

このようなモジュールは、カーネルの整合性ルールに矛盾するため、ロードできません：未解決の外部シンボルが含まれています-このシンボルは、バインディングのためにカーネルによってエクスポートされません（つまり、コンパイラの観点からの警告は、開発者の観点からは重大なエラーのように見えます）。

上記は、エクスポートされたカーネルシンボルのみがモジュールのコードで使用できることを意味しますか？ いいえ、これは、名前による（名前の絶対アドレスによる）推奨バインディング方法が、エクスポートされた名前にのみ適用されることを意味します。 エクスポートは、カーネルの整合性を確保するための別の追加の制御ラインを提供します-最小限の不正確さは、オペレーティングシステムの完全なクラッシュにつながります。

すべてのカーネルシンボルは/ proc / kallsyms疑似ファイルに表示されるため、モジュールコードはそれらをそこから取得できます。 さらに、これは、カーネルAPIにすべての名前をローカライズするメソッドがあり、これらのメソッドを同じ目的でコードで使用できることを意味します。 中間ソリューションのパスを省略して、2つのオプション、2つのエクスポートされた呼び出し（カーネルの<linux / kallsyms.h>のすべての定義、またはlxr.free-electrons.com/source/include/linux/kallsyms.hを参照）のみを考慮します。

呼び出し：

 unsigned long kallsyms_lookup_name( const char *name ); 

ここでnameは探している名前で、その絶対アドレスが返されます。 このオプションの欠点は、カーネルバージョン2.6.32と2.6.35の間（または、おおよそ2010年の夏と2011年の春のパッケージ配布の間）のどこかに表示されることです。正確には、以前に存在しましたが、エクスポートされませんでした。 組み込みシステムおよび小規模システムの場合、これは重大な障害になる可能性があります。

より一般的な電話：

 int kallsyms_on_each_symbol( int (*fn)(void*, const char*, struct module*, unsigned long), void *data ); 

この課題はより複雑であり、ここで簡単な説明が必要です。 最初のパラメーター（fn）は、カーネルテーブル内のすべての文字に対して連続して（ループで）呼び出されるユーザー定義関数へのポインターを受け取り、2番目（データ）-各呼び出しに渡される任意のデータブロック（パラメーター）へのポインターこの関数fn（）の。

各名前に対して周期的に呼び出されるユーザー定義関数fnのプロトタイプ：

 int func( void *data, const char *symb, struct module *mod, unsigned long addr ); 

ここに：
data-上記で説明したように、呼び出しユニットに入力され、呼び出しからkallsyms_on_each_symbol（）関数（2番目の呼び出しパラメーター）に渡されるパラメーターブロック。ここでは、探しているキャラクターの名前を渡すのがよいでしょう。
symb-現在のfunc呼び出しで処理される、カーネル名テーブルの名前のシンボリックイメージ（文字列）。
mod-処理される文字が属するカーネルモジュール。
addr-カーネルのアドレス空間内のシンボルのアドレス（実際、これは私たちが探しているものです）。

ユーザー定義関数funcがゼロ以外の値を返す場合、カーネルテーブルの名前の列挙は現在のステップで中断され、続行できなくなります（効率上の理由から、必要な文字を既に処理している場合）。

kallsyms_on_each_symbol（）の呼び出しを使用するには、kallsyms_lookup_name（）と同じ意味の独自のラッパー関数を準備します。

 static void* find_sym( const char *sym ) { // find address kernel symbol sym static unsigned long faddr = 0; // static !!! // ----------- nested functions are a GCC extension --------- int symb_fn( void* data, const char* sym, struct module* mod, unsigned long addr ) { if( 0 == strcmp( (char*)data, sym ) ) { faddr = addr; return 1; } else return 0; }; // -------------------------------------------------------- kallsyms_on_each_symbol( symb_fn, (void*)sym ); return (void*)faddr; } 

ここでは、symb_fn（）関数の組み込み定義を使用したトリックを使用しました。これは、GCCコンパイラ拡張（C言語標準に関連）を使用して完全に正当ですが、カーネルモジュールのコンパイルにはGCCのみを使用します。 このコードは、グローバルな中間変数の宣言を避け、名前空間の詰まりを防ぎ、コードのローカライズに役立ちます。

使用例

Linuxオペレーティングシステムで最も神聖な場所の1つは、システムコールが行われるsys_call_tableセレクタテーブルです。それに応じてパラメータを準備し、1番目のパラメータでシステムコールの番号（セレクタ）を書き込むと、システムはコマンドを実行してカーネルに移動します：int 80h（in本質的には同じものです）。 システムコール番号（セレクター、第1パラメーター）は、カーネルシステムコール処理関数へのポインターのsys_call_table（配列）内のインデックスです。 たとえば、i386アーキテクチャの場合、すべてのシステムコールの数を確認できます。

 $ cat /usr/include/i386-linux-gnu/asm/unistd_32.h ... #define __NR_restart_syscall 0 #define __NR_exit 1 #define __NR_fork 2 #define __NR_read 3 #define __NR_write 4 #define __NR_open 5 #define __NR_close 6 #define __NR_waitpid 7 #define __NR_creat 8 ... 

以下は、標準ライブラリC libc.soによって実装された、ユーザーのアドレス空間で使用されるシステムコールのインデックス（番号）の表です。 このテーブルの正確な類似物は、カーネルのアドレス空間にあるカーネルヘッダーファイルにもあります。 また、システムコールインデックスの同様のテーブルは、Linuxでサポートされるすべてのアーキテクチャに存在します（異なるアーキテクチャのテーブルは、サイズ、構成、および同様のコールのインデックスの数値が異なります！）。

カーネルのバージョン2.6以降、カーネル開発チームが非常によく理解しているセキュリティ上の考慮事項に基づいて、sys_call_tableシンボルはエクスポートから除外されています（セキュリティは、サードパーティのプログラマーから保護されたカーネル開発者の一部という意味でここで解釈されることになっていると推測できます）。 Linuxドライバーの作成に関するすべての書籍には、ドライバーコードでsys_call_tableを使用できないことが記載されています。 さて、そしてさらに議論の次の部分で、これはそうではないことを示します！

かなり長い間（2011年以降）、議論中の主題を扱って、この主題に関する多くの出版物を読みました。 sys_cal_table検索のために発明したのではない、恐ろしい単語ハッカーで自分自身を怖がらせるウイルスライターやその他のゴミ-カーネルメモリのセクションをスキャンすることで、カーネルが占有するバイナリメモリフラグメントのダンプを動的にデコードします（たとえば、sys_close（）位置はエクスポートされます）常に）。 これから示されるように、これはすべてはるかに簡単に行われます。 Linuxの復元力の唯一の秘密はそれではありません。 その汚いトリックはそこに何かを見つけることができませんが、アクセス権の規制は（ルートの権利なしで）この規制の外で厄介なことをすることを許しません...そして誰も汚いトリックにルートの権利を与えません。

ただし、エクスポートできないカーネル文字を解決するタスクに戻ります。 最初のオプション（mod_kct.cファイル）は、kallsyms_lookup_name（）の使用方法を示しています（簡単にするために、ヘッダーファイルのインクルードは表示されません。MODULE_ *（）などの必要なマクロは、アーカイブファイルにあります）。

 static int __init ksys_call_tbl_init( void ) { void** sct = (void**)kallsyms_lookup_name( "sys_call_table" ); printk( "+ sys_call_table address = %p\n", sct ); if( sct ) { int i; char table[ 120 ] = "sys_call_table : "; for( i = 0; i < 10; i++ ) sprintf( table + strlen( table ), "%p ", sct[ i ] ); printk( "+ %s ...\n", table ); } return -EPERM; } module_init( ksys_call_tbl_init ); 

ここでは、sys_call_tableテーブルのアドレスが取得され、そこに含まれる最初の10個のシステムコール（__NR_restart_syscall ... __NR_link）のハンドラーのアドレスが抽出されます。

 $ sudo insmod mod_kct.ko insmod: ERROR: could not insert module mod_kct.ko: Operation not permitted $ dmesg | tail -n 2 [39473.496040] + sys_call_table address = c1666140 [39473.496045] + sys_call_table : c1067840 c1059280 c1055eb0 c1179ee0 c1179f70 c1178cb0 c1176ff0 c1059570 c1178d10 c1188860 ... 

（エラー「操作は許可されていません」は混乱しないはずです-ゼロ以外のリターンコード-EPERMで示されるように、モジュールをロードするつもりはありませんでした。特権モード、スーパーバイザー、プロセッサ保護リングゼロでコードを実行するだけです）。

見つかったアドレスがsys_call_table配列の先頭にあることを確認します。

 $ sudo cat /proc/kallsyms | grep c1067840 c1067840 T sys_restart_syscall $ sudo cat /proc/kallsyms | grep c1059280 c1059280 T SyS_exit c1059280 T sys_exit $ sudo cat /proc/kallsyms | grep c1055eb0 c1055eb0 T sys_fork 

...など（前述のシステムコール番号の表と比較してください）。

次のオプションは理解が少し難しくなります。kallsyms_on_each_symbol（）関数を使用しますが、より汎用的です（mod_koes.cファイル）：

 static int __init ksys_call_tbl_init( void ) { void **sct = find_sym( "sys_call_table" ); // table sys_call_table address printk( "+ sys_call_table address = %p\n", sct ); if( sct != NULL ) { int i; char table[ 120 ] = "sys_call_table : "; for( i = 0; i < 10; i++ ) sprintf( table + strlen( table ), "%p ", sct[ i ] ); printk( "+ %s ...\n", table ); } return -EPERM; } module_init( ksys_call_tbl_init ); 

テキスト的には、前のものとほぼ完全に繰り返されます。find_sym（）関数は、上記で説明しましたが、すべての生産的な作業を行います。 実行の結果は常に同じです：

 $ sudo insmod mod_koes.ko insmod: ERROR: could not insert module mod_koes.ko: Operation not permitted $ dmesg | tail -n2 [42451.186648] + sys_call_table address = c1666140 [42451.186654] + sys_call_table : c1067840 c1059280 c1055eb0 c1179ee0 c1179f70 c1178cb0 c1176ff0 c1059570 c1178d10 c1188860 ... 

議論

懐疑論者は異議を唱えるかもしれない：「だから何？」 動的にロードされる実際のカーネルモジュールコードでカーネルAPIを使用するために必要かつ十分なメカニズムが示されているという事実。 示されている手法により、カーネルモジュールの作成者の機能の範囲が大幅に拡大されます。 これらは非常に膨大な見通しであるため、検討のためにこの議論の後続の部分が必要になります。

...しかし、ストーリーの完成がそれほど退屈ではないように、シンプルだが印象的なアプリケーションの1つを紹介します。カーネルモジュールコードからユーザーライブラリのシステムコールコード（一般的には任意）を実行します。

カーネルモジュールコードがシステムログ（printk（））に出力を提供し、端末（printf（））に出力できないと言われましたか？ これはそうではないことを示します...ここに、端末に出力するこのような単純なカーネルモジュールを示します。

 static asmlinkage long (*sys_write) ( unsigned int, const char __user *, size_t ); static int __init wr_init( void ) { char buf[ 80 ] = "Hello from kernel!\n"; int len = strlen( buf ), n; sys_write = find_sym( "sys_write" ); printk( "+ sys_write address = %p\n", sys_write ); printk( "+ [%d]: %s", len, buf ); if( sys_write != NULL ) { mm_segment_t fs = get_fs(); set_fs( get_ds() ); n = sys_write( 1, buf, len ); set_fs( fs ); printk( "+ printf() return : %d\n", n ); } return -EPERM; } module_init( wr_init ); 

そして、ここにその実行があります（緊急終了コードで起動する試み）：

 $ sudo insmod mod_wrc.ko Hello from kernel! insmod: ERROR: could not insert module mod_wrc.ko: Operation not permitted $ dmesg | tail -n3 [23942.974587] + sys_write address = c1179f70 [23942.974591] + [19]: Hello from kernel! [23942.974612] + printf() return : 19 

ここの最初の行は、write（）システムコールです。 当然、出力はユーザープロセスinsmodの制御端末に対して行われますが、ここで重要なことは、カーネルスペースコードからwrite（）システムコールを実行することです。 ここで、いくつかの詳細についてさらに説明が必要になる場合があります。

アドレス変数sys_writeを記述するための「トリッキーな」プロトタイプはどこで入手しましたか？ もちろん、カーネルのsys_write（）関数の元の定義から<linux / syscalls.h>ヘッダーファイルに、コードのコメント（アーカイブ全体のコード）に示されているように、恥知らずに書き留めました。

 /* <linux/syscalls.h> asmlinkage long sys_write( unsigned int fd, const char __user *buf, size_t count ); */ 

そして、これは、使用されているすべてのエクスポートされていないカーネル名に対応する唯一の方法です-対応するヘッダーファイルから関数を実装するプロトタイプを書き落とします。 プロトタイプの最小限の不一致は、オペレーティングシステムの即時クラッシュにつながります！

get_ds（）、get_fs（）、set_fs（）という形式のいくつかの同様の呼び出しはどういう意味ですか？ これは、カーネル内のデータセグメントの一時的な置換で構成される小さなトリックです。 実際、sys_write（）システムコールハンドラのプロトタイプには__user修飾子があり、これはポインタがユーザー空間のデータを指していることを示しています。 システムコールコードは、それが属するかどうか（アドレスの数値の範囲のみ）をチェックし、アドレスがカーネルスペースの領域を指す場合（この場合のように）、異常終了を引き起こします。 このトリックを使用して、アドレスがユーザーのスペースに属するものとして解釈される必要があることを制御コードに示します。 そのような場合、このトリックは、その意味を実際に考えずに、機械的に使用できます。

注釈

同様のコードを使用した実験、さらに詳しく説明するケース（さらに詳しくは後述します）では、問題が発生します。コードの小さなエラーでさえ、すぐにオペレーティングシステムを圧倒します。 さらに悪いことに、システムは不特定の不安定な状態でクラッシュし、再起動後もシステムが回復しない可能性があります（それほど高くない）。

同様のコードを使用した実験中、私は常に疑問を抱えていました。仮想マシンでテストしてテストすることは可能ですか？ これは、CR0などの隠しプロセッサハードウェアレジスタへの書き込みなど、非常にマシンに依存することを実行する必要があるという事実にもかかわらずです。

議論されたすべてのコードは、少なくとも2013年の状態から始まって、少なくとも比較的最新のバージョンのOracle VirtualBox環境の仮想マシンで適切に実行されると満足して述べることができます。

したがって、深刻なトラブルを回避するために、仮想マシンで最初にこのようなコードを使用することを強くお勧めします。
Oracle VirtualBoxの言及は、この状況が他の仮想マシンマネージャーに保存されないことを意味するものではありません。これらのマネージャーのコードをチェックしませんでした（VirtualBoxはQEMUから仮想化コードを取得するため、ほぼ確実にすべてがQEMU / KVMで安全になります）。

本文に記載されている実験用のファイル（コード）のアーカイブは、 ここまたはここで入手できます 。