Détection de stack underflow - Page 1

Underflow? Je connaissais même pas! C'est quoi la différence par rapport à un stack overflow?

Rien de tel qu'un petit tour sur le wiki :

http://en.wikipedia.org/wiki/Buffer_underflow
http://en.wikipedia.org/wiki/Buffer_overflow

Merci des précisions à vous deux.

Ah oui desolé Martial
Stack underflow, et pas Buffer underflow

Martial: a moins de faire des choses bizzares, sans MMU ça me parais dur, ou alors il faudrait que tout tes programmes se tiennent d'utiliser une fonction spécifique pour acceder a la pile (bonjour les perfs)

non il n'y a pas d'exception, enfin pas sur 68000 (il n'y en a pas non plus pour du stack overflow), enfin pas en 68K brut.

tu pourrais le savoir "post mortem" si tu décores la zone de mémoire potentiellement touchable avec un pattern particulier style 0xDEADBEEF ou 0x55AA55AA et après tu regardes quelles sont les adresses touchées.

Certe, mais c'est un peu tard

je sais, mais c'est un vrai problème pour les machines sans mmu.

Le seul truc que TI a trouvé sur les ti68k c'est protéger en écriture la zone des vecteurs (le premier ko, je crois) pour obtenir un adress error.

(Hors sujet : N'y aurait t-il pas moyen d'utiliser ces overflow pour balancer du code machine sur les N-Spire?)

Ca correspond aux besoin de Martial ? Si le bas de la pile est juste après les vecteurs, c'est dans la poche Il suffit de rediriger l'interruption pour gérer l'underflow.

Il y a deux piles séparées ? Pourquoi ?

OK mais l'intéret ?

Thi > sur TI c'est complètement dénaturé à cause du trap #12 mais sur un vrai OS 68k, le noyau tourne en mode superviseur et les programmes utilisateur en mode normal. Le fait d'avoir deux piles séparées permet d'éviter des failles à base de traps.

En gros, en mode superviseur, a7 est la pile superviseur, et la pile utilisateur ne peut se manipuler qu'avec move an,usp. c'est un registre comme un autre.

Quand la machine boote t'es en mode superviseur. le vrai kernel au sens de linux peut s'exécuter. Ensuite quand on démarre un processus, on passe en mode utilisateur ^*. Dans ce cas, a7 est sauvé dans ssp, et usp est placé dans a7.

Quand un programme en mode normal exécute trap #n, le CPU passe en mode superviseur (donc a7=ssp, et pas usp), met le SR (qui contient le mode et les flags) sur la pile, puis met le PC de l'appelant sur la pile. En gros on est "rentré dans le noyau" pour faire par exemple un appel système. A la fin du trap, on doit faire RTE pour revenir au processus, car on doit dépiler le PC de retour ET AUSSI le SR qui permettra de revenir en mode utilisateur.

L'idée d'avoir deux piles séparées ça permet d'éviter que le RTE revienne en restant en mode système en trafiquant simplement le SR qui resterait sur la pile utilisateur. parce que le trap a switché en pile superviseur avant de sauver SR et PC.

tu vois le truc? pour moi c'est évident car éprouvé durement en projet système T_T , mais c'est pas forcément clair à la première lecture.

Ben... j'ai relu 2 fois mais je vois pas comment on pourrait trafiquer la copie du SR. Il faudrait pouvoir exécuter le code qui trafique en mode superviseur, puisque le SR est copié après le passage en mode superviseur. Or, on peut pas exécuter du code en superviseur tant qu'on n'a pas trafiqué le SR. C'est le serpent qui se mort la queue non ?

Si on sépare pas les piles, le programme peut écrire ce qu'il veut sur la pile, ça sera écrasé lors du passage en mode superviseur.

> Le seul truc que TI a trouvé sur les ti68k c'est protéger en écriture la zone des vecteurs (le premier ko, je crois) pour obtenir un adress error.
> "Out of memory" plutôt
Non, c'est l'AI7 (non masquable, même avec (SR & $0F00) = $0700).
AMS la traite par un dialogue indiquant "Protected Memory Violation".

21> j'explique mal. c'est pas simple du tout. Mais imagine une routine noyau (style appel système write) à qui tu donnes une adresse d'écriture bidon. Tu peux lui donner l'adresse correspondant au pt de stockage du sr, et lui demander de l'écraser. En faisant RTE, tu récupères alors ton SR modifié, et pas celui qui a été stocké. Ce qui te permet de définir le bit S depuis le mode superviseur. (en utilisateur, tu peux pas changer ce bit, par contre, le code du trap le peut, puisqu'il est exécuté en superviseur.) Avoir deux piles limite ces pbms, puisque tu sais pas ou est le SSP. (il faut le deviner, on peut pas le lire directement depuis le mode normal)

squalyl (./24) :
(il faut le deviner, on peut pas le lire directement depuis le mode normal)

sauf si bonne connaissance de l'OS ou tu peut savoir ou il "cache" la SSP

Lionel Debroux (./23) :
on, c'est l'AI7 (non masquable, même avec (SR & $0F00) = $0700).

D'ailleurs à la base c'est pour se protéger des stack underflows ce mécanisme

Godzil > évidemment, mais c'est moins par zazard, du coup

D'accord Merci pour cette initiation aux techniques de hack C'est tout bête mais intéressant à savoir.

apparemment ça avait des conséquences importantes pour les unix 68k par exemple