test

リンカーとライブラリ

実行時リンカーの監査インタフェース

「rtld-監査」インタフェースを使用すると、プロセスがそれ自身に関する実行時リンク情報にアクセスできます。 「共有オブジェクトのプロファイリング」では、このメカニズムの使用例として、共有オブジェクトの実行時プロファイルを示します。

「rtld-監査」インタフェースは、1 つまたは複数の監査インタフェースルーチンを提供する監査ライブラリとして実装されます。このライブラリがプロセスの一部として読み込まれている場合は、プロセス実行の各段階で、実行時リンカーによって監査ルーチンが呼び出されます。監査ライブラリはこれらのインタフェースを使って、次の情報にアクセスできます。

これらの機能のいくつかは、特殊な共有オブジェクトを事前に読み込むことによって実現できます。しかし、事前に読み込まれたオブジェクトは、プロセスのオブジェクトと同じ名前空間内に存在します。このため、通常、事前に読み込まれた共有オブジェクトの実装は制限されるか、複雑になります。「rtld-監査」インタフェースは、ユーザーに対して、監査ライブラリを実行するための固有の名前空間を提供します。この名前空間により、監査ライブラリがプロセス内で発生する通常の結合を妨害することはなくなります。

名前空間の確立

実行時リンカーは、動的実行可能なプログラムをその依存関係と結合すると、「リンクマップ」のリンクリストを生成して、プロセスを記述します。リンクマップ構造は、プロセス内の各オブジェクトを記述します。リンクマップ構造は、/usr/include/sys/link.h に定義されています。アプリケーションのオブジェクトを結合するために必要なシンボル検索メカニズムは、このリンクマップリストを検索します。このリンクマップリストは、プロセスシンボル解決用の「名前空間」を提供します。

実行時リンカーも、リンクマップによって記述されます。このリンクマップは、アプリケーションオブジェクトのリストとは異なるリストで管理されます。この結果、実行時リンカーが固有の名前空間内に常駐することになるため、アプリケーションが実行時リンカー内のサービスに結合されることはなくなります。アプリケーションは、フィルタ libc.so.1 または libdl.so.1 を介して、実行時リンカーの公開サービスを呼び出すことができるだけです。

「rtld-監査」インタフェースは、監査ライブラリが保持される各自のリンクマップリストを使用します。このため、監査ライブラリは、アプリケーションのシンボル結合要件から分離されます。アプリケーションリンクマップリストの検査は、dlmopen(3C) によって実行できます。dlmopen(3C) を RTLD_NOLOAD フラグとともに使用すると、監査ライブラリで、オブジェクトを読み込むことなくその存在を照会することができます。

アプリケーションと実行時リンカーのリンクマップリストを定義するために、2 つの識別子が /usr/include/link.h に定義されています。

#define LM_ID_BASE      0     /* application link-map list */
#define LM_ID_LDSO      1     /* runtime linker link-map list */

すべての「rtld-監査」サポートライブラリには、固有の新しいリンクマップ識別子が割り当てられています。

監査ライブラリの作成

監査ライブラリはほかの共有オブジェクトと同様に構築されます。ただし、プロセス内の監査ライブラリに固有の名前空間には、いくつかの注意が必要です。

監査ライブラリが printf(3C) を呼び出す場合、その監査ライブラリは、libc への依存関係を定義する必要があります。「共有オブジェクト出力ファイルの生成」を参照監査ライブラリには、固有の名前空間があるため、監査中のアプリケーションに存在する libc によってシンボル参照を満たすことはできません。監査ライブラリに libc への依存関係がある場合は、2 つのバージョンの libc.so.1 がプロセスに読み込まれます。1 つはアプリケーションのリンクマップリストの結合要件を満たし、もう 1 つは監査リンクマップリストの結合要件を満たします。

すべての依存関係が記録された状態で監査ライブラリが構築されるようにするには、リンカーの -z defs オプションを使用します。

システムインタフェースの中には、自らがプロセス内部の実装の唯一のインスタンスであると想定しているものがあります。このような実装の例として、シグナルおよび malloc(3C) があります。このようなインタフェースを使用すると、アプリケーションの動作が不正に変更されるおそれがあるため、監査ライブラリでは、このようなインタフェースの使用を避ける必要があります。

