ShlibVisibilityChecker
1.0.0
SHLIBVISHELCECKER ist ein kleines Tool, das interne Symbole lokalisiert, die unnötig aus gemeinsamen Bibliotheken exportiert werden. Solche Symbole sind unerwünscht, weil sie verursachen
--gc-sections ShlibvisibsibilityChecker vergleicht APIs, die in öffentlichen Kopfzeilen mit APIs erklärt wurden, die aus gemeinsamen Bibliotheken exportiert wurden, und warnt vor Diskrepanzen. In den meisten Fällen sind solche Symbole für interne Bibliothekssymbole, die versteckt werden sollten (in seltenen Fällen sind dies interne Symbole, die von anderen Bibliotheken oder ausführbaren Ausführungsfähigkeiten im selben Paket verwendet werden, und shlibvischeck-debian versucht, solche Fälle nicht zu melden).
Solche Diskrepanzen sollten dann durch Neukompilieren von Paket mit -fvisibility=hidden werden (hier finden Sie hier Einzelheiten). Eine typische Lösung für ein typisches Autoconf -Projekt finden Sie hier.
SHLIBVISHIBLEYCECKER ist nicht zu 100% präzise, sondern hilft sich bei der Suche nach Paketen, was am besten von Sichtbarkeitsanmerkungen profitieren kann (und um zu verstehen, wie schlimm die Situation mit Sichtbarkeit in moderner Distributionen ist).
Um ein Rohpaket zu überprüfen, dh ein paar Header und gemeinsame Libs, sammeln Sie Quellen- und Binärschnittstellen und vergleichen Sie sie:
$ 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'
Ein weiteres nützliches Szenario ist die Suche nach Symbolen, die aus den gemeinsam genutzten Bibliotheken von Debian Paket exportiert werden, aber nicht in seinen Headern erklärt werden. Das Hauptwerkzeug hierfür ist ein shlibvischeck-debian -Skript.
Um es auf ein Paket anzuwenden, laufen Sie aus
$ 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
So überspringen Sie autogenerierte Symbole wie _init oder _edata (verursacht durch LD -Linker -Skripte und LIBGCC -Startdateien) hinzufügen --permissive .
Sie können auch Sichtbarkeitsprobleme in willkürlichen Header und Bibliotheken überprüfen:
$ 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*
Voraussetzungen für Bauzeit sind python3 ( setuptools Modul), clang , llvm , libclang-dev , g++ und make . Laufzeitabhängigkeiten sind python3 ( python-magic Modul), pkg-config und aptitude . Um alles auf Ubuntu zu installieren, laufen Sie
$ sudo apt-get install python3 clang llvm libclang-dev g++ make pkg-config aptitude
$ sudo python3 -mensurepip
$ sudo pip3 install setuptools python-magic
(Sie können auch scripts/install-deps.sh verwenden).
Sie müssen auch den Zugriff auf Ubuntu -Source -Pakete ermöglichen
$ sudo sed -Ei 's/^# *deb-src /deb-src /' /etc/apt/sources.list
$ sudo apt-get update
Python und binäre Komponenten werden separat erstellt:
$ make clean all && make install
$ ./setup.py build && pip3 install .
Während der Analyse installiert shlibvischeck-debian neue Debian-Pakete, sodass es empfohlen wird, sie unter Chroot oder in VM auszuführen. Es gibt viele Anweisungen zum Einrichten von Chroot, z. B. diesen.
Eine Liste von Paketen für die Analyse kann aus der Debian -Bewertung erhalten werden:
$ curl https://popcon.debian.org/by_vote | awk '/^[0-9]+ +lib/{print $2}' > by_vote
$ shlibvischeck-debian $(head -500 by_vote | tr 'n' ' ')
Sobald Sie ein problematisches Paket gefunden haben, können Sie es beheben, indem Sie die Sichtbarkeit interner Symbole einschränken. Der beste Weg, um die Sichtbarkeit der Symbol in einem Paket zu kontrollieren, besteht darin
-fvisibility=hidden zu CFLAGS in Projektbuildscripts ( Makefile.in oder CMakeLists.txt ).__attribute__((visibility("default")))Siehe Fix in libcaca zum Beispiel.
Im Moment arbeitet Tool nur an Debian-basierten Systemen (z. B. Ubuntu). Dies sollte in Ordnung sein, da Buildscripts in allen Distributionen gleich sind, sodass die Erkennung von Problemen in Ubuntu auch allen anderen dienen würde.
Ein wichtiges Designproblem ist, dass das Tool Symbole nicht erkennen kann, die indirekt verwendet werden, dh nicht durch eine API, sondern durch dlsym oder eine explizite Prototypenerklärung außerhalb des Headers in der Quelldatei. Dies geschieht in Plugins oder eng miteinander verbundenen SHLibs innerhalb desselben Projekts. Solche Fälle sollten hoffentlich selten sein.
SHLIBVISHELCECKER ist ein heuristisches Tool, sodass nicht alle Pakete analysieren können. Die aktuelle Erfolgsquote liegt bei 60%. Hauptgründe für Fehler sind
libatasmart , schließt nicht stddef.h und tdb nicht ein, schließt nicht sys/types.h ein).lzma/container.h )dpkg/macros.h erforderlich LIBDPKG_VOLATILE_API )libverto-dev verwendet Glib-Header, erklärt dies jedoch nicht)Andere Probleme:
Das Tool fand eine große Anzahl von Paketen, bei denen die Sichtbarkeitsanmerkungen fehlten (in der Praxis hat jedes zweite Paket falsche Exporte). Hier sind einige, die ich zu beheben versuchte:
Weitere Perspektivpakete (von Debian Top-100): libpopt1, libgpg-eRror0, libxml2, libwrap0, libpcre3, libkeyutils1, libedit2, liblcms2-2.
