3xtr4 ! super sympa, c’est vrai que les chinois sont forts, ils ont su passer outre la muraille
3.
b0l0k | août 24th, 2007 at 12:05
Ouai ils sont peut etre plus fort mais c’est surtout que sur 1 milliard de chinois ya un peu plus de gens qui s’interessent a windows qu’au vieux pingouin
En examinant le code, (notamment celui de KiDeliverApc), je ne vois aucune vérification si le thread est Alertable & Waiting (dans KTHREAD), je vois seulement ce check :
j’ai l’impression que c’est le coup du serpent qui se mort la queue : tu notes qu’on peut bypasser le fait que le thread soit Alertable et Waiting, en utilisant KiInsertQueueApc qui fout le ApcUserPending à 1.
mais dans le code de KiInsertQueueApc : /* Check if this is a non-kernel mode APC */
if (ApcMode != KernelMode)
{
/* Not a Kernel-Mode APC. Are we waiting in user-mode? */
if ((Thread->State == Waiting) && (Thread->WaitMode == UserMode))
{
/* The thread is waiting. Are we alertable, or is an APC pending */
if ((Thread->Alertable) || (Thread->ApcState.UserApcPending))
{
/* Set user-mode APC pending */
Thread->ApcState.UserApcPending = TRUE;
Status = STATUS_USER_APC;
goto Unwait;
}
}
Il faut que le thread soit Alertable et Waiting pour mettre ApcUserPending à 1, beuh ?
J’ai dit !
» le petit souci c’est que comme le dit la doc, un userland APC n’est exécuté que si un thread est à la fois Waiting et Alertable »
Alors a ce moment le ApcUserPending est positionné à 1 et l’APC sera exécuté lors du retour du syscall.
MAIS
Si le thread est en Waiting (ou Running) et qu’il est non Alertable alors ton APC ne sera pas mit en queue et donc non exécuté.
Donc en mettant le ApcUserPending on force l’exécution de l’APC même si celui-ci n’est pas Alertable.
je reviens à la charge : c’est quoi alors le rôle exactement des APIs que t’as cité (WaitForSingleObject, SleepEx) ? C’est de mattre le KTHREAD en Waiting et Alertable pour exécuter le user APC, mais pour que celui-ci soit exécuté ne suffit-t-il pas que le KTHREAD ait UserApcPending == 1 ?
« le petit souci c’est que comme le dit la doc, un userland APC n’est exécuté que si un thread est à la fois Waiting et Alertable, en il faut qu’il est appelé une de ces API »
Ces API mettent le thread en Waiting (ca c’est ok) mais tu peux préciser un flag pour dire si pendant le wait ton thread est alertable. Si jamais il l’est et qu’un APC est envoyé au tread alors l’OS met le flag UserApcPending à 1 et ce dernier sera exécuté lors du retour du prochain syscall.
Donc en mettant le ApcUserPending on force l’exécution de l’APC même si celui-ci n’est pas Alertable !!!!!!!!!!!!!!!!
11 Comments
1. b0l0k | août 21st, 2007 at 17:17
Toujours ce style d’écriture appreciable
Pour ce qui est de la technique j’ai survolé et tu sait ce que j’en pense, on en avais parler 
!
2. Taron | août 23rd, 2007 at 22:28
3xtr4 ! super sympa, c’est vrai que les chinois sont forts, ils ont su passer outre la muraille
3. b0l0k | août 24th, 2007 at 12:05
Ouai ils sont peut etre plus fort mais c’est surtout que sur 1 milliard de chinois ya un peu plus de gens qui s’interessent a windows qu’au vieux pingouin
4. Taron | août 25th, 2007 at 10:51
à Ivan > tu dis :
5. admin | août 25th, 2007 at 11:10
C’est p-e parce que tu n’as pas la bonne version :p
} else if ((Thread->State == Waiting) && (Thread->WaitMode == UserMode) && (Thread->Alertable || Thread->ApcState.UserApcPending)) { Thread->ApcState.UserApcPending = TRUE; KiUnwaitThread(Thread, STATUS_USER_APC, Increment); }6. Taron | août 25th, 2007 at 13:03
c’est le code dans KiInsertQueueApc ça ?
j’ai l’impression que c’est le coup du serpent qui se mort la queue : tu notes qu’on peut bypasser le fait que le thread soit Alertable et Waiting, en utilisant KiInsertQueueApc qui fout le ApcUserPending à 1.
mais dans le code de KiInsertQueueApc :
/* Check if this is a non-kernel mode APC */if (ApcMode != KernelMode)
{
/* Not a Kernel-Mode APC. Are we waiting in user-mode? */
if ((Thread->State == Waiting) && (Thread->WaitMode == UserMode))
{
/* The thread is waiting. Are we alertable, or is an APC pending */
if ((Thread->Alertable) || (Thread->ApcState.UserApcPending))
{
/* Set user-mode APC pending */
Thread->ApcState.UserApcPending = TRUE;
Status = STATUS_USER_APC;
goto Unwait;
}
}
Il faut que le thread soit Alertable et Waiting pour mettre ApcUserPending à 1, beuh ?
c’est quoi la feinte ?
7. admin | août 25th, 2007 at 13:28
J’ai dit !
» le petit souci c’est que comme le dit la doc, un userland APC n’est exécuté que si un thread est à la fois Waiting et Alertable »
Alors a ce moment le ApcUserPending est positionné à 1 et l’APC sera exécuté lors du retour du syscall.
MAIS
Si le thread est en Waiting (ou Running) et qu’il est non Alertable alors ton APC ne sera pas mit en queue et donc non exécuté.
Donc en mettant le ApcUserPending on force l’exécution de l’APC même si celui-ci n’est pas Alertable.
8. Taron | août 25th, 2007 at 14:29
auqai, ho capito !
9. Taron | août 26th, 2007 at 12:27
je reviens à la charge : c’est quoi alors le rôle exactement des APIs que t’as cité (WaitForSingleObject, SleepEx) ? C’est de mattre le KTHREAD en Waiting et Alertable pour exécuter le user APC, mais pour que celui-ci soit exécuté ne suffit-t-il pas que le KTHREAD ait UserApcPending == 1 ?
10. admin | août 26th, 2007 at 12:39
« le petit souci c’est que comme le dit la doc, un userland APC n’est exécuté que si un thread est à la fois Waiting et Alertable, en il faut qu’il est appelé une de ces API »
Ces API mettent le thread en Waiting (ca c’est ok) mais tu peux préciser un flag pour dire si pendant le wait ton thread est alertable. Si jamais il l’est et qu’un APC est envoyé au tread alors l’OS met le flag UserApcPending à 1 et ce dernier sera exécuté lors du retour du prochain syscall.
Donc en mettant le ApcUserPending on force l’exécution de l’APC même si celui-ci n’est pas Alertable !!!!!!!!!!!!!!!!
11. Taron | août 26th, 2007 at 13:44
OKAY !!!!!!!!!!! (jacouille)
Merci
Trackback this post