« Fonctionnement d'un ordinateur/Les jeux d'instructions » : différence entre les versions
Contenu supprimé Contenu ajouté
Ligne 197 :
En regardant dans les langages de programmation un peu plus connus, on peut aussi citer des processeurs spécialisés pour Java. Certains processeurs ARM, qu'on trouve dans des système embarqués, sont de ce type. Mais ceux-ci sont un petit peu à part et ne sont pas vraiment des architectures dédiées. En réalité, ces processeurs sont une implémentation matérielle de la machine virtuelle Java. Rappelons que la machine virtuelle JAVA est un design de processeur comme un autre, avec un jeu d'instruction simple, une architecture à pile, etc. Le code machine associé à cette architecture est appelé le ''bytecode'' Java. En temps normal, le ''bytecode'' Java n'est pas exécuté directement par le processeur, qui utilise un langage machine différent. A la place, le ''bytecode'' est traduit dans le langage machine adéquat, par un interpréteur/compilateur. c'est ce qui permet au ''bytecode'' Java d'être portable sur des architectures différentes. En fait, le ''bytecode'' Java est utilisé comme intermédiaire : on compile du code Java en ''bytecode'' Java, qui est traduit sur l'architecture cible quand on en a besoin. Les architectures Java permettent de se passer de l'étape de traduction ''bytecode'' -> langage machine, vu que eur langage machine est le ''bytecode'' Java lui-même.
===Les architectures à capabilités===
D'autres processeurs incorporent des méthodes qui permettent d’améliorer la sureté de fonctionnement ou la sécurité. Elles permettent d'éviter certaines attaques logicielles, comme des virus ou des accès non autorisés directement en matériel. Ces jeux d'instructions sont conçus en synergie avec certains systèmes d'exploitation. Sur les '''architectures à capacités''', chaque adresse utilisée par un morceau de code se voit attribuer des autorisations d'accès, qui peuvent varier. Par exemple, le code d'un système d'exploitation aura accès en écriture à certaines adresses critiques, qui contiennent des paramètres de sécurité critique, mais les autres programmes n'y auront accès qu'en lecture (voire pas du tout). Les droits d'accès ne seront pas les mêmes, et les capacités différentes (parfois pour une même adresse). Ces droits d'accès sont rassemblés dans une suite de bits, que l'on appelle une capability, ou capacité. Celles-ci décrivent :
* quels sont les droits d'accès en lecture et écriture : lecture seule, pas de lecture ou écriture possible, et ainsi de suite ;
* à quelle zone de mémoire correspondent ces autorisations : il faut indiquer l'adresse de base et la longueur (nombre de mots mémoire) ;
* et sur certaines architectures, quel est le type de la donnée.
Les instructions de lecture et écriture prennent comme argument une adresse et une capacité. Pour avoir accès à une adresse, le programme doit fournir automatiquement la capacité qui va avec : il doit la charger dans des registres spécialisés. Ces capacités sont mémorisées dans la mémoire RAM : chaque programme ou fonction a accès à une liste de capacités en mémoire RAM. Les instructions qui manipulent les registres de capacités ne peuvent pas, par construction, augmenter les droits d'accès d'une capacité : ils peuvent retirer des droits, pas en ajouter. Ce mécanisme interdit donc à tout sous-programme ou programme de modifier une adresse qui n'est pas dans sa liste de capacité : le programme ne pourra pas récupérer la capacité, et n'aura pas accès à l'adresse voulue. Avec ce genre de mécanismes, il devient difficile d’exécuter certains types d'attaques, ce qui est un gage de sureté de fonctionnement indéniable. Du moins, c'est la théorie : tout repose sur l'intégrité des listes de capability : si on peut modifier celles-ci, alors il devient facile de pouvoir accéder à des objets auxquels on n’aurait pas eu droit.
<noinclude>
| |||