Discussion :

[touronster]

Bonjour, depuis quelques temps je suis plongé dans les entrailles de windows, mais je n'arrive à comprendre certaines choses (attention, post surtout destiné aux experts). Notamment, je me demande à quoi sert concrétement les structures kernel KTHREAD, ETHREAD dans le cas d'une exécution kernel-mode "only", j'entends par là, un driver par exemple. Puisque ces structures sont censées (d'après moi) décrirent des threads user-land après qu'il y ait eu passage en kernel-land (ex: lors d'un appel system) ; que sont'ils censés décrire lors d'exécution en kernel mode seulement (driver), puisqu'il n'y est plus question de thread user-land dès lors ?

J'espère avoir été asse clair :s

PS: sinon, que désigne-t-on exactement par Kernel Thread ? La continuation d'exécution d'un thread userland en mode kernel ?

Merci

[nicolas.sitbon]

Puisque ces structures sont censées (d'après moi) décrirent des threads user-land après qu'il y ait eu passage en kernel-land (ex: lors d'un appel system) ;

Non, chaque thread sous windows est représenté par une structure ETHREAD contenant l'ID processus, messages LPC, heures de créations etc + un champs pointant une structure KTHREAD contenant entre autre, tous les champs nécessaire à un basculement de contexte (adresse de base et supérieur de pile noyau, cumul des temps processeur, dispatcher, ordonancement...).
Ainsi, quand basculement de contexte il y a, même d'un thread user à un thread user, la structure KTHREAD est mise à jour et il en va de même d'un thread noyau à un thread noyau.
Cordialement.

[sloshy]

Bonjour,
je ne pense pas que la gestion des processus (à ce niveau) soit influancé par la zone mémoire à partir duquel celui-ci est executé.
Si on prend l'exemple "simple" d'un listage de processus, sans ETHREAD ni KTHREAD, pas d'accès à l'EPROCESS et donc tu brises la liste doublement chainée permettant de lister les processus.

Après, je ne suis pas un pro ...

[touronster]

Ce qui m'intrigue c'est dans le cas d'un thread noyau, caractérisé notamment par sa structure KTHREAD, sur quoi pointe son champ TEB ?
Un thread noyau possède aussi un TEB en user-land ?

[Médinoc]

Je ne suis pas expert de Windows en mode kernel, mais qu'appelles-tu exactement un thread noyau ?

Est-ce simplement un thread qui ne passe jamais en mode User, ou y a-t-il vraiment des différences plus significatives ?

[touronster]

Je dirais simplement un thread qui ne passe jamais en mode User. C'est aussi assez flou pour moi, les threads noyau, pour ça que je demande quelques infos dessus. Parce que apparement tous les threads (user & noyau) possèdent un KTHREAD, et le champ TEB de KTHREAD pointe sur du userland, je me demandais alors si tout thread (user & noyau) possédait une structure TEB en userland ?

Merci, je repasserais voir demain.

[Neitsa]

Bonjour,

Parce que apparement tous les threads (user & noyau) possèdent un KTHREAD

Oui c'est exact.

et le champ TEB de KTHREAD pointe sur du userland

Oui mais uniquement pour un thread créé en user-land.

je me demandais alors si tout thread (user & noyau) possédait une structure TEB en userland ?

Non ! Les threads créés depuis l'espace kernel ne peuvent avoir de TEB (PTEB = NULL).

Il est extrêmement compliqué de créer un thread kernel (plus exactement : un thread créé depuis le kernel par un driver) qui va tourner dans le contexte du processus et avoir accès aux données du processus. Ne pas oublier que pour un thread, tout est une histoire de "contexte". Extrêmement compliqué pour la simple et bonne raison qu'il y a trop de chose à faire au niveau user land (allocation de la page du TEB, init du TEB, allocation de la pile du thread user-land, protection de la page de pile, initialisation du contexte (CONTEXT) du thread, etc.).

Les worker threads kernel sont fait pour rester cantonnés au kernel et tourner dans le contexte "system" pas dans le contexte d'un processus.

[edit]

Tiens j'y pense, il existe bien une fonction qui fait tout cela (init d'un thread user-land depuis le kernel), mais... elle n'est pas exportée par le kernel : il s'agit de RtlCreateUserThread(). A voir pour ceux que ça pourrait intéresser.

[touronster]

Bonjour,



Oui c'est exact.



Oui mais uniquement pour un thread créé en user-land.



Non ! Les threads créés depuis l'espace kernel ne peuvent avoir de TEB (PTEB = NULL).

Il est extrêmement compliqué de créer un thread kernel (plus exactement : un thread créé depuis le kernel par un driver) qui va tourner dans le contexte du processus et avoir accès aux données du processus. Ne pas oublier que pour un thread, tout est une histoire de "contexte". Extrêmement compliqué pour la simple et bonne raison qu'il y a trop de chose à faire au niveau user land (allocation de la page du TEB, init du TEB, allocation de la pile du thread user-land, protection de la page de pile, initialisation du contexte (CONTEXT) du thread, etc.).

Les worker threads kernel sont fait pour rester cantonnés au kernel et tourner dans le contexte "system" pas dans le contexte d'un processus.

[edit]

Tiens j'y pense, il existe bien une fonction qui fait tout cela (init d'un thread user-land depuis le kernel), mais... elle n'est pas exportée par le kernel : il s'agit de RtlCreateUserThread(). A voir pour ceux que ça pourrait intéresser.

Yep ! Merci