注 –

監査ライブラリは、mapmalloc(3MALLOC) を使用してメモリー割り当てを行うことができます。これは、アプリケーションによって通常使用される割り当てスキーマとこの割り当てが共存可能なためです。

監査インタフェースの呼び出し

「rtld-監査」インタフェースは、次のいずれかの方法によって有効になります。それぞれの方法は、監視対象のオブジェクトの範囲を意味します。

それぞれの呼び出し方法は、dlopen(3C) によって読み込まれる共有オブジェクトをコロンで区切ったリストを含む文字列で構成されています。各オブジェクトは、各自の監査リンクマップリストに読み込まれます。また、各オブジェクトは、dlsym(3C) によって、監査ルーチンがないか検索されます。検出された監査ルーチンは、アプリケーション実行中に各段階で呼び出されます。

「rtld-監査」インタフェースを使用すると、複数の監査ライブラリを指定することができます。この方法で使用される監査ライブラリは、通常実行時リンカーによって返される結合を変更することはできません。これらの結合を変更すると、後に続く監査ライブラリで予期しない結果が生じる場合があります。

安全なアプリケーションは、トラストディレクトリからだけ監査ライブラリを取得できます。デフォルトでは、32 ビットオブジェクトの実行時リンカーが認識できるトラストディレクトリは、/lib/secure と/usr/lib/secure だけです。64 ビットオブジェクトの場合、トラストディレクトリは /lib/secure/64 と /usr/lib/secure/64 です。

注 –

環境変数 LD_NOAUDIT をヌル以外の値に設定すると、実行時に監査を無効にすることができます。

ローカル監査の記録

ローカル監査要求は、オブジェクトがリンカーオプション -p または -P を使用して作成された場合に確立できます。たとえば、監査ライブラリ audit.so.1 を使用して libfoo.so.1 を監査するには、リンク編集時に -p オプションを使用して、この要求を記録します。


$ cc -G -o libfoo.so.1 -Wl,-paudit.so.1 -K pic foo.c
$ dump -Lv libfoo.so.1 | fgrep AUDIT
[3]    AUDIT      audit.so.1

実行時には、この監査識別子があることにより監査ライブラリが読み込まれます。次に、識別するオブジェクトに関する情報がその監査ライブラリに渡されます。

このメカニズムだけでは、識別するオブジェクトの検索などの情報は監査ライブラリが読み込まれる前に発生します。できるだけ多くの監査情報を提供するため、ローカル監査を要求するオブジェクトの存在は、そのオブジェクトのユーザーに広く知らされます。たとえば、libfoo.so.1 に依存するアプリケーションを作成すると、そのアプリケーションは、その依存関係の監査が必要であることを示すよう認識されます。


$ cc -o main main.c libfoo.so.1
$ dump -Lv main | fgrep AUDIT
[5]    DEPAUDIT   audit.so.1

このメカニズムで監査が有効になると、アプリケーションのすべての明示的な依存関係に関する情報が監査ライブラリに渡されます。この依存関係の監査は、リンカーの -P オプションを使用することにより、オブジェクトの作成時に直接記録することもできます。


$ cc -o main main.c -Wl,-Paudit.so.1
$ dump -Lv main | fgrep AUDIT
[5]    DEPAUDIT   audit.so.1

大域監査の記録

大域監査の要件は、環境変数 LD_AUDIT を設定することによって確立できます。たとえば、この環境変数を使えば、アプリケーション main とそのプロセスのすべての依存関係を、監査ライブラリ audit.so.1 を使って監査できます。


$ LD_AUDIT=audit.so.1 main

また、-z globalaudit オプションを指定することで、アプリケーション内のローカル監査を記録することによる大域監査を実現できます。たとえば、大域監査が有効になるようにアプリケーション main を構築するには、リンカーの -P オプションと -z globalaudit オプションを使用します。


$ cc -o main main.c -Wl,-Paudit.so.1 -z globalaudit
$ dump -Lv main | fgrep AUDIT
[5]    DEPAUDIT   audit.so.1
[26]   FLAGS_1    [ GLOBAL_AUDITING ]

