Wie kann man dynamische Glibc-Symbole (z. B. open@glibc) zuverlässig Kernel-Systemaufrufen (z. B. openat) zuordnen? ⇐ Linux

[Anonymous]

Ich versuche, eine Zuordnung zwischen den dynamischen Symbolen in ELF-Dateien (von glibc) und den tatsächlichen Kernel-Systemaufrufen zu erstellen, die sie aufrufen.
Meine Umgebung ist x86_64 Ubuntu 22.04.
Was ich versucht habe

• Parsing man 2 Seiten: Meine Der erste Versuch bestand darin, den Text von man 2 zu analysieren. Dies war effektiv zum Extrahieren von Argumenttypen und -namen, konnte den Wrapper-Systemaufruf (z. B. open) jedoch aufgrund der Einschränkungen der Handbücher nicht zuverlässig dem tatsächlichen Kernel-Systemaufruf (z. B. openat) zuordnen.
• AI-Empfehlung (AST): Mir wurde von einer KI geraten, dass die Verwendung eines Abstract Syntax Tree (AST), zum Beispiel mit libclang, wäre ein praktikabler Ansatz. Ich bin ein Informatikstudent, aber meine Universität bietet keinen Compiler-Kurs an, daher fehlt mir ein tiefes Verständnis von ASTs und ich suche hier Expertenrat.

Mein Kernproblem und Beispiel
Meine größte Herausforderung besteht darin, dass Glibc extrem komplex ist, voller Präprozessoranweisungen und Symbolaliase.
Zum Beispiel, wenn ich ein C-Programm kompiliere, das aufruft open(), readelf zeigt das dynamische Symbol [email protected].
Ich habe dies auf die Glibc-Quelldatei open64.c zurückgeführt. Auf meinem x86_64-System ist das Präprozessormakro __OFF_T_MATCHES_OFF64_T definiert, das zu diesem Block führt:
C
https://git.launchpad.net/ubuntu/+sourc ... untu/jammy

Code: Select all

#ifdef __OFF_T_MATCHES_OFF64_T
strong_alias (__libc_open64, __libc_open)
strong_alias (__libc_open64, __open)
libc_hidden_weak (__open)
weak_alias (__libc_open64, open)
#endif

Dieser schwache_Alias ordnet open __libc_open64 zu. Die Funktion __libc_open64 ruft dann intern SYSCALL_CANCEL (openat, ...) auf. Dieses Makro (das schließlich Inline-Assembly verwendet) ist der Aufruf auf der niedrigsten Ebene, den ich zu finden versuche.
Mein Ziel ist es, diese gesamte Kette für alle Systemaufrufe zu finden: [email protected] → schwacher_alias (__libc_open64, open) → __libc_open64 → SYSCALL_CANCEL (openat, ...)
...und letztendlich das Mapping erstellen:

Code: Select all

open

→ openat[/b],

Code: Select all

openat

→ openat[/b].

(key:value)
Meine Fragen

• Ist es technisch machbar, einen AST-basierten Ansatz (wie libclang) zu verwenden, um die gesamte Glibc-Quelle zuverlässig zu analysieren und alle diese Präprozessoranweisungen und Aliase aufzulösen (

  Code: Select all

  strong_alias

  , schwacher_alias)?
• Mein ultimatives Ziel ist es, eine N:1-Zuordnung von allen Kernel-Systemaufrufen (die in der Nähe von SYS_ify(name) zu finden sind) zu den verschiedenen User-Space-Aliasnamen zu erstellen, die sie aufrufen. Gibt es bereits eine öffentliche Zuordnung dieser Informationen? Ich wäre überglücklich, wenn ich einfach eine vorhandene Ressource nutzen könnte.