FR2829847A1 - Controlling access to shared resources, especially on a chip card, using a locking flag that is set and reset using two different primitive systems, thus ensuring that a resource cannot be accessed simultaneously by two processes - Google Patents

Abstract

Method for controlling access to a shared resource (Rx) by a process in a chip card, where two or more processes can request access to the resource at the same time. Accordingly each resource has a lock bit that is initially set to state 0. When a process requests a resource it can access it when its value equals 0. It is then set to 1 to prevent access by another process. A second system is required to clear the value and reset it to 0. The invention also relates to a corresponding system and computer program.

Description

<Desc / Clms Page number 1>

METHOD FOR CONTROLLING ACCESS TO SHARED RESOURCES IN AN ONBOARD SYSTEM AND ON-BOARD SYSTEM FOR IMPLEMENTING SUCH A METHOD
The invention relates to a method for controlling access to shared resources in an embedded system with an electronic chip.

 The invention more particularly relates to an embedded system of the type called "multiprocess" or "multitasking", having to manage access to shared resources. For simplicity, the term "multi-process" will be used alone in the following.

 The invention also relates to an embedded system for implementing such a method.

 The invention applies more particularly to a smart card.

 In the context of the invention, the term "embedded system" must be understood in its most general sense. It concerns in particular all kinds of light terminals equipped with an electronic chip, and more particularly the smart cards themselves. The electronic chip is itself equipped with recording means (memory) and digital data processing, for example a microprocessor for the latter means. In all cases, the computing power and the resident storage capacity in an embedded system are relatively limited, compared to a host system of the embedded system, for example a microcomputer. The comparison is even more unfavorable if we consider more powerful systems: local network servers, so-called "mini" systems or large systems called "mainframes".

 Still within the scope of the invention, the term "resources" refers to computer resources present in the embedded system, indistinctly of the software or hardware type. More specifically, it will be hereafter, shared resources, that is to say that can be made available to at least two competing processes.

 To fix ideas, and without limiting in any way its scope, we will place below in the case of the preferred application of the invention, namely smart card-based applications, unless mentioned opposite.

<Desc / Clms Page number 2>

 In a multi-process system, a particular problem arises if several processes access the same shared resource at the same time.

We will consider the following simple example to illustrate in a non-limiting way this problem:
Two applets selectable at the same time, or "applets" according to the English terminology, are an example of multiprocess. An example of a shared resource is the memory of the smart card, or at least a part of that memory.

 The two aforementioned applets may for example consist of so-called "electronic wallet" applications. If these two applets interrogate at the same time the same bank account to know if a bit rate is possible, in the absence of access control, they both get the same answer (for example that there remains 1000F), and they both accept the requested rate (for example 800F each). It follows that the account in question will become debtor (in this case up to: -600 F), whether this type of transaction is authorized or not.

 It is easy to see that this problem can exist in many other fields.

 For more powerful computer systems, it is possible to provide provisions to avoid this type of problem, even if they are "greedy" in computing resources. This is not the case for smart cards (or more generally embedded systems) which are provided, by nature, limited computing resources as previously recalled. Furthermore, in the known art, this problem did not arise because standard applications based on smart cards do not support a multiprocess environment. This is the case, in particular, for one of the most used computer languages for this kind of application, namely "Java Card" (registered trademark).

 To solve this problem, one could think of the following simple solution which consists in associating a so-called shared variable with each shared resource.

 Still in the example described above (application of electronic wallet), to fix the ideas, it is assumed that the shared resource

<Desc / Clms Page number 3>

 either a byte stored in a semi-fixed area of the memory of the smart card, for example in "EEPROM" (for "Electrically Erasable Programmable Read Only Memory" or read-only memory re-programmable by electrical erasure).

