protection mémoire

15 sujets de 1 à 15 (sur un total de 138)

orange_road
4 avril 2007 à 8h44 #4566
question de novice:

je vais regulierement “fleurir” une reflexion sur les amiga NG en disant “c’est nul il y a pas de protection mémoire”.

Qu’est ce que cela veut dire et qu’est ce que cela engendre ?

merci d’avance et ne me taper pas dessus pour cette question bete
adrenochrome
4 avril 2007 à 9h39 #80113
pour notre systeme cela rajouterai de la lenteur, et cela ouvrirai la porte a plein de developpements buggés que les certaines personnes utiliseraient puisqu’il n’auraient pas a rebooter a chaque plantage, on pourrait egalement etendre ca a plein de generateurs de codes divers et buggés

bref pour moi cela signifierai l’ouverture de la porte de la decharge (un peu comme toutes les poubelles que l’on trouve sur le web et qui continuent d’exister grace a des brouteurs trop permissifs et des cpu amphetamines)
seg
4 avril 2007 à 11h03 #80114
Tout est relatif.

D’un point de vue developpeur rigoureux, la protection memoire est plus un garde fou pour les developpeurs foireux.

C’est parce qu’en general, la protection memoire est associee au “resource tracking”, un mecanisme qui consiste au final a restituer les ressources allouees par une application qui vient de se fermer, dans le cas ou elle ne l’aurait pas fait d’elle meme, c’est-a-dire dans le cas ou le developpeur ne maitrise pas un pete de ce qu’il a construit (j’exagere un peu mais parfois, il y en a qui en arrivent la).

Il y a plusieurs niveaux de protection memoire mais, de nos jours, elle consiste a verrouiller en lecture les sections de code d’une meme application pour qu’elle ne se flingue pas elle meme, et interdire completement ces memes sections de code, y compris les sections de donnees aux autres applications pour qu’elles ne sachent pas avec qui/quoi elles cohabitent. En gros, chaque application a l’impression d’etre toute seule dans son environnement.

Elles ont l’impression d’etre toute seule parce qu’il y a un mecanisme mmu (l’unite cpu meme qui se charge des verrouillages de section de code/donnee) qui consiste a “remapper” les adresses memoire, et les applications n’y voient que du feu… Un exemple: Deux applications peuvent virtuellement fonctionner a la meme adresse memoire, mais physiquement, elles sont bien separees; c’est la mmu qui fait son travail.

Tout ce micmac de protection/remappage pose un probleme de temps car, le cpu a beau offrir des fonctionnalites interessantes pour y arriver, ca lui coute quand meme quelque chose a chaque fois qu’il switch de tache ou qu’il se sert d’un autre mecanisme lie encore a la mmu; la fameuse memoire virtuelle.

Il y en a qui doivent se dire que tout ca est gravé dans le silicium et que y a surement rien a faire: ben non, les fonctions apportees par les unites mmu ne permettent, au final, que d’automatiser des appels (ou sauts) a des routines qui se chargent de reparametrer la mmu comme il le faut a l’instant T. Apres, les sacrifices de temps dependent des strategies mmu adoptees.

Mais bon, les unix, les windows, les macos etc… emploient tous ces mecanismes. Le probleme n’est pas de l’implementer sur nos chers ppc (voire les 68k pour les resistants comme moi), mais de le faire cohabiter avec un environnement qui n’a jamais ete architecturé pour, ce qui pourrait rendre toute l’historique des applications existantes incompatible avec cette nouvelle couche systeme.

En la matiere, tout est pourtant possible… a raison d’un effort de travail et d’imagination relativement important, mais aussi passionnant!

D’un point de vue utilisateur maintenant, la protection memoire est indispensable parce que, en depis du nombre de developpeurs rigoureux qu’il nous reste, on a quand meme un beau parc de developpeurs incapables de creer une application sans faille, qui pensent aussi que la gestion memoire ne doit pas etre leur affaire… Ca, c’est un debat qui mene au fight.