監査がこれらのメカニズムのどちらで有効化された場合も、プロセスの「すべて」の動的オブジェクトに関する情報が監査ライブラリに渡されます。

監査インタフェースの関数

次の関数が「rtld-監査」インタフェースによって提供されています。これらの関数は使用順序に従って記載されています。

注 –

アーキテクチャーあるいはオブジェクトクラス固有のインタフェースの参照では、説明を簡潔にするため、省略して一般名を使用します。たとえば、la_symbind32() および la_symbind64() は la_symbind() で表します。

la_version()

この関数は、実行時リンカーと監査ライブラリの間に初期ハンドシェークを提供します。監査ライブラリが読み込まれるためには、このインタフェースが提供されている必要があります。

uint_t la_version(uint_t version);

実行時リンカーは、実行時リンカーがサポート可能な最上位バージョンの「rtld-監査」インタフェースによって、このインタフェースを呼び出します。監査ライブラリは、このバージョンが使用するのに十分かどうかを確認して、監査ライブラリが使用する予定のバージョンを返すことができます。このバージョンは、通常、/usr/include/link.h に定義されている LAV_CURRENT です。

監査ライブラリがゼロ、あるいは、実行時リンカーがサポートする「rtld-監査」インタフェースよりも大きなバージョンを返す場合、監査ライブラリは破棄されます。

la_activity()

この関数は、リンクマップアクティビティーが行われていることを監査プログラムに知らせます。

void la_activity(uintptr_t * cookie, uint_t flags);

cookie は、リンクマップの先頭のオブジェクトを指します。flags は、/usr/include/link.h に定義されているものと同じタイプのアクティビティーを指します。

  • LA_ACT_ADD – リンクマップリストにオブジェクトが追加される。

  • LA_ACT_DELETE – リンクマップリストからオブジェクトが削除される。

  • LA_ACT_CONSISTENT – オブジェクトのアクティビティーが完了した。

la_objsearch()

この関数は、オブジェクトの検索を実行することを監査プログラムに知らせます。

char * la_objsearch(const char * name, uintptr_t * cookie, uint_t flags);

name は、検索中のファイルあるいはパス名を指します。cookie は、検索を開始しているオブジェクトを指します。flags は、/usr/include/link.h に定義されている name の出所および作成を示します。

  • LA_SER_ORIG – 初期検索名。通常は、DT_NEEDED エントリとして記録されたファイル名、あるいは dlopen(3C) に与えられた引数を指します。

  • LA_SER_LIBPATH – パス名が LD_LIBRARY_PATH コンポーネントから作成されている。

  • LA_SER_RUNPATH – パス名が「実行パス」コンポーネントから作成されている。

  • LA_SER_DEFAULT – パス名がデフォルトの検索パスコンポーネントから作成されている。

  • LA_SER_CONFIG – パスコンポーネントの出所が構成ファイルである。crle(1) のマニュアルページを参照してください。

  • LA_SER_SECURE – パスコンポーネントがセキュリティー保護されたオブジェクトに固有である。

戻り値は、実行時リンカーが処理を継続する必要がある検索パス名を示します。値 0 は、このパスが無視されることを示しています。検索パスを監視する監査ライブラリは、name を返します。

la_objopen()

この関数は、新しいオブジェクトが実行時リンカーによって読み込まれると呼び出されます。

uint_t la_objopen(Link_map * lmp, Lmid_t lmid, uintptr_t * cookie);

lmp は、新しいオブジェクトを記述するリンクマップ構造を提供します。lmid は、オブジェクトが追加されているリンクマップリストを特定します。cookie は、識別子へのポインタを提供します。この識別子は、オブジェクト lmp に初期設定されます。この識別子は、監査ライブラリによって、オブジェクトをほかの「rtld-監査」インタフェースルーチンに対して特定するように変更できます。

la_objopen() 関数は、このオブジェクトで問題になるシンボル結合を示す値を返します。この結果の値は、/usr/include/link.h に定義された次の値のマスクです。

  • LA_FLG_BINDTO – このオブジェクトに対する監査シンボル結合。

  • LA_FLG_BINDFROM – このオブジェクトからの監査シンボル結合。

