SYSTEME ET PROCEDE POUR LA PROTECTION D'UN ENVIRONNEMENT INFORMATIQUE D'EXECUTION SECURISE

La présente invention concerne le domaine de la gestion de mémoires informatiques et se rapporte plus particulièrement à un système et un procédé pour sécuriser les tables de translations stockées dans une mémoire externe à un module de processeur sécurisé.

Dans certains appareils digitaux de très haute sécurité, par exemple des terminaux de paiement, une partie des informations sensibles utilisées pendant leur fonctionnement sont, afin d'en garantir la sécurité, stockées dans une ou des mémoires internes au circuit contenant le processeur en fonction. De tels circuits comprennent une puce de silicium miniaturisée ou un ensemble de telles puces collées entre-elles, ou sur un même support. Il est important de noter que la miniaturisation des interconnexions à l'intérieur d'un tel circuit rend l'observation et l'altération des signaux qui y sont véhiculés difficile et donc onéreuse. Il est donc efficace de garder, à l'intérieur d'un même circuit, ci-après nommé circuit, circuit de processeur ou circuit sécurisé, les informations sensibles. Une réalisation de ces circuits sécurisés peut être encapsulée dans un boîtier de protection, par exemple une réalisation sous forme de puce électronique ("chip").

En effet, si les informations sensibles étaient stockées sur une mémoire externe à ce circuit, par exemple sur une mémoire vive dynamique DRAM (Dynamique Random Access Memory) de la carte électronique de l'appareil, elles pourraient être divulguées ou modifiées frauduleusement par l'observation et/ou l'altération des signaux véhiculés par les pistes électriques reliant le circuit du processeur aux circuits de la mémoire externe, lesquelles pistes électriques sont dans ce cas facilement accessibles.

On recherche donc, autant que possible, à conserver, dans les mémoires internes du circuit de processeur, un maximum de données sensibles.

Néanmoins, la taille, en surface et octets, de la mémoire interne dont on dispose à l'intérieur du circuit accueillant un processeur est limitée. Les systèmes actuels comprennent donc à la fois une mémoire interne sécurisée dans le circuit et une mémoire externe de capacité plus importe reliée à ce circuit sécurisé.

De façon plus détaillée, un circuit sécurisé de processeur contient en général un certain nombre de macroblocs logiques. Le concepteur d'un tel circuit utilise en général, et donc achète, des macroblocs logiques préconçus pour réaliser une partie du circuit, par exemple un modèle de processeur. Il développe en parallèle d'autres macroblocs logiques spécialisés, pour l'autre partie du circuit.

Du fait de sa complexité, le macrobloc logique processeur, le "processeur" dans la suite du document, est en général préconçu et fourni par des fournisseurs de solutions spécialisées dans le domaine des processeurs, par exemple les sociétés ARM Ltd ou MlPS Technology (noms commerciaux).

Dans un système comprenant un circuit sécurisé de processeur et une mémoire externe connectée, par exemple un terminal de paiement tel que mentionné ci-dessus, deux univers logiciels (ou environnements d'exécution) exécutés sur le même processeur coexistent généralement :

- d'un côté, un univers sécurisé s'appuyant sur, outre le processeur, les mémoires et périphériques internes au circuit sécurisé. Cet environnement est très sensible et ne doit jamais être compromis, en particulier lorsque la mémoire externe (qui ne le concerne pas) est altérée ;

- d'un autre côté, un univers moins sécurisé pour lequel il est moins dommageable et donc acceptable que ses fonctionnalités puissent être compromises, entre autres, par la modification du contenu de la mémoire externe, par exemple au travers de l'interception de signaux par une personne malintentionnée. L'univers moins sécurisé comprend, outre la mémoire externe, des périphériques externes et éventuellement certains mémoires ou périphériques internes au circuit, non partagés avec ceux de l'univers sécurisé.

Que ce soit lors de l'exécution de l'environnement sécurisé ou de l'environnement moins sécurisé, le processeur s'appuie sur une unité de gestion de mémoire (MMU - Memory Management Unit) pour déterminer les adresses mémoires de données ou d'instructions, notamment par la translation d'adresses. Une translation fournit, pour un contexte d'exécution donné, l'adresse physique correspondant à l'adresse virtuelle (ou logique) émise par une application exécutée. L'unité MMU comprend notamment une mémoire cache, également nommée TLB {Translation Look-aside Buffer), contenant les translations les plus récentes entre adresse virtuelle et adresse physique.

Sur certaines architectures de processeurs, MIPS (nom commercial) par exemple, ce cache de translations est rempli par l'exécution d'une routine logicielle.

Sur d'autres architectures de processeurs, par exemple ARM ou Intel (noms commerciaux), ce cache de translation est rempli automatiquement par un mécanisme matériel. Ce mécanisme, qui fait partie intégrante du processeur, est habituellement nommé un "Hardware page Table Walker", également désigné, dans la suite, par l'acronyme HTW.

Le HTW exploite une base de données de tables de translations présente en mémoire. Cette base de données, dont l'architecture interne peut être plus ou moins complexe, a pour finalité de fournir au

HTW, lorsque celui-ci la consulte, des descripteurs de translation permettant directement ou indirectement de déterminer l'adresse physique associé à une adresse virtuelle. La base de données peut combiner des descripteurs de translation terminaux qui associent une adresse de page virtuelle à une adresse de page physique, et des descripteurs de table de translations qui associent à une plage d'adresses de pages virtuelles une nouvelle table (par une adresse physique) de la base de données comprenant d'autres descripteurs de translation. Il peut en résulter une arborescence de tables. Ces descripteurs de translations sont utilisés par le HTW pour déterminer de nouvelles translations non présentes dans le cache de translation TLB et mettre à jour, le cas échéant, ce dernier. La mise à jour de cette base de données est effectuée sous la responsabilité du système d'exploitation ou d'un logiciel de virtualisation (hyperviseur) lorsque cette technologie est utilisée.

Pour la suite de l'exposé, on suppose que le mécanisme HTW parcourt cette base de données en utilisant des adresses physiques uniquement et non des adresses virtuelles, car autrement il pourrait être confronté à des recherches récursives (car des adresses virtuelles auraient elles- mêmes à être translatées et pourraient donc potentiellement lancer de nouveaux parcours de la base de données par le HTW). Cependant l'homme de l'art n'aura aucun mal à étendre l'exposé de l'invention qui suit dans le cas où, si le mécanisme HTW le supporte, ces accès se font en utilisant des adresses virtuelles.

La mémoire externe étant beaucoup plus grande que la mémoire interne, l'univers moins sécurisé est beaucoup plus grand que l'univers sécurisé. Aussi, la majorité de la base de données de translations concerne l'univers moins sécurisé. Pour des raisons évidentes de place mémoire, il convient donc de placer la partie de la base de données de

translations concernant seulement l'univers moins sécurisé, dans une mémoire externe au circuit sécurisé du processeur.

La présente invention concerne les processeurs dotés d'un mécanisme HTW et concerne plus particulièrement un système pour la protection d'un environnement informatique d'exécution sécurisé, comprenant un circuit sécurisé de processeur, au moins une ressource définissant un premier univers non sécurisé, ladite ressource comprenant une mémoire externe connectée audit circuit sécurisé, ladite mémoire externe comprenant une pluralité de descripteurs de translation (partie de la base de données de translations) agencée pour associer des adresses virtuelles à des adresses physiques appartenant à l'univers moins sécurisé, c'est-à-dire désignant une ressource de cet univers, ledit circuit sécurisé de processeur comprenant au moins une ressource interne (généralement une mémoire interne et éventuellement d'autres ressources internes) et un processeur pour l'exécution d'au moins une application, ladite au moins une ressource interne définissant un deuxième univers sécurisé, le processeur comprenant un mécanisme matériel HTW agencé pour émettre au moins une requête (ou accès) en lecture d'un ou plusieurs descripteurs de translation stocké en mémoire externe, lorsque l'exécution d'une application émet une adresse virtuelle. De telles requêtes sont généralement émises lorsque la translation demandée n'est pas présente dans le cache TLB de la MMU.

