Protection mémoire sous MOS ?

[eye]

eye

#6392

sur os4 un appel AllocMem avec comme 2eme argument MEMF_PRIVATE permet-elle d’avoir un espace mémoire protégé ?

Y a t’il un equivalent sur MOS?

[papiosaur]

papiosaur

#104774

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

[Fab1]

Fab1

#104775

eye,

ça permettrait d’avoir de la mémoire protégée si toutes les applications utilisaient ça, ce qui n’est pas possible vu le design d’amigaos si on désire conserver la compatibilité (les message ne sont pas copiés etc…). Donc cet appel protège tout au plus cette zone mémoire (et encore, faut voir), mais au final ça n’aide pas beaucoup vu que tout le reste du système n’adopte pas ça.

Sur MorphOS, il n’y a pas d’appel (public) similaire, puisque ça n’apporterait rien. En revanche, le noyau et le code des applis est protégé, on peut définir à partir de combien d’accès illégaux une appli se fait suspendre etc… Mais ce n’est en aucun cas une protection mémoire complète (il en est de même sur OS4).

[Alex]

Alex

#104776

Ce que dit Fab est tout à fait vrai, mais je veux juste rajouter qu’en effet sous OS4 (tout comme sous MOS) le mécanisme n’est pas une protection mémoire complète au sens où on l’entend sur les autres systèmes (i.e. avec séparation d’espace d’adressage), en revanche comme sous MOS le code des applis, ainsi que le noyau, sont protégés en mémoire en plus certaines données internes aux applications le sont aussi…

Contrairement à Fab en revanche je ne dirais pas que le flag MEMF_PRIVATE ne sert à rien, au contraire à mon avis ça ajoute un peu plus de stabilité en évitant les écrasements de mémoire involontaires, c’est un outils supplémentaire à la protection du noyau et du code des applis…

[henes]

henes

#104777

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

[eye]

eye

#104778

peux tu preciser stp ce que tu veux dire quand tu dis : « Le code des applis n’est pas protégé » ? Laisses tu entendre qu’un allocmem avec MEMF_PRIVATE ne garanti pas qu’une autre application puisse acceder à cet espace memoire?

[Alex]

Alex

#104779

Dommage que ça parte en flames, jusque là il ne s’agissait pas de dire X est mieux que Y, ou Z fait plus de truc que A. Juste de répondre à la question posée, Fab a très bien répondu, j’ai juste rajouté un petit plus à propos d’OS4 (dont il parlait lui-même) sans émettre aucun jugement de valeur ni sur OS4 ni sur MOS !!!

M’enfin bon tant pis…

[leo]

leo

#104780

Sur MorphOS, il n’y a pas d’appel (public) similaire, puisque ça n’apporterait rien. En revanche, le noyau et le code des applis est protégé, on peut définir à partir de combien d’accès illégaux une appli se fait suspendre etc…

Qu’est-ce qui est considéré comme un accès « illégal » ? Seulement NULL ? Autre ?

Comment on modifie ce nombre ?

[henes]

henes

#104781

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…

[Tcheko]

Tcheko

#104782

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.

[leo]

leo

#104783

@Henes: ca fait surtout 4 ans que j’ai rien touché.. Et non, je connais pas la doc de Enforcer par coeur.

Et donc: comment on fait pour qu’une application se fasse suspendre lors d’un unique hit ?

[Fab1]

Fab1

#104784

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.

[henes]

henes

#104785

@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…

[eye]

eye

#104786

@henes : pardon d’interrompre le fil du post mais, peux tu preciser stp ce que tu veux dire quand tu dis : « Le code des applis n’est pas protégé » ? Laisses tu entendre qu’un allocmem avec MEMF_PRIVATE ne garanti pas qu’une autre application puisse acceder à cet espace memoire sur OS4? ou veux tu simplement dire que comme il n’y a pas de MEMF_PRIVATE (sur MOS), le code des appli n’est pas protégé?

[henes]

henes

#104787

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é »