It is further assumed that this byte contains the balance of the bank account of the holder of the smart card. We then associate a variable that we will call "lock" (1 bit) to this shared resource or flag, and initialize it for example to the value "0".

 The mechanism of the operations is as follows: a / if the variable "lock" = 1, then the shared resource is in use and it is necessary that it is released; b / if the variable "lock" = 0, then the shared resource is free. The "lock" variable is forced to "1" to indicate that the shared resource is in use.

 Nevertheless, there is still a risk. Indeed, it is now assumed that the first process tests the variable "lock" which has the value "0" (indicating that it is free), and that this process is interrupted between the test of the variable "lock" and its positioning. to "1". If the second process then takes the "hand" and needs to access the shared resource, it tests the "lock" variable. This one is always worth "0". The second process then sets it to "1" and uses the shared resource. When "hand" is returned to the first process, the shared resource is no longer intact because it is likely to be in use. Indeed, the second process does not necessarily finish using this shared resource when the execution of the first process resumes.

 It can be seen that in this simple example, the solution envisaged for solving the problem, if it is also simple and therefore not very greedy in computing resources, does not give satisfaction, however, because it allows malfunctions.

 In addition, we also note that the fraudulent or accidental modification of the "lock" variable has dramatic consequences for the entire system. A "lock" inadvertently set to "1" while it should be "0" permanently prohibits access to this resource, while the opposite phenomenon allows access to a resource already in use.

<Desc / Clms Page number 4>

 The invention aims to overcome the disadvantages of the devices and systems of the prior art, some of which have just been recalled, while satisfying the needs that are felt and the specificities presented by embedded systems.

 In particular, in this context of applications: the calculations required and the memory space requirements induced by the process must remain small; the method must guarantee the integrity of the areas where the information is stored; and - the operating system, or "OS" according to the English terminology, which is provided with the smart card, or more generally the embedded system, must be able to continue to release a defective shared resource, so as not to block the system in its whole.

 The aim of the invention is therefore to set, in a multiprocess embedded system, a process for controlling simultaneous access of processes to a shared resource making it possible to prevent, when a first process uses a given shared resource, one or more other processes use this same shared resource until the first process has fully released it.

 To do this, the method according to the invention provides access management to the same shared resource organizing a mutual exclusion. In other words, two competing requesting processes, having applied for access to the same resource, are mutually exclusive.

 According to the method of the invention, each shared resource is associated, as before, with a shared variable forming a lock or flag. For simplicity, this variable will be called "lock" below. In a preliminary phase, this variable is forced to a first predetermined initial state.

 According to another characteristic of the method according to the invention, the successive operations of testing and positioning of the aforementioned locks are made uninterruptible.

 To do this, a first software function, of so-called system primitive type, is provided which performs the two preceding operations, test and

<Desc / Clms Page number 5>

 positioning the lock in a second determined state, indicating the unavailability of the associated shared resource. This primitive is uninterruptible.

 A second software function, also of the so-called system primitive type, is provided which makes it possible to release the shared resource by resetting the lock. This primitive is also uninterruptible.

 The implementation of the method according to the invention can be carried out by resorting to two large families of solutions, namely a hardware-type implementation and a software-type implementation.

 Regarding the hardware solution, it is expected that a single microprocessor machine instruction can perform the two operations recalled above (test and positioning). This arrangement makes it possible to completely solve the problem that the invention poses. Indeed, as it is known, a so-called machine instruction is, by definition, uninterruptible.

 However, such an instruction does not exist on all commercial microprocessors. It is therefore sometimes necessary to modify the set of microinstructions, which, for standard or standardized applications, has a disadvantage.

 A software solution can be implemented by providing that the test and positioning software function is a system call intended not to be interrupted by the system.

 According to another characteristic of the method according to the invention, the shared variables of the "lock" type associated with each shared resource are stored in memory areas whose integrity is ensured by a process of calculating checksum values (checksum).

 In a further variant of the invention, provision is furthermore made to control the access rights of a process to a shared resource, this advantageously within the execution routine of the first one. primitive, which performs the testing and positioning operations. To do this, it is verified that the process calling the routine has appropriate access rights to request manipulation of the shared resource.

<Desc / Clms Page number 6>

 In a further variant of the invention, it is also possible for the execution routines of the first and second primitives to simultaneously reserve the access of several shared resources to avoid a blocking between several processes, also called "deadlock" according to the Anglo-Saxon terminology.

 The main object of the invention is therefore a method for controlling access to shared resources in an embedded system comprising at least memory means and calculation means under the control of an operating system, said system being multiprocess , characterized in that it comprises the following steps when a process requests access to one of said shared resources: a step of testing a shared data item called a lock associated with each of said shared resources, the lock value; indicating the availability or unavailability of the resource concerned, by a resource reservation entity that makes it possible to refuse access to the shared resource concerned in the event of unavailability of said resource; a step of reserving the shared resource concerned if the test of the preceding step indicates the availability of said resource, by the resource reservation entity including the modification of the lock to give it a value corresponding to the unavailability of the resource; shared resource, said test steps and reservation positioning taking place one after the other without interruption.

 The invention also relates to an embedded system for implementing this method.