En pratique le HTW émet des requêtes en lecture jusqu'à ce qu'il obtienne un descripteur de translation terminal. Les premières requêtes permettent de parcourir la base de données de translations via des descripteurs de tables et la dernière requête fournit un descripteur de terminal comprenant l'adresse physique de translation recherchée. Ce descripteur permet de mettre à jour le cache de translation TLB de l'unité de gestion mémoire MMU, quand celle-ci doit translater une adresse virtuelle, émise par l'application en cours d'exécution, en une

adresse physique, et que le descripteur de translation terminal correspondant, ou son équivalent, n'est pas présent dans son cache de translation TLB.

La base de données de translations placée en mémoire externe et utilisée par un système d'exploitation de l'univers moins sécurisé pour spécifier l'adressage et l'utilisation de la mémoire physique des applications qu'il exécute, peut être, de par son emplacement externe et en cas de mauvaise intention, modifiée de telle sorte que ces applications se trouvent avoir accès à des plages d'adresses physiques de l'univers sécurisé. Un tel accès est préjudiciable en ce qu'il risque d'altérer l'intégrité de l'environnement sécurisé.

La solution qui consiste à placer cette base de données en mémoire interne sécurisée n'apparaît pas opportune pour les raisons mentionnées ci-dessus (ressources de stockage interne limitées).

Une solution à ce problème est proposée par le brevet US-7, 124,274 qui concerne un système tel que présenté ci-dessus dans lequel le HTW du processeur dispose de deux registres, un premier attribué à l'univers sécurisé et pointant vers une base de données de translations dite « sécurisée », et un deuxième attribué à l'univers moins sécurisé et pointant vers une deuxième base de données de translations dite « non sécurisée ». Chaque base de données comprend les translations associées à l'univers correspondant. Le processeur bascule d'un registre à l'autre lorsqu'il exécute des instructions relatives à une application sécurisée ou une application non sécurisée. Ainsi, le mécanisme HTW résout les translations dans un univers ou dans l'autre. Un filtre est cependant appliqué pour détecter lorsqu'un descripteur de translation, retourné par la base de données « non sécurisée », décrit une adresse physique de l'univers sécurisé. Des contre-mesures appropriées sont alors prises.

Néanmoins, cette solution nécessite un certain nombre de modifications des architectures de processeur déjà existantes et, en particulier, la modification du HTW de telle façon qu'il comporte deux registres désignant deux bases de données de translations, le registre couramment utilisé dépendant du fait que le processeur soit dans un mode d'exploitation appartenant au domaine sécurisé ou non. Le mécanisme HTW est également modifié pour détecter l'environnement auquel s'adresse la demande de translation qu'il doit traiter et pour basculer sur le bon registre associé. Ces modifications ne sont disponibles que sur un petit nombre de modèles de processeur, plus coûteux que les modèles de processeur comparables non modifiés.

Un but de l'invention est de fournir une solution au problème ci-dessus sans modifier les modèles de processeurs actuels.

Ainsi, un objectif de l'invention est de permettre au concepteur de circuit mentionné ci-dessus, via la réalisation d'un bloc logique de faible complexité additionnel au bloc processeur, de résoudre le problème particulier de sécurité décrit précédemment, en utilisant pour le circuit sécurisé un modèle de processeur préconçu standard peu onéreux, au lieu de devoir utiliser un modèle de processeur préconçu plus onéreux car possédant des dispositifs particuliers de sécurité.

L'invention atteint ce but par l'utilisation d'un bloc logique intégré au circuit sécurisé, ci-après "moyen de transcodage", et placé pour recevoir les données (les descripteurs de translation) retournées à destination du HTW par la mémoire externe, et éventuellement les modifier avant de les transmettre au HTW.

Ce moyen de transcodage filtre alors les descripteurs de translation reçus de la mémoire externe, et, lorsqu'il détermine que ceux-ci décrivent une adresse physique de l'univers sécurisé, émet une erreur.

A cet effet, l'invention a tout d'abord pour objet un système tel que présenté ci-dessus dans lequel ledit circuit sécurisé de processeur

comprend, en outre, un moyen de transcodage disposé entre ledit processeur et la mémoire externe de sorte à recevoir (ou intercepter) au moins un descripteur de translation en réponse à ladite requête en lecture de la mémoire externe émise par ledit mécanisme HTW (lorsque celui ci consulte la base de donnée de translation), et ledit moyen de transcodage étant agencé pour détecter si ledit descripteur de translation retourné par la mémoire externe associe une adresse virtuelle à une adresse physique de l'univers sécurisé.

Ainsi, les processeurs actuels, disposant d'un mécanisme HTW habituel, ayant un seul registre de désignation de base de données de translations, sont conservés pour fournir le degré de sécurité souhaité. Le moyen de transcodage peut prendre place en tant que relais des requêtes en lecture de la base de données de translations, émises par le mécanisme HTW et filtre les descripteurs de translation qui y sont apportées en réponse. On prévoit alors que ledit moyen de transcodage est également agencé pour recevoir la ou les requête(s) en lecture émise(s) par le HTW, à des fins de synchronisation logique avec le HTW.

En fonction du mode de réalisation du moyen de transcodage, celui-ci peut aussi recevoir les descripteurs de translation reçus de la mémoire interne, à des fins de synchronisation logique avec le HTW.