これらの値により、監査者は la_symbind() で監視するオブジェクトを選択できます。ゼロの戻り値は、結合情報がこのオブジェクトで問題にならないことを示します。

たとえば、監査者は、libfoo.so から libbar.so への結合を監視できます。libfoo.so() の la_objopen は、 LA_FLG_BINDFROM を返します。libbar.so の la_objopen() は、LA_FLG_BINDTO を返します。

監査者は、libfoo.so と libbar.so 間のすべての結合を監視できます。両方のオブジェクトの la_objopen() は、LA_FLG_BINDFROM と LA_FLG_BINDTO を返します。

監査者は、libbar.so へのすべての結合も監視できます。libbar.so() の la_objopen は、LA_FLG_BINDTO を返します。すべての la_objopen() 呼び出しは、LA_FLG_BINDFROM を返します。

la_objfilter()

この関数は、フィルタが新しい「フィルティー」を読み込むと呼び出されます。「フィルタとしての共有オブジェクト」を参照してください。

int la_objfilter(uintptr_t * fltrcook, const char * fltestr,
        uintptr_t * fltecook, uint_t flags);

fltrcook は、フィルタを特定します。fltestr は、フィルティー文字列を指します。fltecook は、フィルティーを特定します。 flags は、現在使用されていません。la_objfilter() は、フィルタとフィルティーの la_objopen() の後に呼び出されます。

戻り値 0 は、このフィルティーが無視されることを示しています。フィルタの使用を監視する監査ライブラリは、0 以外の値を返します。

la_preinit()

この関数は、すべてのオブジェクトがアプリケーションに読み込まれたあとで、アプリケーションへの制御の譲渡が発生する前に一度呼び出されます。

void la_preinit(uintptr_t * cookie);

cookie は、プロセスを開始したプライマリオブジェクト、通常は動的実行可能プログラムを表します。

la_symbind()

この関数は、la_objopen() によって結合通知のタグが付けられた 2 つのオブジェクト間で結合が発生すると呼び出されます。

uintptr_t la_symbind32(Elf32_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook, uint_t * flags);
 
uintptr_t la_symbind64(Elf64_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook, uint_t * flags,
        const char * sym_name);

sym は構築されたシンボル構造であり、 sym->st_value は結合されたシンボル定義のアドレスを示します。/usr/include/sys/elf.h を参照してください。la_symbind32() は、sym->st_name を調整して実際のシンボル名を指すようにしています。la_symbind64() は sym->st_name を結合オブジェクトの文字列テーブルのインデックスのままにしています。

ndx は、結合オブジェクト動的シンボルテーブル内のシンボルインデックスを示します。refcook は、このシンボルへの参照を行うオブジェクトを特定します。この識別子は、LA_FLG_BINDFROM() を返した la_objopen 関数に渡されたものと同じです。defcook は、このシンボルを定義するオブジェクトを特定します。この識別子は、LA_FLG_BINDTO を返した la_objopen() に渡されるものと同じです。

flags は、結合に関する情報を伝達できるデータ項目を指します。このデータ項目を使用すると、プロシージャーのリンクテーブルエントリの連続監査も変更できます。この値は、/usr/include/link.h に定義されたシンボル結合フラグのマスクです。

次のフラグが la_symbind() に提供される場合もあります。

  • LA_SYMB_DLSYM – dlsym(3C) を呼び出した結果、シンボル結合が発生した。

  • LA_SYMB_ALTVALUE (LAV_VERSION2) – la_symbind() への以前の呼び出しによって、シンボル値に対して代替値が返された。

la_pltenter() または la_pltexit() 関数が存在する場合、これらの関数は、プロシージャーリンクテーブルエントリの la_symbind() の後に呼び出されます。これらの関数は、シンボルが参照されるたびに呼び出されます。詳細は、「監査インタフェースの制限」を参照してください。