The invention will now be described in more detail with reference to the accompanying drawings, in which: FIG. 1 schematically illustrates the general architecture of a smart card;
Figure 2 schematically illustrates the mechanism of access control to a shared resource;

<Desc / Clms Page number 7>

 FIG. 3 illustrates in more detail the architecture of a smart card for implementing the method of controlling access of processes to shared resources according to the invention; and FIG. 4 is a flow chart showing the main steps of access to a shared resource by a process implementing the architecture of FIG. 3.

 One embodiment of a method for controlling access to a shared resource according to the invention will now be described in more detail with reference to FIGS. 1 to 4. As indicated, by way of nonlimiting example. and to fix the ideas, it will be placed in the case of the preferred field of application of the invention, namely applications based on smart cards.

 It seems first of all useful to briefly recall the general architecture of a smart card 1 that can be used in the context of the invention. Figure 1 schematically illustrates such an architecture. This comprises at least the following elements: a microprocessor or equivalent (microcontroller) 10 constituting digital data processing means, data storage means and programs, including in particular a RAM area or "RAM" ( "Random Access memory") 11 and a fixed or semi-fixed memory zone 12, for example of the "ROM" ("Read Only Memory") or "PROM" type ("Programmable Read Only Memory"), as well as circuits input-output signal "1/0" ("Input / Output") 13 communicating with the external medium, that is to say with the host terminal 2 of the smart card 1 (for example a microcomputer) .

These different elements communicate with one or more buses, represented (s) under a unique reference B. Generally, software applications, firmware, applets, or "applets" according to the English terminology, which we will call so generic programs, are stored in the fixed or semi-fixed memory 12, but can also be downloaded directly to the RAM 11 from the outside world (not shown), including the terminal 2, via the input-output circuits 13 .

 For an application to be executed, it is necessary to load all or part of its code into RAM 11. One or more processes

