Comment Windows passe-t-il en mode superviseur lors d'un appel système? J'ai entendu quelque chose à propos d'un "piège 0", mais cela ne semble même pas être une instruction x86. J'ai franchi quelques appels système, mais je n'en trouve aucun. Est-ce que beaucoup d'appels système Windows s'exécutent en mode utilisateur? Qui fonctionne en mode superviseur?Comment Windows passe-t-il en mode superviseur lors d'un appel système?
Un appel système est également appelé interruption logicielle. L'instruction x86 qui appelle une interruption logicielle a le mnémonique INT. La façon dont les données sont transmises au système d'exploitation est définie par le système d'exploitation ABI. Pour autant que je sache, Windows utilise le 0x80 immédiat pour toutes ses routines et envoie des données supplémentaires via des registres, mais je ne suis pas sûr. 0x20 est le premier disponible immédiatement, puisque la plage 0 à 31 est réservée et utilisée pour les exceptions générales comme la division entière par zéro et les fautes de mémoire.
Ce qui essentiellement arrive est que la CPU en mode privilégié et lit le IDTR (Interupt Descriptor Table Register). Là, il trouve l'adresse mémoire physique pour l'IDT (Interupt Descriptor Table) et fait une recherche dans l'IDT, basé sur l'instruction d'interruption logicielle 8 bits immédiatement cuite. L'IDT peut être stocké n'importe où dans la mémoire. L'IDTR peut être lu/écrit par les instructions LIDT et SIDT. L'IDT peut stocker une variété d'informations, mais pour les interruptions, il stocke l'adresse dans la routine de service associée à l'INT immédiatement.
Exemples de fonctions win32 qui déclenchent une interruption logicielle .. hm. printf et amis le fait, comme le fait EnterCriticalSection. Dans Windows Vista et Windows 7, certains appels d'API OpenGL et DirectX nécessitent désormais un aller-retour dans les zones du noyau en raison du nouveau gestionnaire composite. Pour OpenGL, cela s'applique à toutes les fonctions qui lisent le backbuffer actuel, comme glReadPixels, glCopy (Sub) TexImage2D, etc.
P.S: Prenez ce post avec une pincée de sel. Ça fait longtemps que je n'ai pas fait de Windows de cette façon, et je n'ai pas fait beaucoup de vérifications. Les modifications et les commentaires sont les bienvenus.
Et voici un lien vers le Intel 386 manual original (que je citais de toute façon)
processeurs x86 fournissent les instructions SYSENTER et SYSEXIT. Ces instructions exécutent un passage très rapide du mode utilisateur au mode noyau et inversement, et les systèmes d'exploitation modernes fonctionnant sur des processeurs modernes les utilisent probablement au lieu d'interruptions très coûteuses ou d'appels lointains.
Vous pouvez voir plus de détails dans Intel's Software Developer's Manuals, en particulier volume 2B
Lisez également les livres Windows Internals. Ils sont bons pour la compréhension. – ChristianWimmer
Hummm ... les callbacks d'onde sont 100% code de mode utilisateur dans Vista et plus. Il y a un appel en mode noyau effectué pendant le traitement des API, mais c'est juste parce qu'il y a un appel IPC fait d'un processus en mode utilisateur à un autre et qui implique des appels système. –
Correction, merci :-) Je suis assez sûr que c'était le cas dans Windows 3.1 à travers Windows 98 cependant. –
Donc les commutateurs en mode superviseur sont ceux INT3 que je vois dispersés tout autour? Je n'en ai jamais vu dans le code exécuté. Je suis sur win64 (W7) en ce moment, et je ne peux pas détecter de sauts en mode superviseur dans EnterCriticalSection. (http://slask.sys5.se/q/RtlEnterCriticalSection.png) Printf n'est pas un appel API, c'est une fonction C. –