La réalisation de l'invention ne nécessite pas la modification du modèle préconçu du processeur, modification que le concepteur de circuit ne pourrait en général pas mener à bien, en raison, entre autres, d'obstacles techniques et juridiques.

De la sorte, une protection de l'environnement sécurisée est apportée à tous les modèles de processeur déjà existants.

Puisque la mémoire externe est susceptible d'être corrompue, le moyen de transcodage assure que les descripteurs de translation qui sont retournées spécifient des adresses physiques de l'univers moins sécurisé. Des réponses comportementales peuvent alors être prises en

réponse à cette détection pour garantir une sécurité de l'univers sécurisé. De ce fait, le moyen de transcodage permet de limiter la plage d'adresses physiques qui peuvent être décrites par toute table de translations située dans la mémoire externe.

L'invention empêche, par conséquent, l'accès sans autorisation à l'univers sécurisé, via une adresse virtuelle, dont la translation en adresse physique dépend, même partiellement, d'une table de translations située en mémoire externe susceptible d'être altérée.

Dans un mode de réalisation, il est prévu que ledit moyen de transcodage est apte à générer, suite à ladite détection, une exception informatique afin que le processeur ou le système d'exploitation (éventuellement hyperviseur) prenne les dispositions nécessaires pour garantir l'herméticité de l'environnement sécurisé.

Une exception est un signal émis lors de l'exécution d'une application pour avertir d'une situation exceptionnelle ne correspondant pas à une exécution normale de l'application, et pour laquelle le système d'exploitation, le processeur ou des routines adaptées prend des actions réparatrices.

L'exception est émise aussi bien lorsque l'adresse physique non valide, car appartenant à l'univers sécurisé, est retournée via un descripteur de translation terminal ou via un descripteur de table de translation.

Cette exception informatique peut être réalisée, par exemple, par l'application des règles suivantes :

- si le descripteur de translation fautif est un descripteur de translation terminal, il est modifié de telle sorte qu'il spécifie que l'adresse logique à traduire est invalide, aucune adresse physique n'y étant associée. Ainsi l'exception d'accès invalide est générée. La routine du système d'exploitation OS (ou de l'hyperviseur) associée à cette exception peut alors déterminer si l'invalidité de l'accès résulte de l'action du moyen de transcodage ou non, par exemple en lisant un registre de statut de ce mécanisme de transcodage, le

concepteur du système ayant pris soin de rendre ce registre accessible au processeur en tant que registre périphérique.

- si le descripteur de translation fautif est un descripteur de table de translation, et s'il peut être modifié en un descripteur de translation terminal, alors il est modifié en un descripteur de translation terminal invalide tel que décrit ci-dessus,

- si le descripteur de translation fautif est un descripteur de table de translation, mais qui ne peut pas être modifié en un descripteur de translation terminal car l'accès mémoire du HTW correspond à un niveau hiérarchique de l'arborescence de la base de données de translations où le HTW ne s'attend pas à recevoir de descripteur de translation terminal, alors l'adresse spécifiée par le descripteur fautif est transformée de telle façon qu'elle spécifie une adresse physique valide de la mémoire externe. Un automate d'état du mécanisme de transcodage note qu'il doit signaler une exception, par l'une des deux règles précédemment décrites, dès que l'accès généré par le HTW correspond à un niveau hiérarchique où il est possible de retourner un descripteur de translation terminal invalide.

Si le concepteur du système ne souhaite pas modifier la gestion par l'OS (ou l'hyperviseur) des exceptions, et donc ne pas générer une exception inhabituelle, résultant de l'action du mécanisme de transcodage, il est prévu que, pour assurer la suite de l'exécution de l'application en cours, ledit moyen de transcodage est apte à modifier, suite à ladite détection (c'est-à-dire lorsque l'adresse physique spécifiée par le descripteur de translation désigne l'univers sécurisé), ledit descripteur de translation reçu en spécifiant une adresse physique désignant l'univers moins sécurisé. On s'assure ainsi que la poursuite de l'exécution de l'application ne vient pas lire ou altérer des données de l'univers sécurisé. L'exécution de l'application est désormais corrompue, ce qui est sans importance puisque de toute façon la

mémoire externe est également corrompue. Mais, cela est sans dommage pour l'univers sécurisé.

Dans un mode de réalisation, ladite pluralité de descripteurs de translation est regroupée en une pluralité de tables de translations dans la base de données de translations, lesdites tables de translations étant regroupées en types de tables. Selon le type de la table considérée, une entrée d'une table peut, en fonction éventuellement de la valeur d'un champ binaire de cette entrée, soit contenir un descripteur de translation terminal associant une plage d'adresses virtuelles à une plage d'adresses physiques, soit un descripteur de translation de table décrivant une autre table de la base de données de translations. Un descripteur de table contient, outre d'autres informations éventuelles, l'adresse physique, ou du moins une partie suffisante de celle-ci, de la table qu'il décrit. La base de données de translations peut ainsi être organisée de façon arborescente, notamment sous la forme d'un arbre hiérarchique, lesdits types correspondant aux différents niveaux hiérarchiques.

Le HTW, quand il consulte la base de données, poursuit la recherche dans celle-ci, descendant éventuellement dans les sous-arborescences de la base de données de translations, tant que la donnée lue correspond à un descripteur de table. Seule la lecture d'un descripteur de translation terminal met un terme à la recherche.

L'organisation des tables en types permet notamment d'ajouter une sécurité supplémentaire en vérifiant la compatibilité des adresses spécifiées par les descripteurs de table de translations reçus avec le type de table de translations courant.

Le moyen de transcodage est agencé pour appliquer à l'adresse physique d'un descripteur de translation reçu en réponse à une requête en lecture du HTW, une règle de traitement avant transmission du descripteur de translation reçu au mécanisme matériel HTW, ladite

règle étant fonction dudit type de table de translation contenant ledit descripteur reçu. A cet effet, ledit moyen de transcodage comprend une unité logique stockant, à chaque requête en lecture émise par le HTW, le type associé à la table de translations visée dans la requête. De ce fait, le moyen de transcodage connaît continuellement le type associé à la requête et donc la règle à appliquer à la réponse reçue, si celle-ci provient de la mémoire externe, de telle façon qu'il puisse modifier de façon adéquate le descripteur reçu avant de le transmettre au HTW.

Plusieurs règles applicables sont décrites plus en détail par la suite.

Lorsqu'au moins un descripteur de translation associe une plage d'adresses virtuelles à une autre table de translations en indiquant une adresse physique de ladite autre table, on prévoit que les adresses physiques des tables de translations d'un même type de tables appartiennent à une même plage d'adresses associée audit type, et le moyen de transcodage est alors agencé pour vérifier que ladite adresse physique de table dudit descripteur reçu en réponse à la requête en lecture appartient à la plage d'adresses associée au type de ladite autre table spécifiée par le descripteur reçu, et transmettre, en cas de vérification positive, ledit descripteur de translation reçu audit mécanisme matériel HTW.

