FR2829847A1

FR2829847A1 - Procede de controle d'acces a des ressources partagees dans un systeme embarque et systeme embarque pour la mise en oeuvre d'un tel procede

Info

Publication number: FR2829847A1
Application number: FR0112143A
Authority: FR
Inventors: Dominique Bouveron; Nicolas Fougeroux; Patrice Hameau
Original assignee: CP8
Current assignee: CP8
Priority date: 2001-09-20
Filing date: 2001-09-20
Publication date: 2003-03-21

Abstract

L'invention concerne un procédé de contrôle d'accès à une ressource partagée (Rx) par un processus (P1) dans une carte à puce (1}. Deux processus (P1 , P2) ou plus peuvent poser une requête d'accès à une ressource partagée (Rx) en même temps. Selon l'invention, on met à la disposition de chaque ressource partagée (Rx) une position de mémoire (4x) stockant un bit dit de verrou, mis à l'état "0 " dans une phase initiale. On réserve aussi une position de mémoire (4y) contenant une valeur de vérification (checksum) permettant de préserver l'intégrité des zones mémoire (4x). Chaque ressource partagée (Rx) est associée à une première primitive système dite de réservation de ressource (5-P) qui teste l'état du bit, et lorsqu'il est à "0 ", le positionne à "1 " et accorde l'accès. Dans le cas contraire, elle interdit l'accès. Chaque ressource partagée (Rx) est aussi associée à une seconde primitive système dite de libération de ressource (6-V) qui remet le bit à " 0 " lors de la libération de cette ressource. Les deux primitives ne sont pas interruptibles. Avant ou après toute modification d'au moins un bit " verrou ", la valeur de vérification (4y) est vérifiée ou mise à jour.L'invention concerne également une carte à puce (1) mettant en oeuvre le procédé.

Description

PROCEDE DE CONTROLE D'ACCES A DES RESSOURCES PARTAGEES DANS UN SYSTEME EMBARQUE ET SYSTEME EMBARQUE POUR LA MISE EN CEUVRE D'UN TEL PROCEDE
L'invention concerne un procédé de contrôle d'accès à des ressources partagées dans un système embarqué à puce électronique.

L'invention concerne encore plus particulièrement un système embarqué du type dit"multiprocessus"ou encore"multitâches", ayant à gérer l'accès à des ressources partagées. Pour simplifier, le terme"multi-processus"sera seul utilisé dans ce qui suit.

L'invention concerne encore un système embarqué pour la mise en oeuvre d'un tel procédé.

L'invention s'applique plus particulièrement à une carte à puce.

Dans le cadre de l'invention, le terme "système embarqué" doit être compris dans son sens le plus général. Il concerne notamment toutes sortes de terminaux légers munis d'une puce électronique, et plus particulièrement les cartes à puce proprement dites. La puce électronique est munie elle-même de moyens d'enregistrement (mémoire) et de traitement de données numériques, par exemple un microprocesseur pour ces derniers moyens. Dans tous les cas, la puissance de calcul et la capacité de stockages résidents dans un système embarqué sont relativement limitées, ce par comparaison à un système hôte du système embarqué, par exemple un micro-ordinateur. La comparaison est encore plus défavorable si on considère des systèmes plus puissants : serveurs de réseaux locaux, systèmes dits"minis"ou grands systèmes dits"mainframes".

Toujours dans le cadre de l'invention, le terme"ressources"désigne des ressources informatiques présentes dans le système embarqué, indistinctement de type logiciel ou matériel. De façon plus précise, il s'agira ci-après, de ressources partagées, c'est-à-dire pouvant être mises à la disposition d'au moins deux processus concurrents.

Pour fixer les idées, et sans que cela limite en quoi que ce soit sa portée, on se placera ci-après dans le cas de l'application préférée de l'invention, à savoir les applications à base de cartes à puce, sauf mention contraire.

Dans un système multi-processus, un problème particulier se pose si plusieurs processus accèdent en même temps à une même ressource partagée.

On va considérer l'exemple simple suivant pour illustrer de façon non limitative ce problème :
Deux appliquettes sélectionnables en même temps, ou"applets"selon la terminologie anglo-saxonne, constituent un exemple de multiprocessus. Un exemple de ressource partagée est la mémoire de la carte à puce, ou pour le moins une partie de cette mémoire.

