Ca n'est pas alors un thread malicieux, mais une faille dans un thread existant.
Le résultat de l'exploit d'un overflow dans T1, c'est justement d'en faire un T1 malicieux !
Quand à la séparation des privilèges avec des schedulers internes en userspace qui évitent les changements de contexte, c'est ridicule:
Démonstration par l'absurde. Supposons que ce soit possible.
On a alors les conséquences suivantes:
1. Cela nécessite le stockage de la threadID courante en userspace, pour pouvoir changer cet ID, donc il est modifiable par une thread T1 malicieuse du userspace.
2. Si tu veux protéger l'accès à cet ID par un segfault, alors il y aura passage en kernelspace à chaque scheduling d'une nouvelle tache.
Ce qui contredit l'hypothèse d'origine.
CQFD
# pas de séparation de privilèges avec des schedulers userspace!
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Le résultat de l'exploit d'un overflow dans T1, c'est justement d'en faire un T1 malicieux !
Quand à la séparation des privilèges avec des schedulers internes en userspace qui évitent les changements de contexte, c'est ridicule:
Démonstration par l'absurde. Supposons que ce soit possible.
On a alors les conséquences suivantes:
1. Cela nécessite le stockage de la threadID courante en userspace, pour pouvoir changer cet ID, donc il est modifiable par une thread T1 malicieuse du userspace.
2. Si tu veux protéger l'accès à cet ID par un segfault, alors il y aura passage en kernelspace à chaque scheduling d'une nouvelle tache.
Ce qui contredit l'hypothèse d'origine.
CQFD