Protection Memoire une autre voie
-
@Batteman: bein.. la protection mémoire t’empêche de vautrer tout le système au moindre crash. Donc si t’as que le resource_tracking, si ton programme a pas encore tout vautré, tu dois pouvoir le killer et le relancer… Mais c’est vrai que l’un sans l’autre… bof bof.
@+,
Léo.
Hello!
Il existe une “semi” alternative: Personnellement, j’ai sur Ambient un raccourcis sur Scout: Lorsque je sais qu’un programme a des “chances” de planter, je pré-ouvre Scout, sinon, dans la plupart des cas, quand je vois un commencement de plantage, j’ai le temps de cliquer sur le raccourcis… Quelque fois il met du temps à démarrer, mais après, il suffit de tuer la tâche vilaine…
Bien sûr, on peut aussi lancer Scout par une combinaison de touches… mais j’ai eu jusqu’à présent la flemme de configurer ça (je sais: honte sur moi! )
/ Amigalement!
Bien sûr, cela marche aussi sur Amiga classique ou AOne!
Pour moi, le resource tracking c’est le fait que l’OS sait quelles ressources sont utilisées par une application comme ça il peut les fermer lorsque l’application se termine normalement (sans tout libérer) ou lors d’un crash.
La mémoire virtuelle, c’est manipuler des adresses mémoire virtuelles qui sont associées à des adresses physiques. C’est la tambouille de l’OS grâce à la MMU. Ca peut être poussé jusqu’à l’utilisation du disque dur pour stocker des pages mémoire inutilisées.
L’exploitation de la mémoire virtuelle amène ainsi la protection mémoire, en protégeant l’écriture à certains endroits, en séparant les zones utilisées pour pas qu’elles ne se marchent dessus, …
Il me semble que ca dois dépendre du style de programation utilisé :
Avec du code réentrant, (obligatoire pour les .library), on peux mieux isoler et affecter des plages mémoires aux programmes.
A défaut d’être réentrant, ils dois être relogeable.
Par exemple ne pas écrire :
JRS MAROUTINE
mais
BSR MAROUTINE
JSR est fait un saut absolu alors que BSR est relatif.
Assemblé ca peux donner ceci :
A l’adresse 100 On trouve le code ‘JSR MAROUTINE’, assemblé en ‘JSR 150’
A l’adresse 150 On trouve le code de MaRoutine.
Le JSR dit: ‘va a l’adresse 150’
Le BSR dit: ‘va a l’adesse 50 lignes plus bas.’
Donc avec un programme écrit avec des BSR, on peux déplacer tout le programme en mémoire et le garder correct.
Si on charge ce programme à l’adresse 1000,
A l’adresse 1100 On trouve le code ‘BSR MAROUTINE’, remplacé par BSR +50
A l’adresse 1150 On trouve le code de MaRoutine.
Si on conserve le JSR, on aurra toujours un JSR 150, produit par l’assembleur et donc un crash de protection mémoire, puisque notre programe n’y est plus.
Pour l’accès aux variables, je crois que c’est un peu la même chose, mais je ne me souviens plus de la syntaxe.
Donc, tant qu’il est permis de faire de l’assembleur de cette manière, on ne pourra pas garantir la protection mémoire.
Le plus dur à controler, c’est bien entendu les écritures avec le blitter. Donc la mémoire CHIP est bien plus difficile à protéger que la mémoire FAST, inaccessible par le blitter.
Si je parle de ceci, c’est parce que la facon évidente de protéger la mémoire c’est de réorganiser l’adressage comme suit :
Au lieu d’utiliser les 32 bits du registre d’adresse, qui peut adresser 4giga, on réserve les 8 bits de poids fort pour stocker un numéro de page, et les 24 bits de poids faible pour stocker un adressage de 16 Méga octets. Une simple interface (MMU ou logicielle ?) peut recalculer l’adressage réel en fonction de la taille alouée pour chaque page.
Je suis assez curieux de savoir si le pegasos, ou l’Aone fait ca. L’adressage est surrement passé à 64 bits non ? (Perso, je n’ai qu’un brave 1200+8mo donc je n’en sais rien)
J’ai un peu de mal à voir le rapport en fait.
En soit il n’y a aucun problème à implémenter une protection mémoire si on change certains éléments de l’api (message, libraries, …), donc on peut passer sur la façon d’organiser la mémoire, c’est vraiment pas le problème.
Le vrai problème est qu’avec l’api actuelle, certains morceaux de mémoire *doivent* être accessibles en lecture et écriture par toutes les tâches (les messages par exemple, autour desquels tout est basé), ce qui est bien sûr incompatible avec le concept de protection mémoire.
Dans un système protégé, pour arriver à ça, on définit un segment de mémoire partagée auquel chaque processus peut alors accéder. Mais ce segment de mémoire partagée est bien entendu alloué d’une manière bien particulière avec une fonction bien précise, ce qui n’est par exemple pas le cas des messages amigaos qui peuvent être alloués à partir de n’importe quelle fonction d’allocation mémoire.
Donc pour résumer, et pour la 98465465 fois, on perdrait toute compatibilité binaire et source si on décidait d’implémenter la protection mémoire sur les amigaos-like.
GuardianAngel (GuardianAngelRmx, l’option GUARD de CyberGuard, MuGardianAngel…) protège la mémoire NON ALLOUEE.
Cela ne sert ni à protéger les programmes en train d’être exécutés ni à protéger l’OS.
Donc cela ne sert en fait strictement à rien sinon à, parfois, détecter une écriture/lecture folle qui, par chance, s’est produite à une adresse libre.
Le tout au prix d’une énorme baisse de performance de tout l’OS et de toues les applications.
Le rapport, c’est que en utilisant les bits de poids forts on pourrait protéger la mémoire.
Si l’adresse est décrite de $0000 0000 à $FFFF FFFF
Si on utilise le 1er octet pour stocker un numéro de page (nommé P) on a donc plus que de $00 0000 à $FF FFFF pour stocker l’adresse, soir 16 Mo de mémoire (nommé M).
L’adressage est donc de cette manière : $PPMM MMMM
On peux utiliser 256 pages et 16 Mo de mémoire par page maxi.
Tous les programmes peuvent donc conserver leur ancien adressage dans les adresses basses, de $00 0000 à $FF FFFF et il suffit de préfixer les appels mémoire par le numéro de page.
Ex : $0100 0001 = adresse 1 de la page 1.
Ensuite, il faut un MMU pour refaire un adressage vers la mémoire réelle:
En effet, si la page 0 fait 65535 octets, soit $FFFF. Tout acces en dehors de la zone de 0000 à $FFFF serait sanctionné d’une erreur de protection mémoire.
En mémoire réelle, la page 1 ne commencerait pas en $0100 0000 mais en $1 0000, à la suite de la page 0. C’est le travail de la MMU: Elle dois re-calculer les adresses pour que les 256 pages de 16 Mo Max (donc 4 Giga) tiennent sur la mémoire disponible en collant les pages les unes derrières les autres.
Ca me parrais possible, mais sur Amiga il faut se méfier des adresses DFF ???? qui sont des registres: C’est une autre difficulté à contourner…
henes a écrit :
GuardianAngel (GuardianAngelRmx, l’option GUARD de CyberGuard, MuGardianAngel…) protège la mémoire NON ALLOUEE.
[…]
Donc cela ne sert en fait strictement à rien sinon à, parfois, détecter une écriture/lecture folle qui, par chance, s’est produite à une adresse libre.
[…]
C’est quand même une méthode non infaillble qui permet de vérifier si un programme est louche.
C’est utile pour les développeurs maladroits des doigts mais un peu consciencieux quand même.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › Protection Memoire une autre voie