Le mécanisme HTW vérifie ainsi à chaque étape du parcours de l'arbre en vue de la résolution d'une translation d'adresse, généralement les arbres de tables de translations comprennent deux à trois niveaux, que les adresses physiques spécifiées par les descripteurs de translation renvoyés sont compatibles avec celles attendues. Lorsque c'est le cas, les descripteurs de translation sont transmis au HTW pour suite à donner, notamment par l'émission d'une nouvelle requête en lecture de la base de données avec l'adresse d'une nouvelle table afin de poursuivre la résolution de l'adresse virtuelle.

Si ce n'est pas le cas (vérification négative), le moyen de transcodage est alors agencé pour modifier le descripteur de translation avant sa transmission au HTW de sorte à:

- transformer ladite adresse physique en une adresse physique valide appartenant à la plage d'adresses associée au type de la table de translation spécifiée par le descripteur de translation reçu, c'est-à- dire que l'adresse que le descripteur retourné spécifie est située dans la plage d'adresses associée au type attendu ; ou

- modifier le type de table de translation spécifié par le descripteur de translation en le type correspondant à la plage d'adresses à laquelle appartient l'adresse physique spécifiée par le descripteur reçu.

Ainsi, en cas de vérification négative, soit le type de la table de translation décrite, soit l'adresse physique de la table de translation décrite, est modifié de telle sorte que le type et l'adresse soient compatibles entre eux.

La première méthode est préférée en ce que la modification de l'adresse est toujours réalisable, la seconde méthode suppose que le HTW décode le type du descripteur depuis un champs de bit du descripteur lui-même (ce que ce qui n'est pas toujours le cas) afin que le transcodeur puisse modifier ce champ de bit, et donc modifier le type du descripteur tel que décodé par le HTW. Si le HTW calcule le type du descripteur d'une façon implicite, la deuxième méthode n'est pas réalisable. Si le HTW décode d'une façon partiellement implicite le type du descripteur en utilisant un encodage explicite d'un type parmi un sous-ensemble implicite des types possibles, la deuxième méthode, en fonction des caractéristiques précises du HTW, peut être ou ne pas être réalisable.

Pour simplifier les traitements que le moyen de transcodage effectue, il est prévu que les types de tables sont encodées dans des bits parmi les plus significatifs des adresses. A ce titre, les adresses mémoires de chaque plage d'adresses associée à un type ont des bits, parmi par

exemple les plus significatifs, fonction dudit type. Cette réalisation correspond à un mappage (correspondance) de la mémoire externe, c'est-à-dire que les adresses effectives sont encodées sur les bits restants ; des bits, parmi les plus significatifs, n'étant utilisés que pour encoder le type de table courant et par conséquent connaître le niveau actuel dans le parcours de l'arbre et les règles à appliquer aux descripteurs de translation qui y sont lus.

