[Kos-dev] Double Fault

[Thomas Petazzoni]

> Ce doit être l'adresse du code fautif ! récupère cette adresse et fais
> un désassemblage comme je te l'avais montré chez toi. Pas sur le faux EIP
> empilé dans la pile du Double Fault, hein ! ;) mais bien l'EIP du TSS
> système !

le desassemblage a cette adresse donne le resultat suivant :

Disassemble instruction at 0x5d8448 (size 1) : pushS   %eax.

et voui, l'instruction fautive est bien un push, ce qui semble encore
confirmer le fait que l'histoire du double fault puisse fonctionner.
 
> > En fait, j'ai remarque que si on mettait pas le champ ESP du TSS du
> > double fault a une bonne adresse, celui ci se lancait quand meme
> > mais avec une adresse de pile egale à 0xFFFFFFFF. il devait donc ecraser
> > le PD present a cette adresse, sympa nan ?

> Arf ! tu avais oublié de le placer à la bonne valeur ? j'ai laissé
> passer ça
> ? honte à moi !

euh, nan je crois que tu avais fait pire : moi je m'etais pas pose la
question, j'avais tout initialise ce qui ressemblait a du esp a
l'adresse dela pile, dans le doute. et toi tu m'avais dit que ca servait
a rien d'initialiser le champ ESP, mais que ESP0 suffisait... arf pas
grave, ca m'a fait reflechir :o)
 
> > maintenant le probleme est de retourner de ce handler de double
> > fault. il y a des choses presentes sur la pile, mais pas bcp. pas de EIP,
> > juste un EFLAGS a une valeur de 0x1000. j'ai pas verifie ce que signifiait
> > cette valeur.

> S'agissant d'un TASK GATE, il ne peut y avoir un CS:EIP dans la pile,
> tu trouveras en fait en lieu et place du CS:EIP probablement des 0. Cela
> est normal car le CS:EIP du code interrompu est en fait enregistré dans
> les champs CS et EIP du TSS se trouvant dans le backlink. Le EFLAGS
> contient un bit à 1 qui indique au IRETD de l'exception de faire un TASK GATE sur
> le tss décrit dans le backlink plutôt que de lire le cs:eip dans la pile.
> Dans notre cas, nous avons le CS:EIP du code interrompu dans les champs CS
> et EIP du TSS système qui est lui même pointé par le backlink du TSS
> responsable de la gestion du doublefault.

l'etat de la pile est le suivant :

| ESP    = 0x5c9fdf
| EIP    = 0x0
| CS     = 0x0
| EFLAGS = 0x1000
| EAX    = 0x0
| EBX    = 0x0
| ECX    = 0x0
| EDX    = 0x0
| ESI    = 0x0
| EDI    = 0x0

les EAX, EBX, ECX, EDX, ESI et EDI a 0, c'est tout a fait normal a mon
avis : le TSS utilise pour le double fault les initialise a 0, or
l'empilement de ces registres a lieu qques instructions apres le debut
du handler de double fault, donc ces valeurs ne sont pas du tout
inquietantes a mon avis.

la valeur 0x1000 de Eflags comme je l'ai explique dans un mail a part ne
correspond pas du tout a ce qu'il faudrait. il faudrait que le bit NT
(Nested Task) soit a 1, or ce n'est pas le cas !!! alors je veux bien
changer le EFLAGS a la main, mais est-ce normal ?

> Je pars du principe que c'est le Double Fault qui gère l'aggrandissement de
> la pile système ou la punition de la tâche fautive.

la on est tout a fait d'accord, c'est dans cet objectif la qu'on voulait
gerer le double fault. d'ailleurs a propos de la non garantie de
fonctionnement du retour de double fault, je propose de pour l'instant
gerer ca a coup de #define. ils ne seront pas trop violents, car meme si
les piles sont statiques, nous aurons tout de meme besoin de tout
l'attirail TSS/TaskGate/TSSDescriptor. par la suite, on pourra imaginer
un test au boot des capabilities du processeur, qui permettront de
determiner si il sait gerer les pages de 4Mo, si il sait gerer ca et ca
et ca, et pourquoi pas si il sait gerer le retour du double fault. je
sais pas si c'est faisable de faire un tel test, parce qu'a mon avis, si
ca foire au boot, ca reboote . . . enfin on pourra en parler plus tard,
et au pire, une petite option de compilation de noyau, ca fait de mal a
personne :o))

voili voilo,

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/