En conclusion, oui la protection memoire et le resource tracking sont interessants! Si seulement certains developpeurs ne se reposaient pas la dessus pour compenser leur manque de rigueur…

a+
leo
4 avril 2007 à 11h48 #80115
Pour résumer, et essayer de faire simple (et neutre: pas question de dire que c’est plus mieux, ou plus moins bien…):

Actuellement, n’importe quel programme a accès à toute la mémoire de l’Amiga. Quand un programme dit: “je veux avoir accès à tant de mémoire”, le système lui dit: “ok, voila, on t’as réservé ta mémoire, ici: [adresse de sa zone1]”

Il est fort possible qu’un deuxième programme dise aussi: “ok, moi je voudrai aussi avoir tant de mémoire”. Là imaginons que le système lui dise “ok”, et lui donne l’adresse juste après la zone mémoire réservée par le 1er programme. On se retrouve avec:

[…mémoire….][zone mémoire réservée par le programme 1][zone mémoire réservée par le programme 2][…fin mémoire…]

Maintenant, qu’est-ce qui se passe si le programme 1 est buggé, et “dépasse” de sa zone ? Bein il va tout simplement écraser une partie de la zone mémoire du programme 2. Résultat: le programme 2 se retrouve, sans le savoir, avec des données complètement aléatoires dans sa mémoire réservée. Donc il a de grandes chances de crasher.

Maintenant imaginez que le programme 2 c’est une librairie importante du système d’exploitation. Et que le programme 1 est un petit programme x. Ce qui se passe (dans le pire des cas biensur), c’est que le petit bug du programme x va entraîner un crash de la librairie, donc un blocage possible de tout le système.

Tous les AmigaOS fonctionnent en gros de cette manière: n’importe quel programme peut accéder à n’importe quelle zone mémoire (les puristes me diront que MorphOS protège certaines zones mémoires, mais bon: ca reste limité…).

Maintenant, avec un système avec protection mémoire, ce qui se passe, c’est que quand un programme 1 demande un peu de mémoire, le système lui dit “ok, voila, c’est à l’adresse 1”. Le programme 2 fait de même. Le système lui dit “ok, voila, c’est à l’adresse 2”. Maintenant, si on tombe dans le même cas, à savoir que le méchant programme 1 dépasse de son tableau, c’est là qu’intervient la protection mémoire. Le système va interdire le programme de sortir de sa zone. Alors: ca n’empêchera pas évidemment le programme 1 de planter parce qu’il est buggé (personne n’a dit que c’était le cas). Mais on est sur que le programme 2 aura sa zone mémoire intacte, et ne crashera donc pas à cause du bug du programme x.

Voila en gros ce qu’apporte la protection mémoire. C’est en réalité beaucoup plus complexe que ca. Mais mon but est juste d’en montrer le principe, et ce que ca peut apporter. Pas de d’en détailler le fonctionnement.

Et, pour info, tous les Unix (que ce soit Linux, Unix, MacOSX,…), et Windows (depuis NT) fonctionnent de cette manière. Si vous avez déjà vu un “segfault” sur un Unix, il y a de grandes chances que ce soit un problème de ce genre en fait. De même, si vous êtes tombés sur l’erreur Windows “Le programme va être arrêté, erreur: la zone mémoire 0x1155454 ne peut être written”, c’est aussi la même chose.

Voili, voila.

J’espère que ca t’éclairera. Et à toi de voir si au final c’est mieux, ou moins bien… Moi j’ai mon avis.

@+,

Léo.

—

