-ホンジュラスに迷惑をかけている...
                                                                                     -心配？ そして、あなたは彼を傷つけません。

ディスカッションの前の部分（ 1st 、 2ndおよび3rd ）で、sys_call_tableの内容を変更する機能を使用して、Linuxシステムコールの動作を変更する方法を検討しました。 次に、ソフトウェアプロジェクトの目的で新しいシステムコールを動的に追加できるかどうか（およびその方法）の方向で実験を続けます。



「なぜ？」という質問には焦点を当てません。プログラミングでは、最後に尋ねるのは「なぜ？」です。「どうやって？」と尋ねる必要があります。 しかし、それでも、私たちは議論の終わりに向かって、これにすぐに戻ります。

どのように見えますか？

システムコールを置き換える前述の例との一般的な類似性を考えると、このタスクはすべての類似点とともに、いくつかの悪化する特徴を持っています。

• 元のsys_call_tableシステムコールテーブルのサイズは、カーネルのバージョンごとにゆっくりですが単調に増加しており、特定のプロセッサプラットフォームに大きく依存しています。
• このテーブルのディメンションを定義する定数（カーネルでは__NR_syscall_max、または一部の新しいバージョンでは__NR_syscallsとして知られています）は、コンパイル期間のプリプロセッサ定数（マクロ）によって宣言され、実行時には不明です（少なくとも、私には不明です）。
• テーブルの最後に独自のエントリポイントを追加しようとすると、テーブルに割り当てられた領域を超える重大なリスクがあります-これは実行できません！

sys_call_tableテーブルのサイズは非常に大きく、バージョンからカーネルバージョン（バージョン3.13）に変更されます。これは非常に大まかな見積もりです。

$ cat /proc/kallsyms | grep ' sys_' | grep T | wc -l 357
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

議論のこの部分のカーネルバージョンは、常に言及する必要があります：前のバージョンのヘッダーファイルで定義されたものは、次のバージョンとは異なる方法で完全に異なる場所（ファイル）で決定されるか、まったく定義されないことさえあります。 これはカーネルコードの一般的な方法です。 しかし、それでもすべての基本原則と依存関係はバージョンごとに変更されていません。