次のフラグは、デフォルトの動作を変更するために la_symbind() から提供されます。これらのフラグは、flags 引数が指す値とのビット単位の OR 演算として適用されます。

  • LA_SYMB_NOPLTENTER – このシンボルに対して la_pltenter() 関数は呼び出さない。

  • LA_SYMB_NOPLTEXIT – このシンボルに対して la_pltexit() 関数は呼び出さない。

戻り値は、この呼び出しに続いて制御を渡す必要があるアドレスを示します。シンボル結合を監視するだけの監査ライブラリは、sym->st_value の値を返すため、制御は結合シンボル定義に渡されます。監査ライブラリは、異なる値を返すことによって、シンボル結合を意図的にリダイレクトできます。

sym_name は、la_symbind64() のみに適用可能であり、処理されるシンボルの名前を含みます。この名前は、32 ビットインタフェースの sym->st_name フィールドから得られます。

la_pltenter()

これらの関数はシステムに固有です。これらの関数は、結合通知のタグが付いた 2 つのオブジェクト間でプロシージャーのリンクテーブルエントリが呼び出されるときに呼び出されます。

uintptr_t la_sparcv8_pltenter(Elf32_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook,
        La_sparcv8_regs * regs, uint_t * flags);
 
uintptr_t la_sparcv9_pltenter(Elf64_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook,
        La_sparcv9_regs * regs, uint_t * flags,
        const char * sym_name);
 
uintptr_t la_i86_pltenter(Elf32_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook,
        La_i86_regs * regs, uint_t * flags); 
uintptr_t la_amd64_pltenter(Elf64_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook,
        La_amd64_regs * regs, uint_t * flags, const char * sym_name);

sym、ndx、refcook、defcook、および sym_name は、la_symbind() に渡されたものと同じ情報を提供します。

la_sparcv8_pltenter() と la_sparcv9_pltenter() では、regs は out レジスタを指します。la_i86_pltenter() では、 regs は stack および frame レジスタを指します。la_amd64_pltenter() では、 regs は stack および frame レジスタ、および整数引数の受け渡しに使用されるレジスタを指します。regs は /usr/include/link.h に定義されています。

flags は、結合に関する情報を伝達できるデータ項目を指します。このデータ項目を使用すると、プロシージャーリンクテーブルのエントリの連続監査を変更できます。このデータ項目は、la_symbind() から flags によって指されるものと同じです。

次のフラグは、現在の監査動作を変更するために la_pltenter() から提供できます。これらのフラグは、flags 引数が指す値とのビット単位の OR 演算として適用されます。

  • LA_SYMB_NOPLTENTER – la_pltenter() は、このシンボルでは再び呼び出されることはない。

  • LA_SYMB_NOPLTEXIT – la_pltexit() は、このシンボルでは呼び出されない。

戻り値は、この呼び出しに続いて制御を渡す必要があるアドレスを示します。シンボル結合を監視するだけの監査ライブラリは、sym->st_value の値を返すため、制御は結合シンボル定義に渡されます。監査ライブラリは、異なる値を返すことによって、シンボル結合を意図的にリダイレクトできます。

la_pltexit()

この関数は、結合通知のタグが付いた 2 つのオブジェクト間でプロシージャーのリンクテーブルエントリが返されるときに呼び出されます。この関数は、制御が呼び出し側に到達する前に呼び出されます。

uintptr_t la_pltexit(Elf32_Sym * sym, uint_t ndx, uintptr_t * refcook,
        uintptr_t * defcook, uintptr_t retval);

uintptr_t la_pltexit64(Elf64_Sym * sym, uint_t ndx, uintptr_t * refcook,
        uintptr_t * defcook, uintptr_t retval, const char * sym_name);

sym、ndx、refcook、defcook、および sym_name は、la_symbind() に渡されたものと同じ情報を提供します。retval は結合関数からの戻りコードです。シンボル結合を監視する監査ライブラリは、retval を返します。監査ライブラリは、意図的に異なる値を返すことができます。

注 –

la_pltexit() は実験段階のインタフェースです。詳細は、「監査インタフェースの制限」を参照してください。

la_objclose()

この関数は、オブジェクトに対する終了コードが実行されてから、オブジェクトが読み込みを解除されるまでに呼び出されます。

