ShlibVisibilityCheckerダウンロードShlibVisibilityCheckerソースコードのダウンロード

ShlibVisibilityChecker

その他のカテゴリー

1.0.0

ダウンロード

これは何ですか？

Shlibvisibilitycheckerは、共有ライブラリから不必要にエクスポートされる内部シンボルを見つける小さなツールです。そのようなシンボルは、それらが引き起こすため望ましくありません

スタートアップ時間の遅い（動的リンカーによる再配置処理が遅いため、Linuxカーネルの実際の例を参照）
パフォーマンスの減速（間接関数呼び出し、コンパイラがエクスポート可能な関数を最適化できないことにより、それらのインライン、効果的なターンオフ--gc-sections ）
実装の詳細のリーク（一部のクライアントが通常のAPIの代わりにプライベート機能を使用し始めた場合）
ランタイムシンボルの衝突によるバグ
- シンボルがlibasn1との衝突によるアパッチでのクラッシュ
- Flameeyesブログのより現実世界の例

shlibvisibilitycheckerは、共有ライブラリからエクスポートされたAPIに対して公開ヘッダーで宣言されたAPIを比較し、矛盾について警告します。ほとんどの場合、そのようなシンボルは非表示にする必要がある内部ライブラリシンボルです（まれに、これらは同じパッケージの他のライブラリまたは実行可能ファイルが使用する内部シンボルであり、 shlibvischeck-debianそのようなケースを報告しないように努力します）。

そのような矛盾は-fvisibility=hiddenを使用してパッケージを再コンパイルすることで修正する必要があります（詳細についてはこちらを参照）。典型的なAutoCONFプロジェクトの典型的な修正は、ここにあります。

shlibvisibilitycheckerは、100％正確であることを意図していませんが、視認性の注釈から最も利益を得る可能性のあるパッケージを見つけるのに支援を提供します（視界のある状況が最新のディストリビューションでどれほど悪いかを理解するため）。

使い方

生のパッケージを確認するには、つまり、多数のヘッダーと共有Libs、ソースインターフェイスとバイナリインターフェイスを収集して比較してください。

 $ bin/read_header_api --only-args /usr/include/xcb/* > api.txt
$ ./read_binary_api --permissive /usr/lib/x86_64-linux-gnu/libxcb*.so > abi.txt
$ vimdiff api.txt abi.txt  # Or `comm -13 api.txt abi.txt'

もう1つの有用なシナリオは、Debian Packageの共有ライブラリからエクスポートされるが、ヘッダーでは宣言されていないシンボルを見つけることです。これの主なツールはshlibvischeck-debianスクリプトです。

パッケージに適用するには、実行します

 $ shlibvischeck-debian libacl1
The following exported symbols in package 'libacl1' are private:
  __acl_extended_file
  __acl_from_xattr
  __acl_to_xattr
  __bss_start
  _edata
  _end
  _fini
  _init
  closed
  head
  high_water_alloc
  next_line
  num_dir_handles
  walk_tree

_initや_edata （LDリンカースクリプトとLIBGCCスタートアップファイルによって引き起こされる）のような自動生成シンボルをスキップするには--permissiveです。

また、ヘッダーとライブラリの任意のセットの可視性の問題を確認することもできます。

 $ shlibvischeck-common --permissive --cflags="-I/usr/include -I$AUDIT_INSTALL/include -I/usr/lib/llvm-5.0/lib/clang/5.0.0/include" $AUDIT_INSTALL/include/*.h $AUDIT_INSTALL/lib/*.so*

インストール方法

ビルドタイムの前提条件は、 python3 （ setuptoolsモジュール）、 clang 、 llvm 、 libclang-dev 、 g++およびmakeです。ランタイム依存関係は、 python3 （ python-magicモジュール）、 pkg-config 、およびaptitude 。 Ubuntuにすべてをインストールするには、実行します

 $ sudo apt-get install python3 clang llvm libclang-dev g++ make pkg-config aptitude
$ sudo python3 -mensurepip
$ sudo pip3 install setuptools python-magic

（スクリプトscripts/install-deps.shを使用することもできます）。

また、ubuntuソースパッケージにアクセスできるようにする必要があります

 $ sudo sed -Ei 's/^# *deb-src /deb-src /' /etc/apt/sources.list
$ sudo apt-get update

Pythonおよびバイナリコンポーネントは別々に構築されています。

 $ make clean all && make install
$ ./setup.py build && pip3 install .

分析中、 shlibvischeck-debian新しいDebianパッケージをインストールするため、ChrootまたはVMで実行することをお勧めします。 chrootをセットアップすることについては、これをセットアップすることには多くの指示があります。

パッケージを見つける場所

分析用のパッケージのリストは、Debian評価から取得できます。

 $ curl https://popcon.debian.org/by_vote | awk '/^[0-9]+ +lib/{print $2}' > by_vote
$ shlibvischeck-debian $(head -500 by_vote | tr 'n' ' ')

パッケージの修正方法

問題のあるパッケージを見つけたら、内部シンボルの可視性を制限することで修正できます。パッケージのシンボルの可視性を制御する最良の方法は、

プロジェクトBuildScripts（ Makefile.inまたはCMakeLists.txt ）に-fvisibility=hidden CFLAGSに隠されていることを追加して、デフォルトですべてのシンボルを非表示にします
__attribute__((visibility("default")))で公開されている関数に明示的に注釈

たとえば、Libcacaの修正を参照してください。

問題と制限

現時点では、ツールはDebianベースのシステム（Ubuntuなど）でのみ機能します。 BuildScriptsはすべてのディストリビューションで同じであるため、これは問題ありません。これは、Ubuntuの問題を検出することで他のすべての人にも役立つでしょう。

重要な設計上の問題は、ツールがAPIではなくdlsymまたはSource Fileの明示的な外れのプロトタイプ宣言を介して使用されるシンボルを検出できないことです。これは、同じプロジェクト内でプラグインまたは密接に相互接続されたSHLIBで発生します。そのような場合、うまくいけばまれであるべきです。

shlibvisibilitycheckerはヒューリスティックツールであるため、すべてのパッケージを分析できません。現在の成功率は約60％です。エラーの主な理由です

ひどく構造化されたヘッダー、つまり、すべての依存関係を#includeしないもの（ libatasmart stddef.hを含めることができず、 tdb sys/types.hを含めることができません）。
直接#includedではない内部ヘッダー（例： lzma/container.h ）
カスタムマクロ定義を必要とする実験ヘッダー（pkgconfigにリストされていません）（例： dpkg/macros.hにはLIBDPKG_VOLATILE_APIが必要です）
依存関係が欠落している（例： libverto-devグリブヘッダーを使用しますが、これを宣言しません）

その他の問題：