システムコールのテーブルは密ではなく 、十分にスパースではなく 、未使用の位置があるため（上​​記の制限された状況を緩和します（古いシステムコールから残っており、現在サポートされていません））。 そのような位置はすべて 1つのアドレスで満たされます-未実現呼び出しsys_ni_syscall（）のハンドラーの関数へのポインター：

 $ cat /proc/kallsyms | grep sys_ni_syscall c045b9a8 T sys_ni_syscall
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、sys_ni_syscall（）システムコール自体は次のように定義されます：

 asmlinkage long sys_ni_syscall( void ) { return -ENOSYS; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、sys_call_tableテーブルの未使用の位置に新しいシステムコールハンドラを追加できます。 これらの位置には古く未使用の呼び出しはありませんが、呼び出しは行われ、その唯一のアクションはエラーコードを返すことです。 さらに、カーネル開発者にはこれらの位置を再利用する権利がありません。さもないと、完全に廃止されたアプリケーションが、疑いなく新しい置換呼び出しを引き起こす可能性があります。



静的に、ソースコード内のテキストで、sys_call_tableテーブルの構造を詳細に調べることができます（選択したプラットフォームとバージョン用）。 このような研究では、ソースコード自体は開発者によって提示されたのでほとんど役に立ちませんが、幸いなことに、今日ここで、ここ（ここでバージョンを比較できるように）LXR（Linux Kernel Cross Reference）プロジェクトを使用してカーネルコードを視覚化する多くのリソースがあります必要な識別子を簡単に見つけることができます）。 たとえば、（ファイル<arch / x86 / kernel / syscall_table_32.S>）sys_ni_syscallへのリンクを含むx86アーキテクチャ3.0.26カーネルのsys_call_tableの位置のみを表示します（ただし、カーネル3.2以降では、このファイルはコードツリーからも消えます...テーブルは同じままで、外観は変わりません）：

 ENTRY(sys_call_table) .long sys_restart_syscall /* 0 - old "setup()" system call, used for restarting */ .long sys_exit ... .long sys_ni_syscall /* old break syscall holder */ //17 .long sys_ni_syscall /* old stty syscall holder */ //31 .long sys_ni_syscall /* old gtty syscall holder */ //32 .long sys_ni_syscall /* 35 - old ftime syscall holder */ //35 .long sys_ni_syscall /* old prof syscall holder */ //44 .long sys_ni_syscall /* old lock syscall holder */ //53 .long sys_ni_syscall /* old mpx syscall holder */ //56 .long sys_ni_syscall /* old ulimit syscall holder */ //58 .long sys_ni_syscall /* old profil syscall holder */ //98 .long sys_ni_syscall /* old "idle" system call */ //112 .long sys_ni_syscall /* old "create_module" */ //127 .long sys_ni_syscall /* 130: old "get_kernel_syms" */ //130 .long sys_ni_syscall /* reserved for afs_syscall */ //137 .long sys_ni_syscall /* Old sys_query_module */ //167 .long sys_ni_syscall /* reserved for streams1 */ //188 .long sys_ni_syscall /* reserved for streams2 */ //189 .long sys_ni_syscall /* reserved for TUX */ //222 .long sys_ni_syscall //223 .long sys_ni_syscall //251 .long sys_ni_syscall /* sys_vserver */ //273 .long sys_ni_syscall /* 285 */ /* available */ //285 ... .long sys_setns // 346
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リストには未使用の位置（テーブルの先頭と末尾を除く）のみが表示され、ソースコードからコメントが残され、システムコールの位置番号を含む最後のコメントが追加されました。



このバージョンのカーネルでは、テーブルには347個のシステムコール位置があり、そのうち21個は関係していません。 可変カーネルコードに依存しない、ダイナミクスの未使用位置の分析は、検討中の最初のカーネルモジュールに当てられます。

 static void **taddr, //  sys_call_table *niaddr; //  sys_ni_syscall() static int nsys = 0; //      #define SYS_NR_MAX 450 // SYS_NR_MAX -  ,   sys_call_table static int sys_length( void* data, const char* sym, struct module* mod, unsigned long addr ) { int i; if( ( strstr( sym, "sys_" ) != sym ) || ( 0 == strcmp( "sys_call_table", sym ) ) ) return 0; for( i = 0; i < SYS_NR_MAX; i++ ) { if( taddr[ i ] == (void*)addr ) { //  sys_*  sys_call_table if( i > nsys ) nsys = i; break; } } return 0; } static void put_entries( void ) { int i, ni = 0; char buf[ 200 ] = ""; for( i = 0; i <= nsys; i++ ) if( taddr[ i ] == niaddr ) { ni++; sprintf( buf + strlen( buf ), "%03d, ", i ); } LOG( "found %d unused entries: %s\n", ni, buf ); } static int __init init_driver( void ) { if( NULL == ( taddr = (void**)kallsyms_lookup_name( "sys_call_table" ) ) ) { ERR( "sys_call_table not found!\n" ); return -EFAULT; } LOG( "sys_call_table address = %p\n", taddr ); if( NULL == ( niaddr = (void*)kallsyms_lookup_name( "sys_ni_syscall" ) ) ) { ERR( "sys_ni_syscall found!\n" ); return -EFAULT; } LOG( "sys_ni_syscall address = %p\n", niaddr ); kallsyms_on_each_symbol( sys_length, NULL ); LOG( "sys_call_table length = %d\n", nsys + 1 ); put_entries(); return -EPERM; } module_init( init_driver );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前と同様に、オプションの詳細（マクロLOG（）など）は表示されず、すべて完全な添付ファイルに含まれています。

簡単に実行できます（これも正しい）-sys_call_tableの長さを調べるには、sys_ *マスクを使用してカーネル文字の数をカウントし、1（sys_call_table文字自体）を減算します。 しかし、冗長な方法を取ります。

• sys_ *マスクの次の文字はループ内にあります。
• その位置は sys_call_tableで検索されます（これは、これがシステムコールであるという追加の再保険です）。
• この位置が前の文字で以前に見つかった位置よりも大きい場合、 最後の呼び出しの現在の番号（現在のサイズsys_call_table）と見なされます。

この冗長な（まったく必要ではない）スキームにより、アーキテクチャとLinuxカーネルのバージョンのシステムコールテーブルの正確なサイズを同時に明確にすることができます。

 $ uname -p i686 $ uname -r 3.13.0-37-generic $ sudo insmod nsys.ko insmod: ERROR: could not insert module nsys.ko: Operation not permitted $ dmesg | tail -n 4 [10751.601851] ! sys_call_table address = c1666140 [10751.602194] ! sys_ni_syscall address = c1075930 [10751.659769] ! sys_call_table length = 351 [10751.659779] ! found 27 unused entries: 017, 031, 032, 035, 044, 053, 056, 058, 098, 112, 127, 130, 137, 167, 169, 188, 189, 222, 223, 251, 273, 274, 275, 276, 285, 294, 317,
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このバージョンでは351個のシステムコールのうち、27個は使用されません（テーブルサイズのほぼ10％）。 このリストの安定性は非常に高いです（意識的に、コード分析にはバージョン3.0.26が選択され、ダイナミクスでの実行には互いに4年以上離れているバージョン2.6.32および3.13が選択されています）。



注：脇に注意をそらすことなく、同様の方法でモジュールを記述することに合格していることに注意してください。 まったくダウンロードすることを意図していない、b）。 この点に関して、意図的にゼロ以外の完了コードを返しますc）。 したがって、アンロード機能（__exit）はまったくありません-これはユーザーアプリケーション（メイン（）ポイントから開始）と直接同等ですが、最大特権でスーパーバイザーモードでのみ実行されます。 しかし、これはすでに別の会話の主題です...

新しいシステムコールの実装

これで、定式化されたタスクの実装に戻る準備ができました。新しいシステムコールを追加します。 当然、この呼び出しを使用したテストユーザースペースアプリケーションも必要です。 新しい呼び出しの番号は、モジュールとプログラム（マクロLOG（）、ERR（）、およびそこに記載されている他の小さなもの）の使用の一貫性のために、一般的なヘッダーファイル（syscall.h）で定義されています。

 //      #define __NR_own 223 //    ,     nsys.ko //   3.31     27 : // 017, 031, 032, 035, 044, 053, 056, 058, 098, 112, // 127, 130, 137, 167, 169, 188, 189, 222, 223, 251, // 273, 274, 275, 276, 285, 294, 317,
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいシステムコールを行うユーザーアプリケーションから始める方が簡単かつ明確です。 ここではすべてがシンプルです。簡単にすることはできません。

 static void do_own_call( char *str ) { int n = syscall( __NR_own, str, strlen( str ) ); if( n == 0 ) LOG( "syscall return %d\n", n ); else { ERR( "syscall error %d : %s\n", n, strerror( -n ) ); exit( n ); } } int main( int argc, char *argv[] ) { if( 1 == argc ) do_own_call( "DEFAULT STRING" ); else while( --argc > 0 ) do_own_call( argv[ argc ] ); return EXIT_SUCCESS; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プログラムは、1つまたは一連の（コマンドラインで複数のパラメーターを指定する場合）システムコールを作成し、文字パラメーターを呼び出しに渡すことができます（sys_writeなどの方法と同様）。 そして、すでにモジュールコードで、この行がカーネルスペースにどのようにコピーされているかを確認できます。 ただし、ここでの主な関心事はリターンコードです。システムコールの成功または失敗です。



そして、カーネルからのそのような呼び出しを「ピックアップ」するモジュールは次のとおりです。

 asmlinkage long (*old_sys_addr) ( void ); //     : asmlinkage long new_sys_call ( const char __user *buf, size_t count ) { static char buf_msg[ 80 ]; int res = copy_from_user( buf_msg, (void*)buf, count ); buf_msg[ count ] = '\0'; LOG( "accepted %d bytes: %s\n", count, buf_msg ); return res; }; static void **taddr; //   sys_call_table static int __init new_sys_init( void ) { void *waddr; if( NULL == ( taddr = (void**)kallsyms_lookup_name( "sys_call_table" ) ) ) { ERR( "sys_call_table not found!\n" ); return -EFAULT; } old_sys_addr = (void*)taddr[ __NR_own ]; if( ( waddr = (void*)kallsyms_lookup_name( "sys_ni_syscall" ) ) != NULL ) LOG( "sys_ni_syscall address = %p\n", waddr ); else { ERR( "sys_ni_syscall not found!\n" ); return -EFAULT; } if( old_sys_addr != waddr ) { ERR( "not free slot!\n" ); return -EINVAL; } LOG( "old sys_call_table[%d] = %p\n", __NR_own, taddr[ __NR_own ] ); rw_enable(); taddr[ __NR_own ] = new_sys_call; rw_disable(); LOG( "new sys_call_table[%d] = %p\n", __NR_own, taddr[ __NR_own ] ); return 0; } static void __exit new_sys_exit( void ) { rw_enable(); taddr[ __NR_own ] = old_sys_addr; rw_disable(); LOG( "restore sys_call_table[%d] = %p\n", __NR_own, taddr[ __NR_own ] ); return; } module_init( new_sys_init ); module_exit( new_sys_exit );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

sys_call_tableテーブルの指定された（__NR_own）位置のアドレスと、未使用のsys_ni_syscallシステムコールのアドレスとの対応を確認する二重再保険もあります。



そして今、私たちが得たものを評価します：

 $ ./syscall syscall error -1 : Operation not permitted $ echo $? 255 $ sudo insmod adds.ko $ lsmod | head -n3 Module Size Used by adds 12622 0 pci_stub 12550 1 $ dmesg | tail -n3 [15000.600618] ! sys_ni_syscall address = c1075930 [15000.600622] ! old sys_call_table[223] = c1075930 [15000.600623] ! new sys_call_table[223] = f87d9000 $ ./syscall new string for call syscall return 0 syscall return 0 syscall return 0 syscall return 0 $ dmesg | tail -n4 [15070.680753] ! accepted 4 bytes: call [15070.680799] ! accepted 3 bytes: for [15070.680804] ! accepted 6 bytes: string [15070.680807] ! accepted 3 bytes: new $ ./syscall 'new string for call' syscall return 0 $ dmesg | tail -n1 [15167.526452] ! accepted 19 bytes: new string for call $ sudo rmmod adds $ dmesg | tail -n1 [15199.917817] ! restore sys_call_table[223] = c1075930 $ ./syscall syscall error -1 : Operation not permitted
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モジュールがアンロードされると、カーネルはプログラムに必要なシステムコールの実行をサポートできなくなります！

議論

実際、ここで議論することは何もありません-すべてが例によって透過的に示されています。 しかし、最初は、これがまったく適用されない理由について考えを述べることを約束しました（しかし、プログラミングの質問はなぜですか？ 示されているトリックは、（双方向）アプリケーションがカーネルと対話するための別の方法を提供します。 はい、もちろん/ dev、/ proc、または/ sysを使用して同じことを行うこともできますが、これらの各メソッドはシステムコールよりも重いため、多数の中間カーネルメカニズムが必要になります。



同様のメカニズムを使用できるのはいつですか？ たとえば、予期されるイベントが発生するまで、システムコールで別のアプリケーションスレッドがブロックされた場合の、カーネル内の一部のイベントに関するアプリケーションの非同期通知の場合。 このようなイベントは、たとえば、デバッグされた新しいデバイスからのハードウェア割り込み（IRQ）である可能性があります（ある程度高速ではありません）。 このアプローチでは、デバイスでのI / O操作は、inb（）、outb（）...、またはioperm（）およびiopl（）グループの操作を使用してユーザー空間から実装できます。 これらすべてにより、ユーザーのスペースを超えることなく、特権カーネルモードに関連するリスクや困難を伴わずに、作業を調査し、デバイスを使用して交換コードを最も詳細に記述できます。 そして、状況に応じて自由に：このテスト済みドライバーのコードをモジュールの形で機械的に書き換えたり、ユーザー空間にそのまま残したりできます。



注：この方法でしか解決できないデバイスの低速に関する上記の発言は、心臓に近づきすぎないようにしてください。 実際、Linuxカーネル内の高速デバイスは割り込みでは動作せず、循環ポーリングを使用します。 たとえば、ハードウェアレベルでのネットワークスタックのすべてのネットワークインターフェイスのように、Linuxネットワークサブシステムを知っている人なら誰でも私が意味することを理解できます。



私は、プロプライエタリなハードウェアの開発者や、他の人と同じように自然界に存在する権利を持つプロジェクトについて話しているのではありません。 彼らの作品では、同様の手法がアプリケーションの基礎を見つけることができます。



繰り返しますが、以前と同様に、コードアーカイブはここまたはここで取得できます ...

エピローグ

これはLinuxシステムコールのそのような異常な（下品な？）処理に関する短いサイクルの最後の部分なので、言われたことの全体的な結果の順序で一言で言いたいと思います。



カーネルモジュールまたはカーネルへのパッチの作成を開始すると、最初は硬直感を感じます。これは、文書化が不十分なカーネルAPIが提供する機能によってのみ制限されるか、「Linuxドライバーの作成」などの古くからの書籍で説明されています。 しかし、このシリーズで説明されているものと同様の実験、および他の多くの同様の実験は、カーネルモジュールですべての （例外なし！）ユーザー空間の可能性（新しいプロセスとスレッドの開始、UNIXシグナルの送信など）にアクセスできることを示唆しています。 さらに、特権（スーパーバイザー、リング0）プロセッサ保護モード（特権コマンド、内部プロセッサレジスタ、割り込み応答）に関連付けられたユーザー空間の達成不可能な機能。



これを示してください-これは、この一連の記事の主な目標であり、プライベートタスクの置換またはシステムコールの追加だけではありません。 カーネルモードでのプログラミングは、ここであなたが神のようであり、ここですべてを実行できるような自由感を作成する必要があります。 しかし、これには適切な程度の責任も必要です...