<Desc / Clms Page number 8>

 is (are) then launched (s). The smooth running of these processes, under the control of the microprocessor 10 and an operating system of the smart card 1, or "OS" ("Operating System" in the English terminology ") requires that resources computer hardware and software are made available to them, including, in the context of the invention, the shared resources if the smart card 1 is of the multi-process type as previously indicated.

 When a given requesting process makes a request to access a particular shared resource, it is necessary to control whether that process can actually access it.

 When the embedded system, in this case the smart card 1, is of the multi-process type, by definition several processes can run simultaneously. It is assumed, initially, that a resource, hereinafter called Rx, can be shared between two concurrent processes, hereinafter called P1 and P2, respectively. It is then necessary to check, when one of the two processes, for example P2, asks for access, if the shared resource Rx is not already in use by the other process, that is P1 in the example described. The index x is arbitrary and varies between 1 and n, where n is the maximum number of shared resources.

 Figure 2 schematically illustrates the architecture of an access control system. Two processes, P1 and P2, request to use an Rx shared resource. This request is filtered by an access control module 3, which can be software or hardware type.

 For example, if the P1 process queried first, the P2 process must be denied access to the Rx resource, and vice versa.

 For the access control to be carried out correctly, according to a first characteristic of the method according to the invention, each shared resource Rx is associated with a shared value called a lock, which will be called "lock" below and which is physically present in the form of any appropriate numerical data. In a preferred embodiment, since two distinct states are sufficient, each shared resource Rx is associated with a single binary element (bit), advantageously stored in a memory position.

<Desc / Clms Page number 9>

 alive (Figure 1) or in an independent register. It is also possible to associate, with each shared resource Rx, a flip-flop, for example of "Flip-Flop" type, or any other similar organ having two logical states.

 This bit serves as a flag indicating the availability or, on the contrary, the unavailability of the associated shared resource Rx. The initial value of the bit can be arbitrarily set to logic "0" ("Lock" = 0). The bit is initialized to this value during a so-called preliminary phase.

 Then, in later phases, which can be described as operational, when a process, for example P1, requests access to the resource Rx and it actually takes "the hand", the bit is switched to logical "1" ("Lock" = 1), indicating that the associated shared resource Rx is no longer available.

 If the second process, that is to say P2, in turn asks for access to the resource Rx, a test is performed on the "Lock" bit. In the present case, the value "1" of this bit indicates the unavailable state of the resource Rx and the process P2 will be denied the access requested.

 When the process P1 releases the resource Rx, the "Lock" bit is repositioned to its initial value "0", indicating that the associated shared resource Rx is available again.

 This mechanism is very simple to implement and implement.

However, as has been demonstrated, it allows, under certain conditions, unacceptable dysfunctions. It is not enough on its own.

 Also, according to another characteristic of the method according to the invention, the successive operations of testing and positioning of the aforementioned locks are made uninterruptible.

 To do this, the method according to the invention provides access management to the same shared resource Rx organizing a mutual exclusion of the requesting processes, P1 and P2.

 As such, according to a second characteristic of the method according to the invention, there are provided first and second functions, so-called system primitives, uninterruptible.

<Desc / Clms Page number 10>

 The first system primitive, which will be called hereinafter P, performs the first two operations, testing and positioning the "Logic" bit in logic state "1" (if the preceding test indicates that the "lock" is to "O"), indicating the unavailability of the associated shared resource. This primitive P is uninterruptible.

 The second system primitive, which will be called hereinafter V, makes it possible to release the shared resource Rx by resetting the "Lock" bit to the initial logic state "0". This primitive is also uninterruptible.

 The two primitives, P and V, are loaded in random access memory 11, advantageously from a predetermined location of the fixed memory 12 (FIG. 1). They both cooperate with the storage means of the "Lock" bit: content test and forcing at the value "a" or "1", as indicated above.

 This mechanism is still relatively simple to implement and implement, but, as has already been shown, it still allows, under certain conditions, unacceptable malfunctions.

 Indeed, the "lock" type variables are relatively sensitive data. A change in the value of these variables, whether voluntary or accidental, can compromise the operation of the system. Thus, these variables will have to be stored in memory areas whose integrity will be ensured, by means of checksum value calculations for example of the known Adler type.

 FIG. 3 schematically illustrates the architecture of a smart card 1 for implementing the access control method of a process, for example P2, with a shared resource, for example Rx. The latter can be indifferently software type (an applet for example as illustrated below) or hardware (memory area, etc.).

 FIG. 3 shows a memory position 4x, advantageously a location of the random access memory 11 (FIG. 1), storing the "lock" bit. By a conventional mechanism in itself, it is initialized in the logic state "0", during a preliminary phase, for example when powering the smart card 1. The index x means that the 4x memory position is

<Desc / Clms Page number 11>

 associated with the Rx shared resource. There are indeed as many lock bits as shared resources Rx (ie n as previously described). The corresponding memory locations, if using the RAM 11 (Figure 1) can be contiguous or distributed at predetermined addresses.

Nevertheless, all these memory locations, for storing the "lock" bits of each shared resource, are grouped together in a memory zone whose integrity is ensured by means of the calculation of checksum values.

 In a preferred embodiment, the "lock" type variables will be stored contiguously in a memory zone 4 whose integrity is ensured by means of the calculation of a single verification value covering the whole of the memory zone 4. This checksum value is stored in the memory zone 4y provided for this purpose.

 Two memory locations, 5 and 6, are also shown for storing the two aforementioned primitives, P and V, respectively.

 According to the method of the invention, when a requesting process, for example P2, requests access to the shared resource Rx, it is processed by a routine for executing the primitive P. First of all, , the check value 4y is checked to check the integrity of the memory area 4. If the check value is incorrect, access to the shared resource Rx is denied. In the opposite case, said primitive P then tests the logical state of the "Lock" bit (that is to say the contents of the memory location 4x where it is stored), and more generally the state of a digital datum constituting the lock value. If the lock bit is in the initial state ("lock" = 0), the shared resource Rx is free. An authorization is granted and is immediately made available to the P2 applicant process. The "Lock" bit is set to the "1" logic state by the "P" primitive. These two consecutive operations must be performed without it being possible to interrupt the progress.

 In the opposite case ("lock" = 1), this means that the shared resource Rx is in use by the process P1 (shown in dashed lines in FIG. 3). Access authorization is denied to the P2 process. It must wait for the release of the shared resource Rx.

<Desc / Clms Page number 12>

When this release occurs, the V primitive is informed and reposition the lock bit in the initial state ("Lock" = 0). This primitive is also uninterruptible.

Since all the variables of the "lock" type are stored in a memory zone 4 whose integrity is ensured by the calculation of a verification value, any modification of these variables necessarily implies the updating of the verification value 4y. Likewise, any read access to these variables involves verifying the verification value 4y in order to check the integrity of the "lock" type variables.

The flowchart of FIG. 4 illustrates the main steps of the access control method according to FIG.

In step 700, a request for access to the shared resource Rx is set by the process P2.

In step 701, the verification value is calculated and compared to the saved verification value 4y (FIG. 3). If the values are different, there is an integrity problem and access to the Rx resource is denied to the P2 process. If the values are identical, the system will then check if the resource is available, and this in step 702.

In step 702a the contents of the 4x memory position (FIG. 3) is tested, ie the value of the "lock" bit.

If the "Lock" bit is not in the initial state ("Lock" = 1, "NO" branch), it means that the Rx resource is already busy. Access to this resource is denied to the P2 process. On the other hand, if this bit is in the initial state ("Lock" = 0; "QUI" branch), access to the shared resource Rx is authorized and the "Lock" bit is set to "1" (step 702b ).

As has been indicated, these two successive test (702a) and latch positioning (702b) steps can not be interrupted, and, for this reason, have been shown in one and the same block in dotted lines in the diagram of FIG. 4.

Then, in step 703, after the modification of at least one "lock" variable, the verification value is again calculated and written in the memory zone 4y containing the saved verification value.

<Desc / Clms Page number 13>

 When the process P2 decides to release the shared resource Rx (step 704), the primitive V sets the "lock" bit to the logical state "0" (step 705), which indicates that the shared resource Rx is again free . The V primitive should not be interrupted until this operation is complete.

Then, in step 706, after resetting the "lock" variable, the verification value is recalculated and written in the memory zone 4y containing the saved verification value.

 An example application will now be described. Still in the context of the so-called electronic purse domain, three family bank accounts are considered. Each account constitutes a separate shared resource, for example variables recording the amount available in the aforementioned accounts, variables that will be called "Parent account", "Mother account", "Child account", respectively. It is assumed that several entities can have access to these different accounts, so to these shared resources. For example, these are applications that reside in a smart card owned by the three family members.

According to a first characteristic of the method of the invention, each shared resource is associated with a variable also shared lock that will be called: "Father Lock Bit", "Mother Lock Bit" and "Child Lock Bit". These variables are initialized by convention to the value "0". For example, the following table represents the initial values at a given moment:

<Tb>
<tb> Bit <SEP> Parent Lock <SEP> = <SEP> 0 <SEP> Associate <SEP> to .... <SEP> Parent Account <SEP> = <SEP> 50
<tb> Bit <SEP> Parent Lock <SEP> = <SEP> 0 <SEP> Associate <SEP> to .... <SEP> Parent Account <SEP> = <SEP> 40
<tb> Bit <SEP> Child Lock <SEP> = <SEP> 0 <SEP> Associated <SEP> to .... <SEP> Childrens <SEP> = <SEP> 10
<Tb>

If (P (Verrou-mère) == false) //ICI, le compte de la mère est en If an application wants to debit the mother's account, for example pass the purchase of a price book equal to a variable called "PRICE-BOOK", the corresponding code can be the following:

If (P (Mother Lock) == false) // HERE, the mother's account is in

<Desc / Clms Page number 14>

} 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". return error. RESOURCE ~ USED; It's being used by another entity} else {
ACCOUNT ~ mother = Mother account ~ PRICE + ~ BOOK;
V (lock)

} P and V are the primitives according to the method of the invention, "//" indicates a comment, "If"("if") is an instruction that tests the value of the "Mother lock" bit associated with the shared resource "Mother account" (step 702a) via the primitive P and "return error." RESOURCE-USED indicates that the resource is in use by another process as indicated by the comment. Otherwise ("else", always in step 702a and under the control of the primitive P), access is allowed and the bit lock "mother lock" is set to "1". The debit transaction is carried out under the control of the calling process, ie the amount "PRICE ~ BOOK" is debited from the account "Mother account", the available amount becomes: "Mother-account-PRICE-BOOK". Then the shared resource "Mother Account" is released. Under the command of the primitive V,! e "Lock" bit is re-initialized to "O".

