Protection mémoire sous MOS ?
-
Salut Eye
je sais pas si c’est ce que tu cherche, j’ai trouver ça pour la gestion de mémoire sous MOS:
http://mos.aminet.net/dev/moni/mui_memdump.lha
et ça:
http://mos.aminet.net/search?query=allocmem
en espérant que cela puisse t’aider
www.amigang-store.com
Le code des applis n’est pas protégé. Celui du kickstart/boot.img oui.
Dans les deux cas cela ne sert à rien mais c’est bidon à rajouter et ne coute rien sauf plus ou moins de mémoire suivant l’os…
Pour ce qui est d’allocmem…. il y avait la même fonctionnalité stupide dans warpup : protéger la mémoire allouée… Ce qui ne servait aussi strictement à rien dans la pratique comme l’histoire l’a indirectement prouvé (et c’était de toute façon lourdement bugué comme souvent avec warpmachin…).
Mais bon, cela permet de faire croire que truc est mieux que bidule aux gens qui ne savent pas ou ne réfléchissent pas donc cela a sans doute de l’intérêt pour les marketroids…
goto 10, même débat/question depuis 10-20 ans
Justement, Fab a très mal répondu puisqu’il n’y a pas de MEMF_PRIVATE/SHARED/etc dans MorphOS et que le code des applis n’est pas « protégé »
Ce ne sont pas les accès à « NULL » qui sont « protégés » mais les accès à la première page (les 4ko du bas sauf 0x4-0x7 accessible en lecture puisque l’adresse execbase y est)… Franchement leo après plus de 10 ans d’enforcer, cyberguard, etc…. à poser les mêmes questions, tu devrais plus que le savoir…
Sont aussi protégées bien d’autres plages d’adresses (mémoire ne correspondant à rien, le contenu du kickstart/boot.img sur morphos, etc).
Ce qui fait qu’accèder à NULL fait un hit mais aussi, généralement, accèder à un offset autour de NULL (genre NULL – xyz (NULL moins xyz) pour les appels de méthode MUI sur des objets NULL, les appels de fonction à des libs dont l’ouverture à échoué etc)
Bref, lire la doc d’enforcer sur aminet puisque tout le reste en dérive que ce soit la « protection mémoire » d’uae, morphos, hyperos, cyberguard, mmuguard, truc, bidule, etc
Dispo depuis qques décennies…
Mod Yay,
Pourrait on imaginer une sorte d’UAC (ceux qui on testé vista savent de quoi il retourne…) version Amiga?
L’idée est la suivante :
– Toute la mémoire est protégée en écriture à l’aide du MMU
– Chaque fois qu’une application accède en écriture à une zone qui est réservée (allocmem, allocvec, etc…), une fenêtre s’ouvre et demande si l’application est autorisée à écrire dans cette zone. Si c’est l’on répond par l’affirmative, le MMU ouvre la zone en écriture. Si on répond pas la négative, on fait croire que l’écriture a eu lieu et on verra bien ce qui se passe…
– Le système se rappelle des zones autorisées ou non (jusqu’au prochain reboot…
mouais…)On risque de cliquer souvent toutefois…
Question supplémentaire : lors d’un appel pour allouer de la mémoire, est il possible de savoir quel est le process qui la réclame ?
Si c’est le cas, dans quel mesure il ne serait pas possible de prédéfinir ces zones allouées comme étant accessibles de facto au process ?
Ca économiserait quelques clics…
Encore un thread pourri tiens…
Discuté trois millions de fois et à chaque fois, la même conclusion : c’est pas possible. (avec la voie de Kad)… Czk.
Henes,
ok, pour le code des applis, je ne me souvenais plus. Par contre j’ai bien dit qu’il n’y avait pas d’appel équivalent à PRIVATE_MEM sous MorphOS.
Pour le code des applis, ce n’est pas bien grave. Il est effectivement statistiquement inutile de le protéger, puisqu’en pratique, c’est quasiment toujours la pile ou le tas qui se fait exploser.
Leo,
sur le 2.x, tu règles dans prefs->log la valeur des max hits & exceptions à 1.
@fab
Je ne suis pas sur que bcp vont se souvenir/comprendre la pertinence de la dernière remarque. Ceci dit, c’est tellement drole à postériori (déjà qu’à propri c’était fameux…
Je t’ai en fait répondu quelques posts plus haut
il n’y a pas de MEMF_PRIVATE/SHARED/etc dans MorphOS et le code des applis n’est pas « protégé »
- Vous devez être connecté pour répondre à ce sujet.