PS: et pour expliquer le resource_tracking, un autre principe que l’on retrouve dans les systèmes modernes… Si on reprend le cas précédent. Et qu’on imagine que le programme 1 a alloué beaucoup de mémoire, alloué des canaux audio, et ouvert 3 fenêtres. S’il crash, et bein ca mémoire reste “allouée”, sa fenêtre ouverte, et ses canaux audios alloués. Maintenant, sur un système avec “resource_tracking”, le système garde une trace de toutes les resources allouées par un programme x. Ce qui fait que si un programme x crash, le système peut le “tuer” proprement, et libérer toutes les resources que celui ci avait alloué, fermer les fenêtres qu’il avait ouvertes,…
sinisrus
4 avril 2007 à 12h47 #80116
ce que je ne comprend pas c’est pourquoi les dev (os4.0, morphos) ne font-il pas une protection mémoire total du system (que l’on puisque activer ou désactiver) de façon à gader la comptatibilitée et aussi évoluer il suffirai juste de rebouté pour passé d’un mode à l’autre. mais je pense que cela est bien plus compliqué
Alex
4 avril 2007 à 12h51 #80117
On est quand même marrants nous les amigaïstes :

dans un certain AmigaOS NG il existe un certain niveau de protection mémoire, qui permet de vérouiller tous les segments mémoire contenant du code, ainsi que certaines zones mémoire contenant des données (les données statiques par exemple ou via un flag au moment de l’allocation mémoire), du coup certains anciens programmes (programmés par des programmeurs plus intelligents que les autres) qui tiraient partis du fait que la mémoire était partagée entre les processus en tapant joyeusement dans des zones qu’ils n’avaient pas allouées eux-mêmes, ou encore continuaient d’accéder à des zones libérées) du coup ces programmes ne marchent plus (normal me direz vous) !! Et bien justement on lui reprochee son “manque” de compatibilité avec les vieux softs 68k !!!

M’enfin bon être compatible avec des vielles applis foireuses vaut-il le coup de ne pas aller de l’avant ?

PS: j’en vois certains qui vont me dire “c’est pas de la vraie protection mémoire”, je suis désolé mais personne n’a dit que la seule façon de faire de la protection mémoire c’était d’avoir un espace d’adressage séparé !!
Mod
Tcheko
4 avril 2007 à 13h42 #80118
PS: j’en vois certains qui vont me dire “c’est pas de la vraie protection mémoire”, je suis désolé mais personne n’a dit que la seule façon de faire de la protection mémoire c’était d’avoir un espace d’adressage séparé !!

Raaa l’autre, c’est pas de la vraie protection mémoire!

Est ce que MOS/AOS4 utilisent le mmu pour placer la mémoire contenant du code en lecture seule ?

++
adrenochrome
4 avril 2007 à 13h53 #80119
faudrait plutot penser la question dans l’autre sens, “quelles nouvelles appli tellement foireuses qu’elles requierent une protection memoire souhaite-tu ?”
Fab1
4 avril 2007 à 13h57 #80120
Alex,

ce que tu décris existe dans morphos depuis euhh, 2000 ? Et ça n’a rien d’une protection efficace que de protéger le code et les données statiques, qui statistiquement ne se font jamais exploser.

Et sinon c’est complètement crétin de faire une mémoire protégée sans adressage séparé, ça enlève d’énormes avantages comme :

– la pile qui n’est alors plus limitée que par la mémoire disponible (c’est mieux qu’un concept débile de pile autodépliante avec une redzone dont krabob a voulu faire une pub éhontée il y a quelques années et qui d’ailleurs n’est pas implémenté au final, puisque les gens tapent toujours frénétiquement stack 99999999999999999 dans un shell parce que leurs développeurs ne savent toujours pas régler eux-mêmes la taille de la pile nécessaire à leur propre application).

– l’espace d’adressage de ~4Go par application, ce qui est d’autant plus utile lorsqu’on s’amuse à implémenter des fonctions comme mmap() qui généralement s’utilise avec des gros fichiers, qui peuvent rapidement remplir les 4Go entre toutes les applications si l’espace d’adressage est partagé.

Donc oui, il y’a 36 façons de faire une protection mémoire bancale, mais il n’y en a pas 36 pour en faire une qui marche vraiment.
seg
4 avril 2007 à 13h59 #80121
Bah en fait, il y a un debat cache entre les partisants de la dites “vraie protection memoire” et ceux qui essaient de faire de la “protection memoire” hybride.

On s’inspire tous sur ce qui existe sur les autres systemes, et le principe adopte sur les Unix reste le modele principal.

Pour etre bref, si l’on essaie de suivre le modele Unix (et celui de tous ceux qui l’ont suivi), le travail est important. C’est d’autant plus important qu’AmigaOS4 n’est pas parti sur des bases a la Unix pour gerer cette soit disante “vraie protection memoire”. Or, ils auraient pu partir de la transition PPC pour le faire puisque, de toute maniere, il fallait ajouter une couche d’emulation 68k qui aurait pu s’etendre a une couche d’emulation des interfaces systemes.

Sur OS4, ils se sont contentes d’un systeme hybride apportant une protection memoire dans un environnement a memoire partage. C’est pas 100% securise mais c’est un degre de protection interessant a prendre quand on n’a rien d’autre. Les sections de code ne sont pas trashables au moins… Pour ce qui est du resource tracking, j’ai cru lire des infos qui semblaient en faire part mais, en realite, je ne vois pas comment ils auraient pu integrer ca sans revoir un paquet de trucs. Au pire, il s’agit la encore d’un systeme hybride qui a le merite d’exister.

Donc, s’il faut ajouter la “vraie protection memoire”, il va falloir tenir compte de l’architechture actuelle, et pourquoi pas de celle des systemes 3.x des 68k pour rester compatible.

Comme je le disais avant, tout est possible du moment qu’on s’en donne les moyens et que l’on assume des choix.

Maintenant, pourquoi ne pas se contenter d’un systeme hybride, et pourquoi vouloir a tout prix un systeme a la Unix? Ben, de mon point de vue, il faut quand meme admettre que la facon Unix est la meilleure de toutes celles qui nous sont proposees. Deja, elle nous permettrait d’implementer un fork(), chose qui est impossible a ce jour Mais bon ca, ca interesse qui voudra! Mais rien que ce detail devrait faire tilt.

Je ne suis pas alle loin d’en la lecture des possibilites de MorphOS mais, il semblerait que celui-ci ait fait le bon choix en adoptant un principe de “boites”. Le systeme est en fait represente par le micro kernel “Quark” et l’AmigaOS like est une sorte de tache sous Quark. J’ai lu a l’epoque (il y a 6 ou 7 ans peut-etre) que celui-ci savait gerer la memoire facon Unix.

En gros, il suffirait de batir un systeme dans l’esprit Amiga autour de Quark, tout comme on a un systeme complet autour d’exec aujourd’hui.

Mais alors comment faire cohabiter l’environnement graphique Amiga Like qu’on a avec MorphOS et celui potentiellement implementable autour de Quark? Et encore, il ne s’agit ici qu’une question portee sur la partie visible de l’Iceberg.

C’est bien beau de dire “on veut pas rester compatible, il faut partir de Quark, etc” mais si l’on part de rien, ca va etre la misere pendant un sacre bout de temps. Donc, il faut une transition soft, fiable, qui fait pas rustine… et pour reflechir a ca et resoudre les plus petits details, il va falloir griller un paquet de neurones.

Perso, pour l’AmigaOS, je ne peux imaginer une protection memoire qu’a la Unix, avec un environnement memoire virtuel. Mais le probleme, sur Amiga, c’est qu’en multitache, il y a des notions de messages; les taches doivent pouvoir communiquer entre elles. Or tout fonctionne par pointeur sous AmigaOS et non par Id. Et les pointeurs, dans un environnement a memoire virtuelle, ca ne veut pas dire grand chose. Bon, si on reste dans un thread, ca va, puisque la memoire est partagee; mais dans un process, il va falloir inventer un autre systeme de message…

Allez, je vais pas rentrer dans le details tout en essayant de rester le moins technique possible sinon mon post va ressembler un rien du tout.

a+
leo
4 avril 2007 à 14h32 #80122
Mais alors comment faire cohabiter l’environnement graphique Amiga Like qu’on a avec MorphOS et celui potentiellement implementable autour de Quark? Et encore, il ne s’agit ici qu’une question portee sur la partie visible de l’Iceberg.

C’est bien beau de dire “on veut pas rester compatible, il faut partir de Quark, etc” mais si l’on part de rien, ca va etre la misere pendant un sacre bout de temps. Donc, il faut une transition soft, fiable, qui fait pas rustine… et pour reflechir a ca et resoudre les plus petits details, il va falloir griller un paquet de neurones.

MorphOS a pris la même approche que Apple avec MacOSX. Seulement là on s’est arrêté en chemin… Donc, pour continuer, bein on le fera cohabiter tout comme MacOSX faisait cohabiter MacOS 9…

Et je dis bien “faisait”. Apple a stoppé tout développement de MacOS 9 en 2001. Et depuis 2006 (et les premiers Mac Intel), il n’y a même plus de compatibilité OS9 sur MacOSX…

@+,

Léo.
Alex
4 avril 2007 à 14h51 #80123
@Tcheko

Je crois bien que oui, mais en vérité est-ce réellement important de connaître le détail d’implémentation (même si j’en conviens ce serait un peu idiot de ne pas utiliser la possibilité de la mmu…).

@Fab1

J’avais pas donné de nom exprès pour éviter de tomber dans des flames… Mais bon puisque tu donnes des noms, effectivement je pensais à AmigaOS 4, mais pas pour dénigrer MorphOS (comme tu le fais joyeusement avec AOS4), mais simplement parce que je préfère parler de ce que je connais (même si je n’ai pas la prétention de connaître le fonctionnement interne d’AOS4 en détails) et que AOS4 je connais, pas MOS (enfin sauf ce que j’ai lu ici ou là, mais de mon point de vue ça ne compte pas). Bref tout ça pour dire que j’ai pas dit que MOS n’avait pas ceci ou cela, juste j’en ai pas parlé parce que je ne savais pas, après sur le reste de ton post je ne commenterais pas les attaques gratuites contre des développeurs qui ne t’ont rien fait (et faut pas généraliser, y a aussi des gros porcs qui codent sous MOS, c’est pas une exclue AOS4… Comme partout d’ailleurs, ce n’est pas pour autant que c’est le cas de tout le monde !). Ceci dit juste deux points : 1) y a moyen de protéger la mémoire que l’on alloue même si ce n’est pas des segments de code ou des données statiques, 2) mince pour mmap je voulais l’utiliser sur une image de DVD qui fait 4 GO comment je vais faire ?? En plus c’est bête, mais j’ai que 2GO de RAM, donc je vais mapper un fichier en mémoir qui va être swappée…. sur disque

@seg

C’est pas 100% securise mais c’est un degre de protection interessant a prendre quand on n’a rien d’autre.

Surtout quand on se rend compte du nombre d’anciennes applis qui tout à coup ne tournent plus parce qu’elles accèdent à des adresses auxquelles elles n’ont pas droit…

Pour ce qui est du resource tracking, j’ai cru lire des infos qui semblaient en faire part mais, en realite, je ne vois pas comment ils auraient pu integrer ca sans revoir un paquet de trucs. Au pire, il s’agit la encore d’un systeme hybride qui a le merite d’exister.

En effet il y a un système de ressource tracking, mais il n’est pas activé par défaut, le programmeur *doit* le spécifier pour l’avoir. Et ce pour une raison principale un programme 1 plante, le système libère son port de message associé… Mince un programme 2 qui parlait avec lui d’un seul coup se retrouve avec un port de message qui n’existe plus et se met à planter 😮 alors qu’en fait même si le programme 1 n’était plus là ça n’empêchait pas le programme 2 de tourner….
Fab1
4 avril 2007 à 14h59 #80124
Modération de BatteMan : Troll.
Alex
4 avril 2007 à 15h33 #80125
Modération de BatteMan : Réponse à un troll.
breed
4 avril 2007 à 17h35 #80126
Modération de Breed : Réponseà une réponse trollesque à un troll.