Was sind vdso und vsyscall?

Question 1

Ich tat sudo cat /proc/1/maps -vv

Ich versuche, die Ausgabe zu verstehen. Ich kann sehen, dass viele gemeinsam genutzte Bibliotheken wie erwartet dem Speicherzuordnungssegment zugeordnet werden.

7f3c00137000-7f3c00179000 r-xp 00000000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00179000-7f3c00379000 ---p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00379000-7f3c0037a000 r--p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037a000-7f3c0037b000 rw-p 00043000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037b000-7f3c00383000 r-xp 00000000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00383000-7f3c00583000 ---p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00583000-7f3c00584000 r--p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00584000-7f3c00585000 rw-p 00009000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00585000-7f3c0059b000 r-xp 00000000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0059b000-7f3c0079b000 ---p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0079b000-7f3c0079c000 r--p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0

Gegen Ende gibt es so etwas wie

7f3c0165b000-7f3c0177e000 rw-p 00000000 00:00 0                          [heap]
7fff97863000-7fff97884000 rw-p 00000000 00:00 0                          [stack]
7fff97945000-7fff97946000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Was macht vdso und vsyscall bedeuten? ist vsyscall der Kernelteil des Speichers? Es wäre toll, wenn jemand Licht ins Dunkel bringen könnte.

Question 2

Das vsyscall und vDSO Segmente sind zwei Mechanismen, die verwendet werden, um bestimmte Systemaufrufe in Linux zu beschleunigen. Zum Beispiel, gettimeofday wird normalerweise über diesen Mechanismus aufgerufen. Der erste eingeführte Mechanismus war vsyscall, das hinzugefügt wurde, um bestimmte Systemaufrufe auszuführen, für deren Ausführung keine wirkliche Berechtigung erforderlich ist, um den Systemaufruf-Overhead zu reduzieren. Nach dem vorherigen Beispiel all gettimeofday tun muss, ist die aktuelle Zeit des Kernels zu lesen. Es gibt Anwendungen, die anrufen gettimeofday häufig (z. B. zum Generieren von Zeitstempeln), bis zu dem Punkt, dass sie sich auch nur um ein bisschen Overhead kümmern. Um dieses Problem zu lösen, bildet der Kernel im Benutzerraum eine Seite ab, die die aktuelle Zeit und eine Fast enthält gettimeofday Implementierung (also nur eine Funktion, die die eingesparte Zeit einliest vsyscall). Unter Verwendung dieses virtuellen Systemaufrufs kann die C-Bibliothek eine schnelle Bereitstellung bereitstellen gettimeofday das nicht den Overhead hat, der durch den Kontextwechsel zwischen Kernel-Space und User-Space eingeführt wird, der normalerweise durch das klassische Systemaufrufmodell eingeführt wird INT 0x80 oder SYSCALL.

Dies jedoch vsyscall Mechanismus hat einige Einschränkungen: Der zugewiesene Speicher ist klein und erlaubt nur 4 Systemaufrufe, und, wichtiger und schwerwiegender, die vsyscall Seite wird in jedem Prozess statisch derselben Adresse zugewiesen, da der Speicherort der vsyscall Seite ist im Kernel ABI festgenagelt. Diese statische Zuweisung des vsyscall kompromittiert den Vorteil, der durch die Randomisierung des Speicherplatzes eingeführt wird, die üblicherweise von Linux verwendet wird. Ein Angreifer kann, nachdem er eine Anwendung durch Ausnutzen eines Stapelüberlaufs kompromittiert hat, einen Systemaufruf vom aufrufen vsyscall Seite mit beliebigen Parametern. Alles, was er braucht, ist die Adresse des Systemaufrufs, die leicht vorhersehbar ist, da sie statisch zugewiesen wird (wenn Sie versuchen, Ihren Befehl auch mit anderen Anwendungen erneut auszuführen, werden Sie feststellen, dass die Adresse der vsyscall ändert sich nicht). Es wäre schön, den Speicherort der vsyscall-Seite zu entfernen oder zumindest zufällig zu bestimmen, um diese Art von Angriff zu vereiteln. Leider hängen Anwendungen von der Existenz und der genauen Adresse dieser Seite ab, sodass nichts getan werden kann.

Dieses Sicherheitsproblem wurde behoben, indem alle Systemaufrufbefehle an festen Adressen durch einen speziellen Trap-Befehl ersetzt wurden. Eine Anwendung, die versucht, in die anzurufen vsyscall page wird in den Kernel eingefangen, der dann den gewünschten virtuellen Systemaufruf im Kernelraum emuliert. Das Ergebnis ist ein Kernel-Systemaufruf, der einen virtuellen Systemaufruf emuliert, der dort platziert wurde, um den Kernel-Systemaufruf überhaupt zu vermeiden. Das Ergebnis ist ein vsyscall Die Ausführung dauert länger, bricht aber vor allem nicht die bestehende ABI. In jedem Fall wird die Verlangsamung nur angezeigt, wenn die Anwendung versucht, die zu verwenden vsyscall Seite statt der vDSO.

Das vDSO bietet die gleiche Funktionalität wie vsyscall, überwindet aber dessen Einschränkungen. Das vDSO (Virtual Dynamically Linked Shared Objects) ist ein Speicherbereich, der im Benutzerbereich zugewiesen ist und einige Kernel-Funktionalitäten im Benutzerbereich auf sichere Weise verfügbar macht. Dies wurde eingeführt, um die Sicherheitsbedrohungen zu lösen, die durch die verursacht werden vsyscall. Das vDSO wird dynamisch zugewiesen, was Sicherheitsprobleme löst, und kann mehr als 4 Systemaufrufe haben. Das vDSO Links werden über die glibc-Bibliothek bereitgestellt. Der Linker verlinkt in der glibc vDSO Funktionalität, vorausgesetzt, dass eine solche Routine eine begleitende hat vDSO Version, wie z gettimeofday. Wenn Ihr Programm ausgeführt wird, wenn Ihr Kernel dies nicht hat vDSO Unterstützung, wird ein herkömmlicher Systemaufruf durchgeführt.

Impressum und nützliche Links:

Was ist linux-gate.so.1?

Question 3

Ich möchte das jetzt nur in neuen Kerneln hinzufügen, vDSO wird nicht nur für “sichere” Systemaufrufe verwendet, sondern wird verwendet, um zu entscheiden, welcher Systemaufrufmechanismus die bevorzugte Methode zum Aufrufen eines Systemaufrufs auf dem System ist.