The code above can be written in a more compact way by using a so-called "while" statement (which requires continuing until a prescribed condition is satisfied). Such a code is for example the following: while (P (Mother Lock) == false) {It DO NOTHING It As soon as the resource is released, we reserve it}
Parent account = Mother account - PRICE ~ BOOK;
V (lock); The expression "// as soon as the resource is released, we reserve it" is a simple comment and "// DO NOTHING" indicates that the process is put into

<Desc / Clms Page number 15>

 wait ("do nothing") as long as the resource "Comptemère" is used! another process. The primitives P and V perform the same tasks as before.

 An identical, or at least similar, mechanism is implemented if any process makes a request to access other accounts, ie other shared resources, "Account" and "Accountant", respectively. The corresponding associated lock bits are used for this purpose: "BitVerrouper" and "BitVerrouenfant".

 The solution that has just been described is of the type of what has been called "software".

 As an alternative, as also recalled in the preamble of the present description, it is possible to implement a solution of "hardware" type by replacing the primitives with so-called "machine" microinstructions, that is to say written in Assembler, non-interruptible by essence. However, as has been pointed out, this solution must be reserved for systems whose microinstruction set contains such primitives.

 Although, until now, only two competing processes have been considered, for the sake of simplification of the description, it goes without saying that processes larger than two can request access to the same shared resource Rx. If this last resource is available, the first requesting process will see its request satisfied. The following processes will be rejected according to the mechanism previously described or put on hold. Provisions that fall outside the strict scope of the invention may be adopted to then re-activate one of the processes put on hold, for example according to a "first-in, first-served" (or "FIFO") mechanism according to the English terminology. Saxon) or taking into account the priority levels associated with the processes, if several processes are waiting to be served.

 Similarly, in a further embodiment, it is also possible that the execution routines of the primitives P and V can simultaneously reserve the access of several shared resources, to avoid a deadlock or deadlock between several processes.

