Que sont vdso et vsyscall?

Question 1

J'ai fait sudo cat /proc/1/maps -vv

J'essaie de donner un sens à la sortie.Je peux voir beaucoup de bibliothèques partagées mappées au segment de mappage de mémoire comme prévu.

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

Vers la fin, il y a quelque chose comme

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]

Que signifie vdsoet que vsyscallsignifie? vsyscall est-il la partie noyau de la mémoire? Ce serait formidable si quelqu'un pouvait faire la lumière sur la question.

Question 2

Les segments vsyscall et vDSO sont deux mécanismes utilisés pour accélérer certains appels système sous Linux. Par exemple, gettimeofdayest généralement invoqué via ce mécanisme. Le premier mécanisme introduit était vsyscall , qui a été ajouté comme moyen d'exécuter des appels système spécifiques qui ne nécessitent aucun niveau réel de privilège pour s'exécuter afin de réduire la surcharge des appels système. Suivant l'exemple précédent, il gettimeofdaysuffit de lire l'heure actuelle du noyau. Il y a des applications qui appellent gettimeofdayfréquemment (par exemple pour générer des horodatages), au point qu'elles se soucient même d'un peu de surcharge. Pour résoudre ce problème, le noyau mappe dans l'espace utilisateur une page contenant l'heure actuelle et ungettimeofdayimplémentation (c'est-à-dire juste une fonction qui lit le temps gagné dans vsyscall ). En utilisant cet appel système virtuel, la bibliothèque C peut fournir un rapide gettimeofdayqui n'a pas la surcharge introduite par le changement de contexte entre l'espace noyau et l'espace utilisateur généralement introduit par le modèle d'appel système classique INT 0x80ou SYSCALL.

Cependant, ce mécanisme vsyscall a quelques limitations: la mémoire allouée est petite et ne permet que 4 appels système, et, plus important et plus sérieux, la page vsyscall est allouée statiquement à la même adresse dans chaque processus, car l'emplacement de la page vsyscall est cloué dans le noyau ABI. Cette allocation statique du vsyscall compromet l'avantage introduit par la randomisation de l'espace mémoire couramment utilisée par Linux. Un attaquant, après avoir compromis une application en exploitant un débordement de pile, peut invoquer un appel système depuis le vsyscallpage avec des paramètres arbitraires. Tout ce dont il a besoin est l'adresse de l'appel système, qui est facilement prévisible car elle est allouée statiquement (si vous essayez d'exécuter à nouveau votre commande même avec des applications différentes, vous remarquerez que l'adresse du vsyscall ne change pas). Ce serait bien de supprimer ou au moins de randomiser l'emplacement de la page vsyscall pour contrecarrer ce type d'attaque. Malheureusement, les applications dépendent de l'existence et de l'adresse exacte de cette page, donc rien ne peut être fait.

Ce problème de sécurité a été résolu en remplaçant toutes les instructions d'appel système à des adresses fixes par une instruction d'interruption spéciale. Une application essayant d'appeler la page vsyscall piégera dans le noyau, qui émulera alors l'appel système virtuel souhaité dans l'espace noyau. Le résultat est un appel système du noyau émulant un appel système virtuel qui a été placé là pour éviter l'appel système du noyau en premier lieu. Le résultat est un vsyscall qui prend plus de temps à s'exécuter mais, surtout, ne rompt pas l'ABI existante. Dans tous les cas, le ralentissement ne sera vu que si l'application essaie d'utiliser la page vsyscall au lieu du vDSO .

Le vDSO offre les mêmes fonctionnalités que vsyscall, tout en surmontant ses limites. Le vDSO (Virtual Dynamically Linked Shared Objects) est une zone de mémoire allouée dans l'espace utilisateur qui expose de manière sûre certaines fonctionnalités du noyau au niveau de l'espace utilisateur. Cela a été introduit pour résoudre les menaces de sécurité causées par le vsyscall. Le vDSO est alloué dynamiquement, ce qui résout les problèmes de sécurité et peut avoir plus de 4 appels système. Les liens vDSO sont fournis via la bibliothèque glibc. L'éditeur de liens sera lié à la fonctionnalité vDSO de la glibc , à condition qu'une telle routine soit accompagnée d' une version vDSO , telle que gettimeofday. Lorsque votre programme s'exécute, si votre noyau ne dispose pas de vDSO support, un appel système traditionnel sera effectué.

Crédits et liens utiles:

Question 3

Je veux juste ajouter que maintenant, dans les nouveaux noyaux, vDSOn'est pas utilisé uniquement pour les appels système "sûrs", mais il est utilisé pour décider quel mécanisme d'appel système est la méthode préférée pour invoquer un appel système sur le système.

Answer 1

J'ai fait sudo cat /proc/1/maps -vv

J'essaie de donner un sens à la sortie.Je peux voir beaucoup de bibliothèques partagées mappées au segment de mappage de mémoire comme prévu.

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

Vers la fin, il y a quelque chose comme

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]