Cette organisation des adresses permet de réaliser la fonction de filtrage (de transcodage) bien que le processeur ou le HTW ne donne aucune information, au moyen de transcodage, sur le type (accès normal, ou type d'accès HTW donné) de ses accès en lecture.

On note que les accès normaux utilisent des adresses dont des bits, parmi les plus significatifs, ont une combinaison différente des combinaisons utilisées pour indiquer les types d'accès HTW donnés, cette combinaison étant référée en tant que combinaison d'accès normal. Les adresses physiques spécifiées par les descripteurs de translation terminaux utilisent la combinaison d'accès normal, car ces adresses sont destinées à translater des adresses virtuelles émises par les applications.

Dans ce mode de réalisation, il peut être prévu plus particulièrement, dans le cas où le descripteur reçu en réponse est un descripteur terminal spécifiant une adresse physique de page mémoire, que le moyen de transcodage est un filtre de ladite adresse physique reçue réalisant, avant transmission du descripteur terminal reçu audit mécanisme matériel HTW, la fonction suivante : l'altération desdits bits les plus significatifs de l'adresse physique fournie, les bits encodant les adresses physiques effectives n'étant, quant à eux, pas altérés.

Ce nettoyage éventuel vise à rétablir, au sein de l'adresse indiquée dans le descripteur retourné, un type correct d'adresse (la combinaison d'accès normal) afin que cet encodage précis soit utilisé lors de

l'émission de requêtes mémoire par les applications (les accès normaux donc).

Afin d'appliquer le filtrage adéquat fonction du type courant, il importe que le transcodeur connaisse efficacement le parcours dans la base de données. L'utilisation des bits les plus significatifs à cette fin comme décrit ci-dessus est une solution.

En fonction des caractéristiques du HTW, le moyen de transcodage peut être amené à enregistrer les requêtes émises par le HTW (il peut les reconnaître car leur adresse n'utilise pas la combinaison normale d'accès telle que définie ci-dessus). A cette fin d'enregistrement, il peut être prévu l'utilisation d'un registre tel que mentionné précédemment afin de mémoriser le type de descripteur attendu (et donc les opérations de filtrage à appliquer au retour). Pour mettre à jour ce registre, il convient que le moyen de transcodage répertorie l'ensemble des requêtes émises par le HTW pour accéder aux descripteurs en mémoire. Pour ce faire, il est prévu que lequel ledit moyen de transcodage est agencé pour recevoir ladite au moins une requête en lecture de la mémoire externe. En outre, les accès à des descripteurs en mémoire interne peuvent faire évoluer le parcours dans la base de données. Ainsi, on prévoit que ladite au moins une ressource interne comprend au moins une mémoire interne stockant des descripteurs de translation, ledit mécanisme matériel HTW est alors également agencé pour émettre au moins une requête en lecture d'un descripteur de translation stocké en mémoire interne lors de l'émission d'une adresse virtuelle par l'exécution d'une application, et ledit moyen de transcodage est également agencé pour recevoir ladite au moins une requête en lecture de la mémoire interne.

Dans une configuration telle que présentée ci-dessus, dans laquelle un processeur permet l'exécution de plusieurs environnements dont certains sont sécurisés, il convient d'utiliser un hyperviseur (logiciel de

virtualisation du processeur) afin de cloisonner diverses applications à exécuter (notamment des systèmes d'exploitation vis-à-vis d'applications sécurisées très sensibles, par exemple celles relatives au paiement par terminaux carte bancaire). Notamment, ladite application est un hyperviseur exécuté dans un mode privilégié du processeur. Cet hyperviseur contrôle ainsi l'accès aux ressources matérielles du circuit sécurisé par les applications et systèmes d'exploitation exécutés sur le processeur.

Selon deux modes de réalisation :

- ladite mémoire externe comprend un système d'exploitation pour l'exécution d'une pluralité d'applications, ledit système d'exploitation étant exécuté par ledit processeur sous le contrôle et la supervision dudit hyperviseur,

- ladite mémoire interne comprend au moins une application sécurisée, pouvant être elle-même un système d'exploitation, cette application étant exécutée sous le contrôle et la supervision dudit hyperviseur.

Comme mentionné précédemment, ledit processeur peut comprendre une unité de gestion de mémoire MMU contenant un cache de translations d'adresses récentes TLB, ledit mécanisme matériel HTW étant agencé pour mettre à jour ledit cache TLB en réponse à ladite requête en consultation.

Dans un mode de réalisation de l'invention, il est prévu que ledit circuit sécurisé comprend un contrôleur de mémoire externe par lequel ledit circuit sécurisé communique avec ladite mémoire externe, ledit moyen de transcodage étant disposé entre le processeur et ledit contrôleur de mémoire externe. Le moyen de transcodage concerne donc un module spécifique intégré dans le circuit sécurisé au niveau d'une matrice de communication permettant la communication entre le HTW et le contrôleur de mémoire externe.

Selon une variante, ledit moyen de transcodage comprend des fonctionnalités de contrôleur de mémoire externe grâce auxquelles ledit circuit sécurisé communique avec ladite mémoire externe.

De façon avantageuse, ledit moyen de transcodage est une unité matérielle intégrée dans le module sécurisé. Une telle réalisation, à partir des spécificités fonctionnelles décrites ci avant, ne présente aucune complexité technique.

Le processeur et éventuellement d'autres unités du circuit peuvent également accéder à la mémoire externe. Dans ce cas, il est prévu que ledit moyen de transcodage est agencé pour recevoir également une requête en lecture non générée par le mécanisme matériel HTW et pour transmettre, à l'émetteur de ladite requête et sans modification, la donnée reçue en réponse à cette requête. On délimite ainsi l'invention à la sécurisation de la gestion de la mémoire par le processeur (au travers de la MMU et du HTW).

L'invention a également pour objet un procédé de protection d'un environnement informatique sécurisé exécuté dans un circuit sécurisé de processeur, le procédé comprenant :

- l'exécution d'une application par un processeur dans ledit circuit sécurisé,

- lorsque l'application émet une adresse virtuelle, une étape par laquelle un mécanisme matériel HTW dudit processeur émet au moins une requête en lecture d'au moins un descripteur de translation stocké dans une mémoire externe, ladite mémoire externe étant connectée audit module sécurisé et comprenant une pluralité de descripteurs de translation agencée pour associer des adresses virtuelles à des adresses physiques appartenant à un univers moins sécurisé.

Le procédé s'appuie sur un moyen de transcodage recevant la réponse à ladite au moins une requête en lecture, ce moyen de transcodage étant disposé, dans ledit circuit sécurisé de processeur, entre ledit processeur et la mémoire externe. Le procédé comprend, en outre, les étapes suivantes :

- la réception, par ledit moyen de transcodage, d'au moins un descripteur de translation en réponse à ladite au moins une requête en lecture, et

- la vérification, par ledit moyen de transcodage, de savoir si ledit descripteur reçu associe une adresse virtuelle à une adresse physique d'un univers sécurisé, ledit univers sécurisé comprenant au moins une ressource interne audit circuit sécurisé.

Dans un mode de réalisation, le procédé comprend, lorsque ladite vérification est positive (association d'une adresse virtuelle à une adresse de l'univers sécurisé), une étape de génération, par ledit moyen de transcodage, d'une exception informatique.

Dans un autre mode de réalisation, le procédé comprend, lorsque ladite vérification est positive, une étape de modification dudit descripteur de translation reçu en spécifiant une adresse physique désignant ledit univers non sécurisé, avant transmission de cette adresse modifiée audit mécanisme matériel HTW.

Particulièrement, ladite pluralité de descripteurs de translation est regroupée en une pluralité de tables de translations, lesdites tables de translations étant regroupées en types de tables, au moins un descripteur de translation associe une plage d'adresses virtuelles à une autre table de translations en indiquant une adresse physique de ladite autre table, les adresses physiques des tables de translations d'un même type de tables appartenant à une même plage d'adresses associée audit type,

le procédé comprenant, en outre, une deuxième étape de vérification, par ledit moyen de transcodage, que ladite adresse physique du descripteur reçu en réponse à la requête en lecture appartient à la plage d'adresses associée au type de ladite autre table de translation spécifiée dans le descripteur reçu, et une étape ultérieure de transmission, en cas de deuxième vérification positive, dudit descripteur de translation reçu audit mécanisme matériel HTW.

Dans ce mode de réalisation, il est également envisagé qu'au moins un descripteur de translation est un descripteur de translation terminal associant une plage d'adresses virtuelles à une plage d'adresses physiques de l'univers moins sécurisé, lesdites adresses de descripteur encodant, dans une partie de leurs bits, le type de table auquel elles se réfèrent. Le procédé comprend alors, en outre lorsqu'un descripteur de translation terminal est reçu par le mécanisme de transcodage, une étape d'altération desdits bits du descripteur terminal reçu dans un format spécifique (ci-dessus nommé "combinaison d'accès normal").

Plus particulièrement, le procédé peut comprendre, en outre, à l'émission de ladite au moins une requête, une étape de mise à jour d'un registre dudit moyen de transcodage, ledit registre comprenant le type associé à la table de translations visée dans ladite requête, et au moins une étape de traitement dudit descripteur de translation reçu par ledit moyen de transcodage, ledit traitement étant fonction dudit type de table enregistré dans le registre.

Dans un mode de réalisation, les applications sont exécutées sous le contrôle d'un hyperviseur, et le procédé comprend, suite à la détection de l'exception par ledit hyperviseur, une étape d'altération de données confidentielles stockées en mémoire interne, afin d'empêcher tout accès à celles-ci.

On comprendra mieux l'invention à l'aide de la description, faite ci- après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées :

- Fig. 1 illustre l'architecture générale de la présente invention ;

- Fig. 2 représente un exemple d'architecture logicielle dans laquelle s'inscrit l'invention ;

- Fig. 3 est un exemple de structure de tables de translations pour la mise en œuvre de l'invention ; et

- Fig. 4 illustre un exemple de formatage des adresses et le principe de correspondance (mappage) associé de la mémoire.

En référence à la Fig. 1 , un module ou circuit sécurisé 1 comprend un processeur 10, des mémoires internes 1 1 et 12, un ou des périphérique(s) interne(s) 13, un contrôleur de mémoire externe 14, une unité transcodeur matérielle 15 et un bus ou matrice de communication 16 entre ces diverses entités.

Le transcodeur 15 est situé entre le processeur 10 et le contrôleur de mémoire externe 14, de telle façon que tous les accès en lecture à une mémoire externe 2 reliée par le contrôleur et générés par le HTW passent par le transcodeur 15.

Ces entités sont situées soit sur une même puce de silicium, cette puce de silicium étant encapsulée dans un boîtier, soit réparties sur des puces de silicium distinctes, ces puces de silicium et leurs interconnections étant encapsulées dans un même boîtier. L'encapsulation dans le même boîtier est réalisée de sorte qu'il ne soit possible ni d'observer ni d'altérer les signaux de communication entre ces entités sans des moyens techniques très importants.

Le processeur 10 comprend une unité de gestion de la mémoire MMU 100, une table TLB 101 des translations récentes et un mécanisme Hardware page Table Waiker HTW 102 pour mettre à jour la TLB 101.

Un unique registre 1020 est associé au mécanisme matériel HTW 102 et lui indique l'emplacement de la table de translations initiale 1 1 1 à partir de laquelle la résolution d'une adresse logique pour le processeur peut être menée.

Egalement en référence à la Fig. 2, le processeur 10 permet l'exécution d'un hyperviseur 17 dans un mode privilégie du processeur et d'au moins une application sécurisée 18 utilisant des données sensibles stockées en mémoire SRAM 11 (Static Random Access Memory) du module 1. Le code de l'hyperviseur et de l'application sécurisée, ainsi que les données non modifiables qu'ils utilisent, sont stockées dans la mémoire ROM 12 (Read OnIy Memory) du module sécurisé 1.

Le module sécurisé 1 est relié à la mémoire externe 2 (limitée à 512 Mo) et d'éventuels périphériques externes 2' par une matrice de connexion 3 du type piste de circuit imprimé et connecteurs. La mémoire externe comprend un système d'exploitation OS 21 , par exemple Linux, adapté à être exécuté sur le processeur 10 sous le contrôle de l'hyperviseur 17 et des applications 22 exécutées par ce système d'exploitation. Ces applications et OS utilisent des codes instructions et des données 23 stockées dans cette mémoire externe 2.

Le mécanisme HTW 102 du processeur 10 s'appuie sur une base de données de tables de translations 24 stockée en mémoire externe 2 pour résoudre les translations d'adresses logiques utilisées par le système d'exploitation 21 et les applications 22 lorsqu'ils sont exécutés par le processeur 10.

L'application sécurisée 18 et les entités du module sécurisé 1 constituent un environnement d'exécution sensible et à ce titre sécurisé ENVIR-S. La mémoire externe 2, les applications 22, le système d'exploitation 21 et les périphériques 2' constituent un univers moins sécurisé ENVIR-NS, notamment parce que les échanges avec le module 1 peuvent être interceptés au niveau de la matrice de connexion 3.

L'univers moins sécurisé ENVIR-NS peut aussi comprendre certaines des mémoires et périphériques internes au boîtier 1.

L'univers moins sécurisé ENVIR-NS résiste néanmoins aux attaques uniquement logicielles, grâce à l'utilisation de la MMU du processeur et de l'isolation logicielle que celle-ci procure.

Ces deux univers ENVIR-S et ENVIR-NS cohabitent sur un même processeur 10 grâce au logiciel spécialisé de virtualisation de processeur, (hyperviseur 17). Les ressources (mémoire(s), périphérique(s)) utilisées par l'hyperviseur opèrent dans l'univers sécurisé.

Le système d'exploitation généraliste protège ses applications entre elles par l'utilisation d'une MMU virtuelle qui est réalisée par des services logiciels fournis par l'hyperviseur 17, ces services utilisant la MMU réelle du processeur. Une telle solution est décrite notamment dans la demande de brevet WO-2006/027488.

Maintenant en référence à la Fig. 3, puisque le processeur 10 est dédié à la fois à l'univers sécurisé ENVIR-S et à l'univers moins sécurisé ENVIR-NS, la table de translations initiale 1 1 1 est stockée dans la mémoire interne 1 1 sécurisée. Sa taille est réduite, par exemple 16 Ko et renvoie, en ce qui concerne les données de l'univers non sécurisé aux tables de translations de la base 24.

En revanche, pour ce qui est des données sécurisées en mémoire interne 11 ou 12, cette table 1 1 1 contient soit directement les translations adresse logique-adresse physique des pages mémoires de la mémoire interne, soit l'adresse d'une autre table de translations stockée dans la mémoire interne. Des mécanismes traditionnels s'appliquent alors. L'invention visant principalement à protéger le système lors de l'accès aux tables de translations en mémoire externe, la résolution des adresses logiques relatives aux données sécurisées n'est pas traitée plus avant.

La base de données 24 est constituée en un assemblage de tables de translations 240 de façon arborescente. A cette fin, trois types de tables de translation sont utilisés.

Les tables de translations terminales sont des tables dont chaque entrée E décrit la translation d'adresse d'une page d'adresse logique (ou virtuelle) correspondant à l'entrée E en une page d'adresse physique de la mémoire (descripteur de translation final). Les pages physiques de la mémoire sont généralement d'une taille de l'ordre de 4 kilo-octets.

Les tables de translations X non terminales sont des tables dont chaque entrée E (dite descripteur de translation de table) décrit une autre table de translation Y (par exemple, renseigne l'adresse @Y de cette autre table Y). Cette table Y, qui peut être terminale, non terminale ou mixte, décrit, avec une granularité plus fine, la plage d'adresses logiques qui correspond à l'entrée E considérée de la table X. Le type de la table Y peut être soit implicite, soit encodé dans l'entrée E éventuellement à partir d'un sous-ensemble implicite des types de tables de translations.

Les tables de translations X mixtes sont des tables dont chaque entrée E peut décrire:

- soit la translation d'adresse de la plage d'adresses logiques correspondant à l'entrée E en une plage d'adresses physiques ;

- soit une autre table de translation Y, terminale, non terminale ou mixte, qui va décrire avec une granularité plus fine, la plage d'adresses logiques qui correspond à l'entrée E considérée de la table X.

Dans chaque entrée d'une table de translation mixte X, un encodage indique laquelle de ces deux fonctions est réalisée. Quand une autre table Y de translation est décrite, le type de la table Y peut être soit implicite, soit encodé dans l'entrée E, éventuellement à partir d'un sous-ensemble implicite des types de table de translations.

Chaque descripteur de translation correspond au minimum à un accès du processeur soit, par exemple, 32 bits. En référence également à la Fig. 4, les adresses physiques stockées dans les entrées (descripteurs) des tables de translations sont codées sur 32 bits. Une page physique fait, par exemple, au minimum 4 ko, donc seuls les 20 bits les plus significatifs (MSB) de l'adresse physique 32 bits sont nécessaires pour coder l'adresse de page physique, les 12 bits restant étant utilisés :

- pour éventuellement indiquer le type du descripteur de translation, par exemple à partir d'un sous-ensemble implicite des types de descripteur de translation (aux fins du HTW),

- pour les descripteurs de translation terminaux seulement, pour coder diverses informations sur les propriétés de la page physique, comme par exemple son accessibilité en lecture, en écriture, éventuellement en fonction du mode d'exploitation du processeur dans lequel l'accès est effectué.

L'arborescence des tables de translations 240 dans la base 24 permet de définir ces trois (N) types de tables, chaque type correspondant à un niveau de l'arborescence comme illustré sur la Fig. 3.

Le mécanisme HTW reconnaît trois types différents de tables HTW-1 , HTW-2 et HTW-3 (HTW-N). Un accès mémoire généré par le HTW 102 pour résoudre une translation d'adresse est dit de type P quand il correspond à la lecture d'une table de translation de type P.

Le processeur 10 n'indique pas, lors d'un accès en lecture de la mémoire, si l'accès a été généré par le HTW 102, ou résulte de l'exécution habituelle d'une instruction de lecture mémoire. Si le transcodeur 15 est placé de telle sorte qu'il intercepte aussi des accès en lecture qui ne sont pas générés par le HTW 102, alors l'accès de type 0 est défini comme étant un accès qui n'est pas généré par le HTW.

Si ie type 0 existe, la mémoire externe est mappée quatre (N+1) fois : elle peut être accédée via quatre (N + 1) Plages d'Adresses Physiques 20 différentes désignées PAP[O] jusqu'à PAP[3] (PAP[N]).

Si le type 0 n'existe pas, la mémoire externe est mappée trois (N) fois: elle peut être accédée via trois (N) Plages d'Adresses Physique 20 différentes numérotées PAP[I ] jusqu'à PAP[3] (PAP[N]).

Dans les deux cas, les PAP font toutes la même taille et permettent d'accéder à l'ensemble de la mémoire externe 2.

Les deux bits les plus significatifs [31 ;29] des adresses physiques sont décodées de la façon suivante :

- 00 -> indique que l'accès est interne au circuit sécurisé. Un accès interne reste à l'intérieur du circuit sécurisé 1 , de telle sorte que depuis l'extérieur du circuit 1 , l'on ne puisse pas l'altérer ni même savoir qu'il a eu lieu,

- 01 -> indique que l'accès est externe et concerne les ressources externes 2',

- 1 x -> indique que l'accès est externe, et concerne la mémoire externe 2 (x valant 0 ou 1 , comme décrit ci-après).

Un accès externe, quant à lui, est véhiculé sur les pistes électriques de la matrice de communication 3 externe afin d'accéder à une des ressources externes 2 ou 2' (donc obligatoirement de l'univers moins sécurisé).

Lorsque l'adresse physique correspond à une adresse de la mémoire externe 2 (c'est-à-dire le bit [31] vaut 1), les bits [30:29] indiquent le numéro de type :

00 -> l'accès n'a pas été généré par le HTW (le filtre est inactif),

01 -> l'accès doit être filtré, et correspond au type HTW 1

10 -> l'accès doit être filtré, et correspond au type HTW 2

11 -> l'accès doit être filtré, et correspond au type HTW 3,

Lorsque l'adresse correspond à la mémoire externe 2, les bits [28 :0] correspondent à l'adresse effective dans la mémoire externe 2.

Cela signifie que les adresses physiques dont les bits [31 , 30, 29] :

- valent 100, forment la PAP[O] ;

- valent 101 , forment la PAP[I ] ;

- valent 110, forment la PAP[2] ;

- valent 1 1 1 , forment la PAP[3].

Lors de l'exécution des applications et systèmes d'exploitation par le processeur, l'hyperviseur 17 enregistre les adresses de données sous la forme indiquée ci-dessus, c'est-à-dire en utilisant les trois bits les plus significatifs pour encoder l'externalité et le type de table concerné. L'hyperviseur organise ainsi la gestion de l'adressage logique et physique de telle sorte que les accès de type i utilisent la PAP[i].

Le transcodeur 15 possède une unité logique ou registre 150, qui lui permet de reconnaître à quelle PAP une adresse physique appartient. Il met à jour cette unité logique lorsque l'arbre est parcouru, par exemple en incrémentant de 1 l'unité si le parcours de l'arbre est fait niveau par niveau, sinon en mettant à jour l'unité logique 150 en fonction du type correspondant à la table de translations visée dans la requête en lecture émise par le HTW 102.

Lors du processus de rechargement par le HTW 15 d'une entrée de TLB 101 , une ou plusieurs tables de translations (1 1 1 puis 240) sont accédées.

L'accès à une table de translation (1 1 1 , 240) consiste en la lecture d'une de ses entrées.

La lecture d'une entrée de table de translations 240 d'un type donné en mémoire externe 2 est réalisée soit :

- par un unique accès en lecture de la mémoire,

- par une série consécutive d'accès en lecture de la mémoire.

Le nombre d'accès en lecture pour lire une entrée d'une table de translation d'un type donné est spécifique à ce type. Dans la suite de ce document, et pour simplifier les explications sans nuire à la généralité, la lecture d'une entrée de table est considérée comme étant réalisé par un accès en lecture unique. Quand la lecture d'une entrée nécessite plusieurs accès, l'homme de l'art extrapolera simplement les explications en considérant par exemple qu'une série de i accès consécutifs, sur un bus de largeur I bit, peut être vue comme un accès unique, de largeur (i x I) bits.

Ainsi, lors d'un accès en lecture à la mémoire externe 2 pour résoudre une translation, le transcodeur 15 reconnaît la PAP concernée par l'adresse recherchée grâce aux trois bits [31 ,30,29] les plus significatifs de l'adresse demandée. Le transcodeur 15 met alors à jour le registre 150 avec la valeur des bits [30,29]. Généralement le type vaut 01 lorsqu'une nouvelle adresse virtuelle doit être translatée. Ce type s'incrémente au fur et à mesure du parcours de l'arborescence des tables et donc des adresses indiquant de nouveaux types dans les bits correspondants. A ce stade, le transcodeur 15 est en attente de la réponse à la requête pour appliquer des traitements adéquats fonction du type mémorisé dans le registre 150.

Les mécanismes de la mémoire externe 2 résolvent la requête en lecture émise et retourne le descripteur de la base 24 qui est associé à l'adresse envoyée. Ce descripteur de translation indique soit une adresse physique de page mémoire (descripteur final) soit l'adresse d'une autre table de translation à laquelle il faut accéder, par une requête supplémentaire en lecture, pour poursuivre la translation de l'adresse virtuelle.

A réception de la réponse, le transcodeur 15 applique différentes règles.

Pour les accès à la PAP[O] (ne concernent pas des requêtes émises par le mécanisme HTW 102), le transcodeur transmet la donnée lue de façon inchangée au processeur ou à l'émetteur de la requête.

Pour les accès aux PAP d'indice non nul (relatifs à des requêtes émises par le HTW 102), le transcodeur modifie la donnée lue, avant de la fournir au HTW du processeur, à partir d'une règle qui dépend de l'indice de la PAP stockée dans le registre 150. Cette modification assure les règles suivantes dans deux cas distincts.

Dans un premier cas, si le descripteur de translation retourné décrit directement la translation d'une plage d'adresses logiques en une plage d'adresses physiques, alors le transcodeur 15 altère certains bits de son contenu, de telle façon que:

1. soit la translation ne puisse spécifier que des adresses physiques de l'univers moins sécurisé ;

2. soit si la translation spécifie une adresse physique de l'univers sécurisé, alors l'accessibilité spécifiée est nulle (invalide). En fonction de son exigence en matière de sécurité, le concepteur du système peut moduler et réduire l'accessibilité : exécution seulement et/ou lecture seulement, au lieu de forcer cette accessibilité à être nulle ;

3. soit si la translation spécifie une adresse physique de l'univers sécurisé, le transcodeur indique au CPU que l'instruction qui a causé la recherche dans la base de données de translation doit être annulée ou abandonnée. Dans ce cas, le transcodeur ne réalise plus en fait une fonction de transcodage, mais plutôt une fonction de détection.

Pour ces trois actions, le transcodeur génère une interruption ou une exception, pour signaler le problème à l'hyperviseur. En outre, il peut

renseigner un registre indépendant "statut" par lequel il indique (valeur = 1 ) que c'est lui qui a émis une interruption/exception. L'hyperviseur, considérant le système attaqué, peut, par exemple, décider d'effacer préventivement des clefs de chiffrement stockées en mémoire interne ou toute autre contre-mesure adaptée. Néanmoins, si le registre a la valeur 0 et qu'une interruption/exception est reçue par l'hyperviseur, ce dernier peut décider d'en tenir compte différemment, comme par exemple mettre fin à l'application en cours d'exécution qui est à l'origine de la demande de translation interrompue. En effet, cette exception ne relève peut-être que d'un bogue de l'application qui ne mérite pas de contre-mesure extrême, mais uniquement le redémarrage de l'application.

Dans un deuxième cas, si le descripteur de translation retourné décrit une table de translation d'un type donné T, le transcodeur 15 vérifie que l'adresse de la table T est bien dans la PAP[T]. Le type de table T est donné par les bits [30,29] de l'adresse retournée dans le descripteur. Si tel est le cas, la donnée lue est fournie au HTW inchangée (sauf cas indéfini décrit plus bas). Autrement le transcodeur assure que: a) préférentiellement l'adresse est transformée en une adresse valide appartenant à PAP[T], b) soit, si l'adresse appartient à la PAP[S] et si le HTW décode depuis une partie du descripteur, le type de ce dernier (éventuellement à partir d'un sous-ensemble implicite des types de descripteurs, ce sous-ensemble contenant au moins le type S), alors le transcodeur peut modifier le descripteur de telle façon que celui-ci soit reconnu par le HTW comme étant bien du type S. L'adresse peut dans ce processus être modifiée aussi pour respecter, par exemple, des contraintes d'alignement propres au type S, ainsi que pour avoir ses bits 30 et 29 mis à la valeur de type correspondante

La méthode a) est préférée en ce qu'elle est plus simple et marche dans tous les cas de figure, contrairement à la méthode b) qui nécessite la condition supplémentaire exposée dans sa description.