<Desc / Clms Page number 16>

 Indeed, it will be considered that the process P1 reserves a shared resource Ri and that the process P2 reserves a shared resource R2. It is also considered that before R1 and R2 are released, P1 needs R2 and P2 needs R1. It follows that in this situation, the two processes P1 and P2 are blocked, each waiting for a shared resource that can not be unblocked. In the context of the method of the invention, one solution to this problem consists in providing that the execution routine of the primitive P can reserve more than one shared resource at a time. To do this, it tests the different lock bits of the shared resources to be reserved and according to the test result reserves them by setting these bits to "1", or generally to a value different from the initialization value.

 The routine code of the primitive P will have to be slightly modified to support this mode of operation. However, this modification does not lead to a significant increase in the overall complexity of the process.

 In yet another embodiment, the method according to the invention also makes it possible to carry out a certain number of checks on the access rights to the resources within the execution routine of the primitive P. It is sufficient to verify that the process calling this routine has appropriate access rights to request manipulation of the requested shared resource. This can be achieved, in a manner well known per se, by consulting a file or a security database, advantageously registered in a secure area of the fixed memory of the smart card 1 (FIG. 1) and setting conditions for access to shared resources.

 From the foregoing, it is easy to see that the invention achieves the goals it has set for itself.

 The invention relates to a method for controlling access to a shared resource Rx by a process P1 in a smart card 1. Two processes P1, P2 or more can request access to a shared resource Rx at the same time. According to the invention, provision is made to each shared resource Rx a 4x memory position storing a so-called lock bit, set to "0" in an initial phase. It also reserves a memory position 4y containing a checksum value to preserve the integrity

<Desc / Clms Page number 17>

 4x memory areas. Each shared resource Rx is associated with a first resource reservation primitive 5-P which tests the state of the bit, and when it is at "0", sets it to "1" and grants access. Otherwise, it prohibits access. Each shared resource Rx is also associated with a second so-called 6-V resource release primitive which sets the bit to "0" when this resource is released. Both primitives are not interruptible. Before or after any modification of at least one "lock" bit, the verification value 4y is checked or updated.

 The invention also relates to a smart card 1 implementing the method.

 Thus, the invention notably makes it possible to reliably control access to a shared resource and to prohibit access to a second process (or several) as long as a first process has not fully released this resource.

 The method is therefore very suitable for applications using smart cards.

 It should be clear, however, that the invention is not limited to the only examples of embodiments explicitly described, particularly in relation to FIGS. 1 to 4.

 Nor is it limited, as has been indicated, only to smart cards, but more generally to any embedded system, which by nature has only limited computing resources.

 The present invention also relates to the computer program product directly loadable in the onboard system memory, comprising portions of software code for executing the steps of the previously described method when said program is executed in the onboard system.

