ShlibVisibilityChecker下載ShlibVisibilityChecker源代碼下載

ShlibVisibilityChecker

其他類別

1.0.0

下載

這是什麼？

ShlibvisibleChecker是一個小工具，可以找到內部符號，這些符號不必要地從共享庫中導出。這樣的符號是不可取的，因為它們會導致

啟動時間較慢（由於動態鏈接器的重新定位處理較慢，請參見Linux內核的現實世界示例）
性能放緩（由於間接函數調用，編譯器無法優化可導出功能，例如內聯函數，有效的--gc-sections閉合）
實施詳細信息的洩漏（如果某些客戶開始使用私人功能而不是常規API）
由於運行時符號衝突而引起的錯誤
- 由於符號與libasn1衝突而導致Apache崩潰
- 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'

另一個有用的方案是找到從Debian軟件包共享庫中導出的符號，但並未在其標題中聲明。主要工具是一個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 Linker腳本和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 ）。

您還需要通過

 $ 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' ' ')

如何修復包裹

一旦找到有問題的軟件包，就可以通過限制內部符號的可見性來修復它。控制包中符號可見性的最佳方法是

默認情況下，通過添加-fvisibility=hidden在project buildscript中的CFLAGS （ Makefile.in或CMakeLists.txt ）中隱藏所有符號
用__attribute__((visibility("default")))

例如，請參見Libcaca中的修復。

問題和局限性

目前，工具僅適用於基於Debian的系統（例如Ubuntu）。這應該很好，因為在所有發行版中構建訂閱都是相同的，因此在Ubuntu上檢測問題也將為其他所有人服務。

一個重要的設計問題是，該工具無法檢測到不是通過API而是通過dlsym或源文件中明確的外部原型聲明來檢測IE的符號。這發生在插件或同一項目中緊密相互連接的shlibs中。希望這種情況應該很少見。

ShlibvisibilityChecker是一種啟發式工具，因此無法分析所有軟件包。當前的成功率約為60％。錯誤的主要原因是

結構不佳的標題，即沒有#include所有依賴項的標題（例如， libatasmart未能包括stddef.h ，而tdb未能包括sys/types.h ）。
不應直接包含的內部標題（例如lzma/container.h ）
需要自定義宏定義的實驗標頭（未在pkgconfig中列出）（例如dpkg/macros.h需要LIBDPKG_VOLATILE_API ）
缺失依賴項（例如， libverto-dev使用glib標頭，但沒有聲明這一點）

其他問題：