En général, le concepteur de HTW cherche à permettre la réalisation de bases de données de translations compactes en mémoire. Aussi habituellement toutes les combinaisons possibles pour un format de page donnée sont significatives, c'est-à-dire qu'il n'y a pas de combinaison binaire pour un descripteur de translation, qui ne puissent être décodée par le HTW, et conduire à un comportement prédictible et légal de celui-ci.

Mais dans le cas où le HTW 102 ne supporte pas toutes les combinaisons possibles, et dans l'éventualité d'une entrée de table comprenant des combinaisons non supportées, d'un agencement non supporté (création de boucle dans la structure par exemple), ou de quelque autre réalisation incorrecte de la base de données de translation, le HTW 102 pourrait alors adopter un comportement indéfini, ce qui représente une menace pour la sécurité de l'univers sécurisé. En conséquence le transcodeur 15 a aussi comme rôle de protéger le HTW contre tous les défauts ou malfaçons de la base de données de translation, ces défauts ou malfaçons ayant pu être réalisés, à des fins d'attaque, par la modification du contenu de la mémoire externe, par des moyens d'altération des signaux.

A cette fin, le transcodeur 15 détecte ces défauts et malfaçons. Cette détection est réalisée, par exemple, de la façon suivante :

- lors de l'émission d'une requête par le HTW, le transcodeur repère quel est le type attendu. Quand le descripteur est retourné par la mémoire externe, le transcodeur vérifie sa conformité avec le type attendu, en fonction de règles propres à chaque type (par exemple vérifier qu'une contrainte d'alignement d'adresse de table de translation est respectée) ;

- quand une malfaçon est détectée alors le transcodeur :

• soit transforme la ou les données incorrecte(s) en donnée(s) correcte(s), puis applique un transcodage respectant l'une des règles 1 , 2 ou 3 précédentes ;

• soit indique au CPU que l'instruction qui a causé la recherche dans la base de données de translations doit être annulée ou abandonnée.

Dans ces deux cas, le transcodeur 15 génère alors une interruption ou une exception pour signaler le problème à l'hyperviseur.

Au lieu d'utiliser une mémoire externe 2 mappée plusieurs fois par des PAP 20, celle-ci peut être mappée une seule fois. La plage d'adresses physiques correspondantes est divisée en ZONEs, de taille égale ou non, jouant le même rôle que les PAPs. L'hyperviseur doit dans ce cas ne placer les tables de translations que dans les zones correspondantes, ce qui peut représenter une contrainte non négligeable (traitements plus importants). Mais cette variante a l'avantage de réduire l'espace d'adressage physique consommé par la mémoire externe.

Un mélange du concept de PAP et de ZONE peut être utilisé pour obtenir un compromis entre flexibilité et taille de l'espace d'adresse physique consommé par la mémoire externe.

Le bus 16 peut avoir des signaux dont des combinaisons peuvent renseigner sur le fait que le HTW 102 fait un accès ou non, et de quel type est cet accès. Le transcodeur 15 n'a plus besoin donc du concept de PAP car il obtient, par ces signaux, l'information de TYPE nécessaire pour appliquer la règle de transcodage adéquate.