Les deux appliquettes précitées peuvent par exemple consister en des applications dites de"porte-monnaie électroniques". Si ces deux appliquettes interrogent en même temps un même compte en banque pour savoir si un débit est possible, en l'absence de contrôle d'accès, elles obtiennent toutes les deux une même réponse (par exemple qu'il reste 1000F), et elles acceptent en conséquence toutes les deux le débit demandé (par exemple 800F chacun). Il s'ensuit que le compte en question va devenir débiteur (en l'occurrence à hauteur de :-600 F), que ce type d'opération soit ou non autorisé.

On conçoit aisément que ce problème puisse exister dans de nombreux autres domaines.

Pour des systèmes informatiques plus puissants, il est possible de prévoir des dispositions permettant d'éviter ce type de problème, même si celles-ci sont "gourmandes"en ressources informatiques. Tel n'est pas le cas pour les cartes à puce (ou plus généralement les systèmes embarqués) qui sont pourvues, par nature, de ressources informatiques limitées comme précédemment rappelé. En outre, dans l'art connu, ce problème ne se posait pas, car les applications standards à base de cartes à puce ne supportent pas un environnement multiprocessus. C'est le cas, en particulier, pour un des langages informatiques le plus utilisé pour ce genre d'application, à savoir"Java Card" (Marque déposée).

Pour résoudre ce problème, on pourrait penser à la solution simple suivante qui consisterait à associer une variable dite partagée à chaque ressource partagée.

Toujours dans l'exemple décrit précédemment (application de portemonnaie électronique), pour fixer les idées, on suppose que la ressource partagée

soit un octet stocké dans une zone semi-fixe de la mémoire de la carte à puce, par exemple en"EEPROM" (pour"Electrically Erasable Programmable read Only Memory"ou Mémoire à lecture seule re-programmable par effacement électrique).

On suppose de plus que cet octet contienne le solde du compte en banque du porteur de la carte à puce. On associe alors une variable que l'on appellera "verrou" (1 bit) à cette ressource partagée ou drapeau, et on l'initialise par exemple à la valeur"0".

Le mécanisme des opérations est le suivant : a/si la variable"verrou"= 1, alors la ressource partagée est en cours d'utilisation et il est nécessaire qu'elle se libère ; b/si la variable"verrou"= 0, alors la ressource partagée est libre. On force la variable "verrou" à "1" pour indiquer que la ressource partagée est en cours d'utilisation.

Il existe néanmoins encore un risque. En effet, on suppose maintenant que le premier processus teste la variable "verrou" qui a pour valeur"0" (indiquant qu'elle est libre), et que ce processus soit interrompu entre le test de la variable "verrou"et son positionnement à"1". Si le deuxième processus prend alors "la main"et a besoin d'accéder à la ressource partagée, il teste la variable "verrou". Celle-ci vaut toujours"0". Le deuxième processus la positionne alors à"1"et utilise la ressource partagée. Quand"la main"est rendue au premier processus, la ressource partagée n'est plus intègre, car elle est susceptible d'être en cours d'utilisation. En effet, le deuxième processus n'a pas forcement fini d'utiliser cette ressource partagée quand l'exécution du premier processus reprend.

On constate que sur cet exemple simple, la solution envisagée pour résoudre le problème, si elle est simple également et donc peu gourmande en ressources informatiques, ne donne cependant pas satisfaction, car elle autorise des dysfonctionnements.

De plus, on constate également que la modification, frauduleuse ou accidentelle, de la variable"verrou"a des conséquences dramatiques sur l'ensemble du système. Un"verrou"malencontreusement positionné à"1"alors qu'il devrait être à"0"interdit définitivement l'accès à cette ressource, alors que le phénomène inverse permet l'accès à une ressource déjà en cours d'utilisation.

L'invention vise à pallier les inconvénients des dispositifs et systèmes de l'art connu, et dont certains viennent d'être rappelés, tout en satisfaisant aux besoins qui se font sentir et aux spécificités présentées par les systèmes embarqués.

Notamment, dans ce cadre d'applications : - les calculs exigés et les besoins en espace mémoire induits par le procédé doivent rester peu importants ; - le procédé doit garantir l'intégrité des zones où sont stockées les informations ; et - le système d'exploitation, ou"OS"selon la terminologie anglosaxonne, dont est pourvue la carte à puce, ou plus généralement le système embarqué, doit pouvoir continuer à libérer une ressource partagée défectueuse, pour ne pas bloquer le système dans sa globalité.

L'invention se fixe donc pour but, dans un système embarqué multiprocessus, un procédé de contrôle d'accès simultané de processus à une ressource partagée permettant d'empêcher, lorsqu'un premier processus utilise une ressource partagée donnée, qu'un ou plusieurs autres processus utilise cette même ressource partagée tant que le premier processus ne l'a pas libérée complètement.

Pour ce faire, le procédé selon l'invention prévoit une gestion d'accès à une même ressource partagée organisant une exclusion mutuelle. En d'autres termes, deux processus demandeurs concurrents, ayant posé une requête d'accès à une même ressource, s'excluent mutuellement.

Selon le procédé de l'invention, on associe à chaque ressource partagée, comme précédemment, une variable partagée formant verrou ou drapeau. Pour simplifier, cette variable sera appelée ci-après "verrou". Dans une phase préliminaire, cette variable est forcée à un premier état prédéterminé dit initial.

Selon une autre caractéristique du procédé selon l'invention, les opérations successives de test et de positionnement des verrous précités sont rendues non interruptibles.

Pour ce faire, on prévoit une première fonction logicielle, de type dit primitive système, qui effectue les deux opérations précédentes, test et

positionnement, du verrou dans un deuxième état déterminé, indiquant la nondisponibilité de la ressource partagée associée. Cette primitive est non interruptible.

On prévoit une seconde fonction logicielle, également de type dit primitive système, qui permet de libérer la ressource partagée par remise à l'état initial du verrou. Cette primitive est également non interruptible.

La mise en oeuvre du procédé selon l'invention peut s'effectuer en recourant à deux grandes familles de solutions, à savoir une implantation de type matériel et une implantation de type logiciel.

En ce qui concerne la solution matérielle, on prévoit qu'une seule instruction machine du microprocesseur peut effectuer les deux opérations rappelées ci-dessus (test et positionnement). Cette disposition permet de résoudre entièrement le problème que se pose l'invention. En effet, comme il est connu, une instruction dite machine est, par définition, non interruptible.

Cependant, une telle instruction n'existe pas sur tous les microprocesseurs du commerce. Il est donc parfois nécessaire de modifier le jeu de microinstructions, ce qui, pour des applications standards ou normalisées, présente un inconvénient.

Une solution logicielle peut être implantée en prévoyant que la fonction logicielle de test et de positionnement soit un appel système prévu pour ne pas être interrompu par le système.

Selon une autre caractéristique du procédé selon l'invention, les variables partagées de type"verrou"associées à chaque ressource partagée sont stockées dans des zones mémoire dont l'intégrité est assurée par un processus de calcul de valeurs de vérification (checksum).

Dans une variante supplémentaire de l'invention, on prévoit en outre d'effectuer un contrôle sur les droits d'accès d'un processus à une ressource partagée, ce de façon avantageuse à l'intérieur de la routine d'exécution de la première primitive, qui effectue les opérations de test et positionnement. Pour ce faire, on vérifie que le processus appelant la routine ait des droits d'accès appropriés pour demander à manipuler la ressource partagée.

Dans une variante supplémentaire de l'invention, on peut aussi prévoir que les routines d'exécution des première et seconde primitives permettent de réserver simultanément l'accès de plusieurs ressources partagées pour éviter un blocage entre plusieurs processus, encore appelé "deadlock" selon la terminologie anglo-saxonne.

L'invention a donc pour objet principal un procédé de contrôle d'accès à des ressources partagées dans un système embarqué comportant au moins des moyens de mémoire et des moyens de calcul sous la commande d'un système d'exploitation, ledit système étant multiprocessus, caractérisé en ce qu'il comprend les étapes suivantes lorsqu'un processus pose une requête d'accès à une desdites ressources partagées : - une étape de test d'une donnée partagée appelée verrou associée à chacune desdites ressources partagées, la valeur de verrou indiquant la disponibilité ou l'indisponibilité de la ressource concernée, par une entité dite de réservation de ressource permettant de refuser l'accès à la ressource partagée concernée en cas d'indisponibilité de ladite ressource ; - une étape de réservation de la ressource partagée concernée si le test de l'étape précédente indique la disponibilité de ladite ressource, par l'entité de réservation de ressource comprenant la modification du verrou pour lui donner une valeur correspondant à l'indisponibilité de la ressource partagée, lesdites étapes de test et de positionnement de réservation se déroulant à la suite l'une de l'autre sans interruption.

L'invention a encore pour objet un système embarqué pour la mise en oeuvre de ce procédé.

L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : - la figure 1 illustre schématiquement l'architecture générale d'une carte à puce ;
La figure 2 illustre schématiquement le mécanisme d'un contrôle d'accès à une ressource partagée ;

ta figure 3 illustre de façon plus détaillée l'architecture d'une carte à puce pour la mise en oeuvre du procédé de contrôle d'accès de processus à des ressources partagées selon l'invention ; et - la figure 4 est un organigramme montrant les principales étapes d'un accès à une ressource partagée par un processus mettant en oeuvre l'architecture de la figure 3.

On va maintenant décrire de façon plus détaillée un exemple de réalisation d'un procédé de contrôle d'accès à une ressource partagée selon l'invention par référence aux figures 1 à 4. Comme il a été indiqué, à titre d'exemple non limitatif et pour fixer les idées, on se placera dans le cas du domaine d'application préférée de l'invention, à savoir les applications à base de cartes à puce.

Il paraît tout d'abord utile de rappeler brièvement l'architecture générale d'une carte à puce 1 pouvant être utilisée dans le cadre de l'invention. La figure 1 illustre très schématiquement une telle architecture. Celle-ci comprend au moins les éléments suivants : un microprocesseur ou équivalent (microcontrôleur) 10, constituant des moyens de traitement de données numériques, des moyens de stockage de données et de programmes, comprenant notamment une zone de mémoire vive ou"RAM" ("Random Access memory") 11 et une zone de mémoire fixe ou semi-fixe 12, par exemple de type"ROM" ("Read Only Memory") ou "PROM" ("Programmable Read Only Memory"), ainsi que des circuits d'entrée- sortie "1/0" ("Input/Output") 13 communiquant avec le milieu extérieur, c'est-à-dire avec le terminal hôte 2 de la carte à puce 1 (par exemple un micro-ordinateur).

Ces différents éléments communiquent entre eux avec un ou plusieurs bus, représenté (s) sous une référence unique B. Généralement, les applications logicielles, microprogrammes, appliquettes, ou"applets"selon la terminologie anglo-saxonne, que l'on appellera de façon générique programmes, sont stockés dans la mémoire fixe ou semi-fixe 12, mais peuvent être également téléchargés directement dans la mémoire vive 11 en provenance du monde extérieur (non représenté), notamment du terminal 2, via les circuits d'entrée-sortie 13.

Pour qu'une application puisse être exécutée, il est nécessaire de charger tout ou partie de son code en mémoire vive 11. Un ou plusieurs processus

est (sont) alors lancé (s). Le bon déroulement de ces processus, sous la commande du microprocesseur 10 et d'un système d'exploitation de la carte à puce 1, ou"OS" ("Operating System"selon la terminologie anglo-saxonne"), exige que des ressources informatiques, tant matérielles que logicielles soient mises à leurs dispositions, notamment, dans le cadre de l'invention, des ressources partagées si la carte à puce 1 est du type multi-processus comme il a été précédemment indiqué.

Lorsqu'un processus demandeur donné pose une requête pour avoir accès à une ressource partagée particulière, il est nécessaire de contrôler si ce processus peut avoir effectivement accès à celle-ci.

Lorsque le système embarqué, en l'occurrence la carte à puce 1, est du type multi-processus, par définition plusieurs processus peuvent s'exécuter en simultanéité. On suppose, dans un premier temps, qu'une ressource, appelée ciaprès Rx, peut être partagée entre deux processus concurrents, appelés ci-après P1 et P2, respectivement. Il est alors nécessaire de contrôler, lorsque l'un des deux processus, par exemple P2, pose une requête d'accès, si la ressource partagée Rx n'est pas déjà en cours d'utilisation par l'autre processus, soit P1 dans l'exemple décrit. L'indice x est arbitraire et varie entre 1 et n, n étant le nombre maximum de ressources partagées.

La figure 2 illustre schématiquement l'architecture d'un système de contrôle d'accès. Deux processus, P1 et P2, posent une requête pour utiliser une ressource partagée Rx. Cette requête est filtrée par un module de contrôle d'accès 3, qui peut être de type logiciel ou matériel.

Si le processus P1, par exemple, a posé sa requête en premier, le processus P2 doit se voir refuser l'accès à la ressource Rx, et inversement.

Pour que le contrôle d'accès soit effectué correctement, selon une première caractéristique du procédé selon l'invention, on associe à chaque ressource partagée Rx une valeur partagée dite de verrou, que l'on appellera "Verrou"ci-après et qui se présente physiquement sous la forme de toute donnée numérique appropriée. Dans un mode de réalisation préféré, puisque deux états distincts sont suffisants, on associe à chaque ressource partagée Rx un seul élément binaire (bit), stocké avantageusement dans une position de la mémoire

vive 11 (figure 1) ou dans un registre indépendant. On peut également associer, à chaque ressource partagée Rx, une bascule, par exemple de type"Flip-Flop", ou tout autre organe similaire présentant deux états logiques.

Ce bit sert de drapeau indiquant la disponibilité ou, au contraire, la nondisponibilité, de la ressource partagée Rx associée. La valeur initiale du bit peut être fixée arbitrairement à l'état logique"0" ("Verrou"= 0). Le bit est initialisé à cette valeur lors d'une phase dite préliminaire.

Ensuite, lors de phases ultérieures, que l'on peut qualifier d'opérationnelles, lorsqu'un processus, par exemple P1, pose une requête d'accès à la ressource Rx et qu'il prend effectivement "la main", le bit est basculé à l'état "1"logique ("Verrou"= 1), indiquant par là que la ressource partagée associée Rx n'est plus disponible.

Si le second processus, c'est-à-dire P2, pose à son tour une requête d'accès à la ressource Rx, un test est effectué sur le bit"Verrou". Dans le cas présent, la valeur "1" de ce bit indique l'état non disponible de la ressource Rx et le processus P2 se verra refuser l'accès demandé.

Lorsque le processus P1 libère la ressource Rx, le bit "Verrou" est repositionné à sa valeur initiale"0", indiquant par là que la ressource partagée associée Rx est de nouveau disponible.

Ce mécanisme est très simple à implanter et à mettre en oeuvre.

Cependant, comme il a été démontré, il autorise, dans certaines conditions, des dysfonctionnements inacceptables. Il n'est donc pas suffisant à lui seul.

Aussi, selon une autre caractéristique du procédé selon l'invention, les opérations successives de test et de positionnement des verrous précitées sont rendues non interruptibles.

Pour ce faire, le procédé selon l'invention prévoit une gestion d'accès à une même ressource partagée Rx organisant une exclusion mutuelle des processus demandeurs, P1 et P2.

A ce titre, selon une deuxième caractéristique du procédé selon l'invention, on prévoit des première et seconde fonctions, de type dit primitives système, non interruptibles.

La première primitive système, que l'on appellera ci-après P, effectue les deux premières opérations, test et positionnement du bit "Verrou" à l'état logique "1" (si le test précédent indique que ! e"verrou"est à"O"), indiquant la nondisponibilité de la ressource partagée associée. Cette primitive P est non interruptible.

La seconde primitive système, que l'on appellera ci-après V, permet de libérer la ressource partagée Rx par remise à l'état logique initia !"0"du bit "Verrou". Cette primitive est également non interruptible.

Les deux primitives, P et V, sont chargées en mémoire vive 11, avantageusement à partir d'un emplacement prédéterminé de la mémoire fixe 12 (figure 1). Elles coopèrent toutes deux avec les moyens de stockage du bit "Verrou" : test du contenu et forçage à la valeur "a" ou "1", comme indiqué cidessus.

Ce mécanisme est toujours relativement simple à implanter et à mettre en oeuvre, mais, comme il a déjà été montré, il autorise toujours, dans certaines conditions, des dysfonctionnements inacceptables.

En effet, les variables de type"verrou"sont des données relativement sensibles. Une modification de la valeur de ces variables, qu'elle soit volontaire ou accidentelle, peut compromettre le fonctionnement du système. Ainsi, ces variables devront être stockées dans des zones mémoire dont l'intégrité sera assurée, par l'intermédiaire de calculs de valeurs de vérification (checksum) par exemple du type Adler connu.

La figure 3 illustre schématiquement l'architecture d'une carte à puce 1 pour la mise en oeuvre du procédé de contrôle d'accès d'un processus, par exemple P2, à une ressource partagée, par exemple Rx. Cette dernière peut être indifféremment de type logiciel (une appliquette par exemple comme illustré ciaprès) ou matériel (zone de mémoire, etc.).

On a représenté sur cette figure 3 une position de mémoire 4x, avantageusement un emplacement de la mémoire vive 11 (figure 1), stockant le bit"Verrou". Par un mécanisme classique en soi, celui-ci est initialisé à l'état logique "0", lors d'une phase préliminaire, par exemple lors de la mise sous tension de la carte à puce 1. L'indice x signifie que la position 4x de mémoire est

associée à la ressource partagée Rx. Il existe en effet autant de bits de verrou que de ressources partagées Rx (soit n comme décrit précédemment). Les emplacements de mémoire correspondants, si on utilise la mémoire vive 11 (figure 1) peuvent être contigus ou répartis à des adresses prédéterminées.

Néanmoins, tous ces emplacements de mémoire, permettant de stocker les bits "verrou"de chaque ressource partagée, sont regroupés dans une zone mémoire dont l'intégrité est assurée par l'intermédiaire du calcul de valeurs de vérification (checksum).

Dans un mode de réalisation préféré, les variables de type"verrou" seront stockées de façon contiguë dans une zone mémoire 4 dont l'intégrité est assurée par l'intermédiaire du calcul d'une unique valeur de vérification portant sur l'ensemble de la zone mémoire 4. Cette valeur de vérification (checksum) est stockée dans la zone mémoire 4y prévue à cet effet.

On a également représenté deux emplacements de mémoire, 5 et 6, destinés à stocker les deux primitives précitées, P et V, respectivement.

Selon le procédé de l'invention, lorsqu'un processus demandeur, P2 par exemple, pose une requête d'accès à la ressource partagée Rx, celle-ci est traitée par une routine d'exécution de la primitive P. Tout d'abord, la valeur de vérification 4y est contrôlée afin de vérifier l'intégrité de la zone mémoire 4. Si la valeur de vérification est incorrecte, l'accès à la ressource partagée Rx est refusé. Dans le cas contraire, ladite primitive P teste ensuite l'état logique du bit"Verrou" (c'est-àdire le contenu de l'emplacement de mémoire 4x où il est stocké), et de façon plus générale l'état d'une donnée numérique constituant la valeur de verrou. Si le bit de verrou est à l'état initial ("verrou"= 0), la ressource partagée Rx est libre. Une autorisation est accordée et elle est mise immédiatement à la disposition du processus demandeur P2. Le bit"Verrou"est positionné à l'état logique "1" par la primitive"P". Ces deux opérations consécutives doivent être réalisées sans qu'il soit possible d'en interrompre le déroulement.

Dans le cas contraire ("verrou"= 1), cela signifie que la ressource partagée Rx est en cours d'utilisation par le processus P1 (représenté en traits pointillés sur la figure 3). L'autorisation d'accès est déniée au processus P2. Celuici doit attendre la libération de la ressource partagée Rx.

Lorsque cette libération intervient, la primitive V en est informée et repositionne le bit de verrou à l'état initial ("Verrou"= 0). Cette primitive est également non interruptible.

Toutes les variables de type"verrou"étant stockées dans une zone mémoire 4 dont l'intégrité est assurée par le calcul d'une valeur de vérification, toute modification de ces variables implique nécessairement la mise à jour de la valeur de vérification 4y. De même, tout accès en lecture à ces variables implique la vérification de la valeur de vérification 4y afin de contrôler l'intégrité des variables de type"verrou".

L'organigramme de la figure 4 illustre les principales étapes du procédé de contrôle d'accès selon la figure 3.

A l'étape 700, une requête d'accès à la ressource partagée Rx est posée par le processus P2.

A l'étape 701, la valeur de vérification est calculée et comparée à la valeur de vérification sauvegardée 4y (figure 3). Si les valeurs sont différentes, il y a un problème d'intégrité et l'accès à la ressource Rx est refusé au processus P2. Si les valeurs sont identiques, le système va ensuite vérifier si la ressource est disponible, et ceci à l'étape 702.

A l'étape 702a le contenu de la position de mémoire 4x (figure 3) est testé, c'est-à-dire la valeur du bit"Verrou".

Si le bit"Verrou"n'est pas à l'état initial ("Verrou"= 1 ; branche"NON"), cela signifie que la ressource Rx est déjà occupée. L'accès à cette ressource est dénié au processus P2. Par contre, si ce bit est à l'état initial ("Verrou"= 0 ; branche "QUI"), l'accès à la ressource partagée Rx est autorisé et le bit"Verrou" est positionné à"1" (étape 702b).

Comme il a été indiqué, ces deux étapes successives de test (702a) et de positionnement de verrou (702b) ne peuvent être interrompues, et, pour cette raison, ont été représentées dans un même bloc en traits pointillés dans le diagramme de la figure 4.

Ensuite, à l'étape 703, après la modification d'au moins une variable "verrou", la valeur de vérification est à nouveau calculée et inscrite dans la zone mémoire 4y contenant la valeur de vérification sauvegardée.

Lorsque le processus P2 décide de libérer la ressource partagée Rx (étape 704), la primitive V positionne le bit "verrou" à l'état logique "0" (étape 705), ce qui indique que la ressource partagée Rx est de nouveau libre. La primitive V ne doit pas pouvoir être interrompue tant que cette opération n'est pas complète.

Ensuite, à l'étape 706, après la remise à zéro de la variable "verrou", la valeur de vérification est recalculée et inscrite dans la zone mémoire 4y contenant la valeur de vérification sauvegardée.

On va maintenant décrire un exemple d'application. Toujours dans le cadre du domaine du porte-monnaie dit électronique, on considère trois comptes en banque familiaux. Chaque compte constitue une ressource partagée distincte, par exemple des variables enregistrant le montant disponible dans les comptes précités, variables que l'on appellera "Compte~père", "Compte~mère", "Compte~enfant", respectivement. On suppose que plusieurs entités peuvent avoir accès à ces différents comptes, donc à ces ressources partagées. Il s'agit par exemple d'applications résidant dans une carte à puce détenue par les trois membres de la famille.

Selon une première caractéristique du procédé de l'invention, on associe à chacune des ressources partagées une variable également partagée de verrou que l'on appellera :"Bit Verrou-père","Bit Verrou-mère"et"Bit Verrou enfant". Ces variables sont initialisées par convention à la valeur"0". On obtient par exemple le tableau suivant représentant les valeurs initiales à un instant donné :

<tb>
<tb> Bit <SEP> Verrou-père <SEP> = <SEP> 0 <SEP> associé <SEP> à.... <SEP> Compte-père <SEP> = <SEP> 50
<tb> Bit <SEP> Verrou~mère <SEP> = <SEP> 0 <SEP> associé <SEP> à.... <SEP> Compte~mère <SEP> = <SEP> 40
<tb> Bit <SEP> Verrouenfant <SEP> = <SEP> 0 <SEP> associé <SEP> à.... <SEP> Compteenfant <SEP> = <SEP> 10
<tb>

Si une application veut effectuer un débit sur le compte de la mère, par exemple répercuter l'achat d'un livre de prix égal à une variable appelée "PRIX-LIVRE", le code correspondant peut être le suivant :

If (P (Verrou-mère) == false) //ICI, le compte de la mère est en

return error. RESSOURCE~USED ; Il cours d'utilisation par une autre entité } else {
COMPTE~mère = Compte~mère - PRIX+~LIVRE ;
V (verrou)

} P et V sont les primitives conformes au procédé de l'invention,"//"indique un commentaire,"If" ("si") est une instruction qui teste la valeur du bit "Verrou~mère" associé à la ressource partagée "Compte~mère" (étape 702a) par l'intermédiaire de la primitive P et"return error. RESSOURCE-USED" indique que la ressource est en cours d'utilisation par un autre processus comme l'indique le commentaire. Dans le cas contraire ("else", toujours à l'étape 702a et sous la commande de la primitive P), l'accès est autorisé et le verrou bit "Verrou~mère" positionné à"1". L'opération de débit est effectuée sous la commande du processus appelant, à savoir la somme "PRIX~LIVRE" est débitée du compte "Compte~mère", dont le montant disponible devient :"Compte-mère- PRIX-LIVRE". Ensuite, la ressource partagée "Compte~mère" est libérée. Sous la commande de la primitive V, ! e bit"Verroumère"est ré-initiaiisé à"O".

Le code ci-dessus peut s'écrire de façon plus compacte en utilisant une instruction dite de boucle"while" (qui impose de continuer tant qu'une condition prescrite n'est pas satisfaite). Un tel code est par exemple le suivant : while (P (Verrou-mère) == false) { Il DO NOTHING Il Dès que la ressource se libère, on la réserve }
Compte~mère = Compte~mère - PRIX~LIVRE ;
V (verrou) ; L'expression"//Dès que la ressource se libère, on la réserve" est un simple commentaire et"//DO NOTHING"indique que le processus est mis en

attente ("ne rien faire") tant que la ressource"Comptemère"est uti ! isée par un autre processus. Les primitives P et V effectuent les mêmes tâches que précédemment.

Un mécanisme identique, ou pour le moins similaire, est mis en oeuvre si un processus quelconque pose une requête d'accès aux autres comptes, c'est-àdire aux autres ressources partagées,"Comptepère"et"Compteenfant", respectivement. On utilise pour ce faire les bits de verrou associés correspondants :"BitVerroupère"et"BitVerrouenfant".

La solution qui vient d'être décrite est du type de ce qui a été appelé "logiciel".

A titre d'alternative, comme également rappelé dans le préambule de la présente description, on peut mettre en oeuvre une solution de type"matériel"en remplaçant les primitives par des microinstructions dites"machine", c'est-à-dire écrites en assembleur, non interruptibles par essence. Cependant, comme il a été signalé, cette solution doit être réservée à des systèmes dont le jeu de microinstructions contient de telles primitives.

Bien que, jusqu'à présent, seuls deux processus concurrents aient été considérés, pour des raisons de simplification de la description, il va de soi que des processus en nombre plus grand que deux peuvent poser des requêtes d'accès à une même ressource partagée Rx. Si cette dernière ressource est disponible, le premier processus demandeur verra sa demande satisfaite. Les processus suivants seront rejetés selon le mécanisme précédemment décrit ou mis en attente. Des dispositions qui sortent du cadre strict de l'invention peuvent être adoptées pour ensuite ré-activer un des processus mis en attente, par exemple selon un mécanisme du type"premier entré-premier servi" (ou"FIFO" selon la terminologie anglo-saxonne) ou encore en tenant compte de niveaux de priorités associés aux processus, si plusieurs processus sont en attente d'être servis.

De même, dans un mode de réalisation supplémentaire, on peut aussi prévoir que les routines d'exécution des primitives P et V permettent de réserver simultanément l'accès de plusieurs ressources partagées, ce pour éviter un blocage ou"deadlock"entre plusieurs processus.

En effet, on va considérer que le processus P1 réserve une ressource partagée Ri et que le processus P2 réserve une ressource partagée R2. On considère également que, avant que Ri et R2 ne soient libérées, P1 ait besoin de R2 et P2 ait besoin de R1. Il s'ensuit que, dans cette situation, les deux processus P1 et P2 sont bloqués en attendant chacun une ressource partagée qui ne pourra pas être débloquée. Dans le cadre du procédé de l'invention, une solution à ce problème consiste à prévoir que la routine d'exécution de la primitive P puisse réserver plus d'une ressource partagée à la fois. Pour ce faire, elle teste les différents bits de verrou des ressources partagées à réserver et selon le résultat des tests les réserve en positionnant ces bits à"1", ou de façon générale à une valeur différente de la valeur d'initialisation.

Le code de la routine de la primitive P devra être légèrement modifié pour supporter ce mode de fonctionnement. Toutefois, cette modification n'entraîne pas une augmentation significative de la complexité globale du procédé.

Dans une mode de réalisation supplémentaire encore, le procédé selon l'invention permet aussi d'effectuer un certain nombre de contrôles sur les droits d'accès aux ressources à l'intérieur de la routine d'exécution de la primitive P. Il suffit de vérifier que le processus appelant cette routine ait des droits d'accès appropriés pour demander à manipuler la ressource partagée demandée. Ceci peut être réalisé, de façon bien connue en soi, par consultation d'un fichier ou d'une base de données dite de sécurité, avantageusement enregistrée dans une zone sécurisée de la mémoire fixe de la carte à puce 1 (figure 1) et fixant les conditions d'accès aux ressources partagées.

A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.

L'invention concerne un procédé de contrôle d'accès à une ressource partagée Rx par un processus P1 dans une carte à puce 1. Deux processus P1, P2 ou plus peuvent poser une requête d'accès à une ressource partagée Rx en même temps. Selon l'invention, on met à la disposition de chaque ressource partagée Rx une position de mémoire 4x stockant un bit dit de verrou, mis à l'état "0"dans une phase initiale. On réserve aussi une position de mémoire 4y contenant une valeur de vérification (checksum) permettant de préserver l'intégrité

des zones mémoire 4x. Chaque ressource partagée Rx est associée à une première primitive dite de réservation de ressource 5-P qui teste l'état du bit, et lorsqu'il est à"0", le positionne à "1" et accorde l'accès. Dans le cas contraire, elle interdit l'accès. Chaque ressource partagée Rx est aussi associée à une seconde primitive dite de libération de ressource 6-V qui remet le bit à "0" lors de la libération de cette ressource. Les deux primitives ne sont pas interruptibles. Avant ou après toute modification d'au moins un bit "verrou", la valeur de vérification 4y est vérifiée ou mise à jour.

L'invention concerne également une carte à puce 1 mettant en oeuvre) le procédé.

Ainsi l'invention permet notamment de contrôler de façon fiable l'accès à une ressource partagée et d'interdire l'accès à un deuxième processus (ou à plusieurs) tant qu'un premier processus n'a pas libéré entièrement cette ressource.

Le procédé convient donc parfaitement aux applications mettant en oeuvre des cartes à puce.

Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 1 à 4.

Elle n'est pas non plus limitée, comme il a été indiqué, seulement à des cartes à puce, mais de façon plus générale à tout système embarqué, qui par nature ne dispose que de ressources informatiques limitées.

La présente invention porte également sur le produit programme d'ordinateur chargeable directement dans la mémoire du système embarqué, comprenant des portions de code de logiciel pour l'exécution des étapes du procédé précédemment décrit lorsque ledit programme est exécuté dans le système embarqué.

Claims

REVENDICATIONS

1. Procédé de contrôle d'accès à des ressources partagées (Rx) dans un système informatique embarqué comportant au moins des moyens de mémoire et des moyens de calcul sous la commande d'un système d'exploitation, ledit système étant multiprocessus, caractérisé en ce qu'il comprend les étapes suivantes lorsqu'un processus pose une requête d'accès à une desdites ressources partagées (Rx) : - une étape de test d'une donnée partagée appelée verrou associée à chacune desdites ressources partagées, la valeur de verrou indiquant la disponibilité ou l'indisponibilité de la ressource concernée, par une entité (P) dite de réservation de ressource permettant de refuser l'accès à la ressource partagée concernée en cas d'indisponibilité de ladite ressource ; - une étape de réservation de la ressource partagée concernée si le test de l'étape précédente indique la disponibilité de ladite ressource, par l'entité (P) de réservation de ressource comprenant la modification du verrou pour lui donner une valeur correspondant à l'indisponibilité de la ressource partagée, lesdites étapes de test et de positionnement de réservation se déroulant à la suite l'une de l'autre sans interruption.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend, lorsque ledit processus libère la ressource réservée à l'étape précédente, une étape de libération de la ressource partagée concernée par une entité (V) dite de libération de ressource comprenant la modification du verrou pour lui donner une valeur correspondant à la disponibilité de la ressource partagée, ladite étape de positionnement de libération étant non interruptible.

3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce qu'il comprend avant les étapes de test et de positionnement, une étape de contrôle d'une valeur de vérification (4y) stockée dans des premiers moyens de stockage (4x) permettant de vérifier l'intégrité d'une zone mémoire (4x) contenant le verrou et de refuser l'accès à la ressource partagée concernée suivant le résultat du

contrôle, et en ce qu'il comprend une étape de mise à jour de la valeur de vérification (4y) dans le cas d'une modification du verrou lors de la réservation et de la libération de la ressource partagée concernée.

4. Procédé selon les revendications 1 et 2, caractérisé en ce que lesdites première (P) et seconde (V) entités sont constituées par des instructions dudit système embarqué (1) du type dit"machine", lesdites instructions machines étant non interruptibles.

5. Procédé selon les revendications 1 et 2, caractérisé en ce que lesdites première (P) et seconde (V) entités sont constituées à base de fonctions logicielles de type dit"primitive système", lesdites primitives posant des appels non interruptibles au dit système d'exploitation.

6. Procédé selon la revendication 5, caractérisé en ce que ladite donnée partagée ("Verrou") est constituée d'un bit pouvant prendre les valeurs logiques "0" et "1", et en ce que ladite valeur initiale est la valeur logique "0".

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que, pendant lesdites étapes de test et de réservation, chacun desdits processus posant une requête d'accès, sous la commande de ladite première entité (P), réserve plusieurs ressources partagées (Rx) en positionnant le verrou associé à chacune desdites ressources partagées à réserver (Rx) à une valeur correspondant à l'indisponibilité desdites ressources.

8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que ladite première entité (P) contrôle les droits d'accès du processus posant une requête d'accès à ladite ressource partagée (Rx) par comparaison entre des droits associés au dit processus et des données dites de sécurité, fixant les conditions d'accès à ladite ressource partagée (Rx), stockées dans une zone sécurisée desdits moyens de mémoire (12).

9. Système embarqué comportant au moins des moyens (11,12) de mémoire et des moyens de calcul sous la commande d'un système d'exploitation, ledit système embarqué étant multiprocessus et comportant des ressources partagées,

caractérisé en ce qu'il comprend, associés à chacune desdites ressources partagées (Rx), des premiers moyens de stockage (4x) d'une donnée partagée, appelée "verrou", associée à chacune desdites ressources partagées (Rx), susceptible de prendre des premier et deuxième états déterminés (Rx) représentatifs de la disponibilité desdites ressources partagées, et en ce que lesdits moyens de mémoire (11-12) stockent une première entité (P) dite de réservation de ressource destinée à coopérer avec lesdits premiers moyens de stockage (4x) de manière à tester le verrou, et si la ressource concernée est disponible à réserver ladite ressource en modifiant le verrou.

10. Système selon la revendication 9, caractérisé en ce que lesdits moyens de mémoire (11-12) stockent une seconde entité (V) dite de libération de ressource destinée à coopérer avec lesdits premiers moyens de stockage (4x) de manière à modifier le verrou lorsque la ressource concernée est libérée.

11. Système selon l'une des revendications 9 ou 10, caractérisé en ce qu'il comprend, associés à la zone mémoire (4) contenant lesdits premiers moyens de stockage (4x), des seconds moyens de stockage (4y) de valeurs de vérification (checksum) permettant de contrôler l'intégrité de la zone (4),

12. Système selon l'une des revendications 9 à 11, caractérisé en ce qu'il est constitué par une carte à puce (1).

13. Système embarqué comportant au moins des moyens (11, 12) de mémoire et des moyens de calcul sous la commande d'un système d'exploitation, ledit système embarqué étant multiprocessus et comportant des ressources partagées, caractérisé en ce qu'il consiste à mettre en oeuvre le procédé selon l'une des revendications 1 à 8.

14. Programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une des revendications 1, 2, 3 ou 5 lorsque ledit programme est exécuté sur un système embarqué.