uint_t la_objclose(uintptr_t * cookie);

cookie はオブジェクトを特定するもので、以前の la_objopen() から取得されています。戻り値は、ここではすべて無視されます。

監査インタフェースの例

次の単純な例では、動的実行可能プログラム date(1) によって読み込まれた各共有オブジェクトの依存関係の名前を出力する、監査ライブラリを作成しています。


$ cat audit.c
#include        <link.h>
#include        <stdio.h>
 
uint_t
la_version(uint_t version)
{
        return (LAV_CURRENT);
}
 
uint_t
la_objopen(Link_map * lmp, Lmid_t lmid, uintptr_t * cookie)
{
        if (lmid == LM_ID_BASE)
                (void) printf("file: %s loaded\n", lmp->l_name);
        return (0);
}
$ cc -o audit.so.1 -G -K pic -z defs audit.c -lmapmalloc -lc
$ LD_AUDIT=./audit.so.1 date
file: date loaded
file: /lib/libc.so.1 loaded
file: /lib/libm.so.2 loaded
file: /usr/lib/locale/en_US/en_US.so.2 loaded
Thur Aug  10 17:03:55 PST 2000

監査インタフェースのデモンストレーション

/usr/demo/link_audit の SUNWosdem パッケージには、「rtld-監査」インタフェースを使用する多数のデモアプリケーションが用意されています。

sotruss

このデモアプリケーションは、指定アプリケーションの動的オブジェクト間でのプロシージャー呼び出しを追跡します。

whocalls

このデモアプリケーションは、指定アプリケーションに呼び出されるたびに、指定関数のスタック追跡を行います。

perfcnt

このデモアプリケーションは、指定アプリケーションの各関数で費やされた時間を追跡します。

symbindrep

このデモアプリケーションは、指定アプリケーションを読み込むために実行されたすべてのシンボル結合を報告します。

sotruss(1) と whocalls(1) は、SUNWtoo パッケージに組み込まれています。perfcnt と symbindrep はサンプルプログラムです。これらのアプリケーションは、実際の環境での使用を目的としていません。

監査インタフェースの制限

「rtld-監査」 実装には制限があります。監査ライブラリを設計するときは、これらの制限をよく理解するようにしてください。

アプリケーションコードの実行

オブジェクトがプロセスに追加されると、監査ライブラリは情報を受け取ります。監査ライブラリがこのような情報を受け取るときに、監視するオブジェクトが実行できる状態でない場合があります。たとえば、監査プログラムは、読み込むオブジェクトのための la_objopen() 呼び出しを受け取ることができます。ただし、そのオブジェクト内のコードを実行するには、その前にオブジェクトの依存関係を読み込んで再配置する必要があります。監査ライブラリは、dlopen(3C) を使用してハンドルを取得して、読み込んだオブジェクトを検査しなければならない場合があります。このハンドルは、dlsym(3C) を使用してインタフェースを検索するために使用できます。ただし、この方法で取得したインタフェースは、そのオブジェクトの初期化が完了したことがわかるまで、呼び出さないようにしてください。

la_pltexit() の使用

la_pltexit() 系列の使用にはいくつかの制限があります。これらの制限は、呼び出し側と「呼び出し先」の間で余分なスタックフレームを挿入して、la_pltexit() 戻り値を提供するための必要から生じたものです。la_pltenter() ルーチンだけを呼び出す場合、この要件は問題になりません。この場合、目的の関数に制御を渡す前に、余分なスタックを整理できます。

これらの制限が原因で、la_pltexit() は、実験的インタフェースとみなされます。問題がある場合には、la_pltexit() ルーチンの使用は避けてください。

スタックを直接検査する関数

スタックを直接検査するか、またはその状態について仮定をたてる少数の関数があります。これらの関数の例としては、setjmp(3C) ファミリ、vfork(2)、および構造へのポインタではなく構造を返す関数があります。これらの関数は、la_pltexit() をサポートするために作成される余分なスタックによって調整されます。

実行時リンカーは、このタイプの関数を検出できないため、監査ライブラリの作成元が、このようなルーチンの la_pltexit() を無効にする必要があります。