Claims (14)

 1. A method for controlling access to shared resources (Rx) in an on-board computer system comprising at least memory means and calculation means under the control of an operating system, said system being multiprocess, characterized in it comprises the following steps when a process requests access to one of said shared resources (Rx): a step of testing shared data called a lock associated with each of said shared resources, the lock value; indicating the availability or unavailability of the resource concerned, by a resource reservation entity (P) for refusing access to the shared resource concerned in the event of unavailability of said resource; a step of reserving the shared resource concerned if the test of the preceding step indicates the availability of said resource, by the resource reservation entity (P) comprising modifying the lock to give it a value corresponding to the unavailability of the shared resource, said test and reservation positioning steps taking place one after the other without interruption. 2. Method according to claim 1, characterized in that it comprises, when said process releases the reserved resource in the previous step, a step of releasing the shared resource concerned by a so-called resource release entity (V) comprising changing the lock to give it a value corresponding to the availability of the shared resource, said release positioning step being uninterruptible. 3. Method according to one of claims 1 or 2, characterized in that it comprises before the test and positioning steps, a step of controlling a verification value (4y) stored in first storage means ( 4x) to check the integrity of a memory zone (4x) containing the lock and deny access to the shared resource concerned according to the result of the <Desc / Clms Page number 19>  control, and in that it comprises a step of updating the verification value (4y) in the case of a modification of the lock during the reservation and the release of the shared resource concerned. 4. Method according to claims 1 and 2, characterized in that said first (P) and second (V) entities are constituted by instructions of said embedded system (1) of the type called "machine", said machine instructions being uninterruptible. 5. Method according to claims 1 and 2, characterized in that said first (P) and second (V) entities are formed based on software functions of type called "system primitive", said primitives making uninterruptible calls to said system operating. 6. Method according to claim 5, characterized in that said shared data ("lock") consists of a bit that can take the logical values "0" and "1", and in that said initial value is the logical value. "0". 7. Method according to one of claims 1 to 6, characterized in that, during said test and reservation steps, each of said processes making an access request, under the control of said first entity (P), reserves several shared resources (Rx) by setting the lock associated with each of said shared resources to be reserved (Rx) to a value corresponding to the unavailability of said resources. 8. Method according to one of claims 1 to 7, characterized in that said first entity (P) controls the access rights of the process requesting access to said shared resource (Rx) by comparing rights associated said process and so-called security data, setting the conditions of access to said shared resource (Rx), stored in a secure area of said memory means (12). 9. Embedded system comprising at least memory means (11, 12) and calculation means under the control of an operating system, said embedded system being multiprocess and including shared resources, <Desc / Clms Page number 20>  characterized in that it comprises, associated with each of said shared resources (Rx), first storage means (4x) of shared data, called "lock", associated with each of said shared resources (Rx), likely to take first and second determined states (Rx) representative of the availability of said shared resources, and in that said memory means (11-12) store a first resource reservation entity (P) intended to cooperate with said first resource means storage (4x) so as to test the lock, and if the resource concerned is available to reserve said resource by modifying the lock.

10. System according to claim 9, characterized in that said memory means (11-12) store a second entity (V) said release of resource for cooperating with said first storage means (4x) so as to modify the lock when the resource is released. 11. System according to one of claims 9 or 10, characterized in that it comprises, associated with the memory zone (4) containing said first storage means (4x), second storage means (4y) of values of check (checksum) to control the integrity of the zone (4), 12. System according to one of claims 9 to 11, characterized in that it consists of a smart card (1). 13. Embedded system comprising at least memory means (11, 12) and calculation means under the control of an operating system, said embedded system being multiprocess and including shared resources, characterized in that it consists to implement the method according to one of claims 1 to 8. A computer program comprising program code instructions for performing the steps of the method according to one of claims 1, 2, 3 or 5 when said program is executed on an embedded system.