RING0 ... petit soucis !

Signaler
Messages postés
18
Date d'inscription
jeudi 26 juin 2003
Statut
Membre
Dernière intervention
24 novembre 2003
-
 benjdu -
Bonjour a tous !
J'ai implémenté le passage en Ring0 via un Callgate ...
j'ai fait ca en Delphi, mais peu importe, il y a bcp plus de programmeurs C ... alors je pose ma question ici ! hi !
La programme tourne, je passe en Ring0, et j'en reviens, ca c'est certain. En fait, je suis parti du soft MASM de Chris_Hks (source disponible sur le forum). Le problème est que le code qui s'exécute en Ring0 plante l'ordi dans certaines conditions ... toutes simples. Si je place en Ring0 une suite d'instructions (privilégiées ou non, je suis en Ring0, tout passe sans me sortir d'exeption), pas de problème ! mais si je "reste" trop longtemps, par exemple, en placant une boucle (simplement décrémenter ecx et boucler) avec un grand nombre d'itération (ex:300.000), bein ca plante a chaque coup ... écran bleu grave ! On dirait que le système n'aime pas que je reste trop longtemps en Ring0 ... !
Le soft MASM de l'auteur Chris_Hks, présente le meme problème ... plantage memes conditions !
Je suis meme passé en "Real Time" avant le passage en Ring0, avec SetPriorityClass + SetThreadPriority. Et je passe effectivement en "Real Time ", en tout cas, tant que je suis en Ring3 c'est certain, j'ai vérifié. Normalement, je dois arriver en Ring0 avec le meme niveau de priorité ... normalement ! Dans ma routine Ring0, j'ai un " cli " et j'ai meme désactivé NMI via le port 70 ! ... mais ca plante toujours quand je place une "grande" boucle de temporisation en Ring0 ! Suis dans une impasse ! POURQUOI me code en Ring0 fait il planter l'ordi quand je "reste" trop longtemps en Ring0 ??? TOUTES les idées sont les bien venues.
Si vous avez des questions, faut d'mander ...
Tout grand merci a tous .
A voir également:

4 réponses

Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
23
J'avais deja signale cela mais je n'ai toujours pas de reponse valable sur le pourquoi. Tu fais bien de relancer cette reflexion.
BruNews, ciao...
Messages postés
18
Date d'inscription
jeudi 26 juin 2003
Statut
Membre
Dernière intervention
24 novembre 2003

Ah bon, suis pas tout seul a avoir rencontré ce problème ?
bien ! bonne nouvelle quelque part, hi !
Bein moi, j'ai une idée ...
En fait, quand on passe en Ring0 par un Callgate, c'est du piratage ! Oui, on se retrouve en Ring0 ... mais 1) on est toujours en muti-taches et 2) l'OS ne le sait pas qu'on est en Ring0. Je veux dire par la que l'état de privilège 0 de notre code n'est pas repris dans le "plan" général de gestion de l'OS ... bein non, il n'est pas au courant, on lui a fait ca par derrière !!! Conclusion, pour lui, notre code est toujours repris comme code Ring3, aie ! Il va donc, quand il en a besoin, reprendre la "main" pour ses propres besoins et notamment pour switcher de taches ! et la , ca pose problème ! Car un soft ne peut interrompre un autre soft par IRQ que s'il posède un niveau de privilège supérieur ! Si le niveau de privilège est égal ou inférieur, ca provoque une exeption, et ca plante ! Quand l'OS regarde notre code, via les données
de son descripteur, il se rend compte (pour la 1ere fois)
qu'il s'adresse a du code Ring0 ... il ne le savait pas jusque
la ! ... et Boum ! C'est l'écran bleu !!! avec qq infos et notemment j'ai vu : Interrupt_Less_or_equal ... hum !
Si notre code a une priorité de Class "Normal", ca arrive très vite. Si on place notre code Ring0 en "Real Time" ... on peut "trainer" en PL0 plus longtemps. Mais, ca bug quand meme après un certain temps, car Real Time ne veut pas dire "mode réel" ou "mono-tache" ...
Meme en real time, l'os pointe son nez de temps en temps !
voila ! Alors, la solution ? J'ai une idée ... hi !
L' APIC, le controleur programmable des interruptions.
Le mettre OFF ! on peut le disabl-er de 2 facons, une irréversible (jusqu'au prochain reset machine) et l'autre réversible ! Je dois pour ca accéder a son registre situé a l'adresse physique FEE000F0 ... je cherche... la, toutes les infos sont les bien venues ..
Messages postés
9
Date d'inscription
vendredi 14 février 2003
Statut
Membre
Dernière intervention
21 mars 2008

Pour evité ça, essay de ne créer qu'un loader... tu passe en Ring0 et tu lance une application en R0... elle ne devrait pas planter si elle est déclarer ;)

De toute les chose que j'ai perdu...
Celle qui me manque le plus...
C'est mon esprit.
Bonjour !
J'ignore si tu es encore présent sur ce forum et même si tu liras ce message, mais sache pour éviter ce type de crash , il faut désactiver les interruptions masquables (attention : ne pas utiliser la mémoire virtuelle donc) avec l'instruction cli (ou sti, je ne sais plus, l'une les désactive et l'autre les rétablit), et les réactiver ensuite. Attention, l'instruction doit se faire DES l'arrivée en ring 0, si ton flux se fait préempté, c'est le BSOD. Par ailleurs, entre le temps où ton thread arrive et exécute cli, et où le thread exécute sti, il s'écoule un petit laps de temps. Les chances pour qu'un bsod survienne sont quasi-nulle. Mais évite de boucler sur une le passage 3->0 via callgate, sinon là tu n'es assuré de rien. Je te rappelle que le mécanisme de pagination qui permet l'utilisation de la mémoire virtuelle ne peut donc pas être utilisée, dépendant d'interruptions d'irql software.