9Fermer11
PpHdLe 13/04/2013 à 12:47
Kevin Kofler (./7) :
Folco (./5) :
La solution qui me paraitrait la plus propre :
- ne pas tenir compte du flag ro sous AMS, dans le cas d'un kernel::exec, kernel::LibsExec ou kernel::LibsCall, car nécessairement ça va planter, on le sait d'avance.
- laisser le programme en ROM s'il est ro lors d'un kernel::LibsPtr, ou d'un relogement à résoudre, car ça ressemble tout à fait à de l'accession de données, pas de code.Cette solution serait totalement transparente pour les anciens programmes, dont les utilisations de libs de données sont très probablement basées sur des relogements.

À mon avis, c'est probablement la meilleure solution. Ça ressemble un peu à l'heuristique de TitaniK pour savoir quand il faut mettre directement l'adresse de destination (accès aux données) et quand il faut interposer le fameux stub de déprotection (appel de code), mais dans ton cas, où le chargement est dynamique, c'est moins risqué parce qu'on a une API différente pour les 2 cas, alors que TitaniK n'a que l'instruction utilisée devant le relogement, qu'il compare bêtement à jsr.l et jmp.l, sans gérer aucun autre cas (genre l'appel indirect avec lea et jsr (%an) etc.).

Mais PpHd a peut-être une autre idée, comme d'habitude. wink


Honnêtement, ca reste une heuristique qui va être fausse de temps en temps.
on peut très bien appeler LibPtr pour remplir une table d'appel indirect, et passer cette table aux autre modules...
Par ailleurs, la relocation se fait au moment de l'appel à Begin et pas lors du Call ou du Ptr... et que tu peux avoir un mélange des 2 dans ton programme.
Je sens une énorme usine à gaz pour le gérer à peu près...


Folco (./9) :
Si pas archivé tu veux dire ? Ok, mais le flag était-il fait pour permettre l'exécution en ROM, ou permettre la lecture de données en ROM sans bouffer la RAM ? Parce que là, on est encore dans un autre contexte qui n'a très probablement pas été pensé au moment du design du flag...

Pour ne pas faire de copie ROM->RAM, c'est tout. Le reste n'est pas géré.
Folco (./9) :
avec le code aussi protégé que la recette du coca-cola ? non merci... puis amha c'est absolument pas à un programme user-space de faire ça.

Pourquoi ne pas l'ajouter dans hw3patch?