Que signifie vdsoet que vsyscallsignifie? vsyscall est-il la partie noyau de la mémoire? Ce serait formidable si quelqu'un pouvait faire la lumière sur la question.

Answer 2

5

Google pour VDSO donne ce wikipage VDSO (qui a d'autres références).

Basile Starynkevitch

Answer 3

procfs , consultez la version de votre noyau de ce fichier pour les spécificités de votre système.

bruit sans art

Answer 4

Je pense qu'une meilleure explication que ce qui peut être trouvé dans le wiki ou dans la documentation procfs est nécessaire pour ce sujet.

Giuseppe Pes

Answer 5

Les segments vsyscall et vDSO sont deux mécanismes utilisés pour accélérer certains appels système sous Linux. Par exemple, gettimeofdayest généralement invoqué via ce mécanisme. Le premier mécanisme introduit était vsyscall , qui a été ajouté comme moyen d'exécuter des appels système spécifiques qui ne nécessitent aucun niveau réel de privilège pour s'exécuter afin de réduire la surcharge des appels système. Suivant l'exemple précédent, il gettimeofdaysuffit de lire l'heure actuelle du noyau. Il y a des applications qui appellent gettimeofdayfréquemment (par exemple pour générer des horodatages), au point qu'elles se soucient même d'un peu de surcharge. Pour résoudre ce problème, le noyau mappe dans l'espace utilisateur une page contenant l'heure actuelle et ungettimeofdayimplémentation (c'est-à-dire juste une fonction qui lit le temps gagné dans vsyscall ). En utilisant cet appel système virtuel, la bibliothèque C peut fournir un rapide gettimeofdayqui n'a pas la surcharge introduite par le changement de contexte entre l'espace noyau et l'espace utilisateur généralement introduit par le modèle d'appel système classique INT 0x80ou SYSCALL.

Cependant, ce mécanisme vsyscall a quelques limitations: la mémoire allouée est petite et ne permet que 4 appels système, et, plus important et plus sérieux, la page vsyscall est allouée statiquement à la même adresse dans chaque processus, car l'emplacement de la page vsyscall est cloué dans le noyau ABI. Cette allocation statique du vsyscall compromet l'avantage introduit par la randomisation de l'espace mémoire couramment utilisée par Linux. Un attaquant, après avoir compromis une application en exploitant un débordement de pile, peut invoquer un appel système depuis le vsyscallpage avec des paramètres arbitraires. Tout ce dont il a besoin est l'adresse de l'appel système, qui est facilement prévisible car elle est allouée statiquement (si vous essayez d'exécuter à nouveau votre commande même avec des applications différentes, vous remarquerez que l'adresse du vsyscall ne change pas). Ce serait bien de supprimer ou au moins de randomiser l'emplacement de la page vsyscall pour contrecarrer ce type d'attaque. Malheureusement, les applications dépendent de l'existence et de l'adresse exacte de cette page, donc rien ne peut être fait.

Ce problème de sécurité a été résolu en remplaçant toutes les instructions d'appel système à des adresses fixes par une instruction d'interruption spéciale. Une application essayant d'appeler la page vsyscall piégera dans le noyau, qui émulera alors l'appel système virtuel souhaité dans l'espace noyau. Le résultat est un appel système du noyau émulant un appel système virtuel qui a été placé là pour éviter l'appel système du noyau en premier lieu. Le résultat est un vsyscall qui prend plus de temps à s'exécuter mais, surtout, ne rompt pas l'ABI existante. Dans tous les cas, le ralentissement ne sera vu que si l'application essaie d'utiliser la page vsyscall au lieu du vDSO .

Le vDSO offre les mêmes fonctionnalités que vsyscall, tout en surmontant ses limites. Le vDSO (Virtual Dynamically Linked Shared Objects) est une zone de mémoire allouée dans l'espace utilisateur qui expose de manière sûre certaines fonctionnalités du noyau au niveau de l'espace utilisateur. Cela a été introduit pour résoudre les menaces de sécurité causées par le vsyscall. Le vDSO est alloué dynamiquement, ce qui résout les problèmes de sécurité et peut avoir plus de 4 appels système. Les liens vDSO sont fournis via la bibliothèque glibc. L'éditeur de liens sera lié à la fonctionnalité vDSO de la glibc , à condition qu'une telle routine soit accompagnée d' une version vDSO , telle que gettimeofday. Lorsque votre programme s'exécute, si votre noyau ne dispose pas de vDSO support, un appel système traditionnel sera effectué.

Crédits et liens utiles:

Answer 6

3

Pourquoi vsyscall ne peut-il avoir que 4 appels système? Il y a 8 mégaoctets réservés pour les appels système et une seule page (en fait 3 fonctions, allignées par 1024 prennent 1 page) est utilisée.

skap

Answer 7

Je veux juste ajouter que maintenant, dans les nouveaux noyaux, vDSOn'est pas utilisé uniquement pour les appels système "sûrs", mais il est utilisé pour décider quel mécanisme d'appel système est la méthode préférée pour invoquer un appel système sur le système.

Que sont vdso et vsyscall?

Réponses: