Le 386 ne gère que 4 segments. En général, dés qu'une ressource hardware est nécessaire en nombre, si on ne peut pas masquer le nombre réduit, on ne finit par ne plus l'utiliser. Il y a eu des sémaphores hardware, en plus de la pagination ou des ring d’exécution.
_
Je suis plutôt d'accord, si un processus pouvait avoir plusieurs espaces d'adresses virtuelle interne, on pourrait avoir une protection matérielle des tableaux sans la complexité des segments._
Non, on ne pourrait pas. Le nombre de tableau serait toujours potentiellement plus grand que le nombre d'espace d'adressage que pourrait gérer un cpu. De plus, le changement d'espace d'adressage aurai un coup à l’exécution non négligeable.
Si ton but est de protégé l'index d'un tableau, cela serait beaucoup plus facile d'avoir une instruction de test entre l'index et la taille maximum, avant un accès mémoire qui génère un trap en cas de débordement.
[^] # Re: SMEP et la segmentation
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 4.
Le 386 ne gère que 4 segments. En général, dés qu'une ressource hardware est nécessaire en nombre, si on ne peut pas masquer le nombre réduit, on ne finit par ne plus l'utiliser. Il y a eu des sémaphores hardware, en plus de la pagination ou des ring d’exécution.
_
Je suis plutôt d'accord, si un processus pouvait avoir plusieurs espaces d'adresses virtuelle interne, on pourrait avoir une protection matérielle des tableaux sans la complexité des segments._
Non, on ne pourrait pas. Le nombre de tableau serait toujours potentiellement plus grand que le nombre d'espace d'adressage que pourrait gérer un cpu. De plus, le changement d'espace d'adressage aurai un coup à l’exécution non négligeable.
Si ton but est de protégé l'index d'un tableau, cela serait beaucoup plus facile d'avoir une instruction de test entre l'index et la taille maximum, avant un accès mémoire qui génère un trap en cas de débordement.
"La première sécurité est la liberté"