WO2001037085A1 - Procede de chargement d'applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d'execution correspondants - Google Patents

Procede de chargement d'applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d'execution correspondants Download PDF

Info

Publication number
WO2001037085A1
WO2001037085A1 PCT/FR2000/003193 FR0003193W WO0137085A1 WO 2001037085 A1 WO2001037085 A1 WO 2001037085A1 FR 0003193 W FR0003193 W FR 0003193W WO 0137085 A1 WO0137085 A1 WO 0137085A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
class
api
modules
classes
Prior art date
Application number
PCT/FR2000/003193
Other languages
English (en)
Inventor
Christian Goire
Jean-Paul Billon
Original Assignee
Bull Cp8
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull Cp8 filed Critical Bull Cp8
Priority to BR0007569-8A priority Critical patent/BR0007569A/pt
Priority to CA002360431A priority patent/CA2360431A1/fr
Priority to US09/889,416 priority patent/US6983460B1/en
Priority to JP2001539111A priority patent/JP3689368B2/ja
Priority to EP00981423A priority patent/EP1147467A1/fr
Publication of WO2001037085A1 publication Critical patent/WO2001037085A1/fr
Priority to HK02104110.5A priority patent/HK1042151B/zh

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G06Q20/35765—Access rights to memory zones

Definitions

  • the present invention relates to a method for loading applications into a multi-application embedded system provided with data processing resources, the corresponding embedded system, and the method for executing an application from a corresponding embedded system.
  • the present invention relates more particularly to the realization of firewalls between modules sharing the same memory space in systems embedded on portable multi-application objects using an intermediate pseudocode and an associated virtual machine.
  • PCMCIA cards or any other portable terminal. Thereafter we will use the term card to designate any of these portable objects.
  • the programming of embedded systems, previously carried out in assembler, is now possible in an advanced language like "Java”, and allows to facilitate and accelerate development
  • a smart card 10 includes an input and output system (1 1) connected to the microprocessor (14), a volatile memory RAM (12) (Random Access Memory ) a non-volatile memory constituted by a ROM read only memory (13) (Read Only Memory) and a programmable non-volatile memory (15) constituted by a flash RAM or EEPROM (Electrically Erasable Programmable Read Only Memory). All of these elements are connected to the microprocessor by a link BUS.
  • a smart card in the best of cases, using the new components currently existing, includes a ROM memory, an EEPROM memory of 32 kilobytes or kilo bytes, and a RAM memory of 2 Kilo Bytes.
  • the virtual machine of a conventional platform includes a pseudocode verifier, a dynamic class loader, a pseudocode interpreter which allows translation into machine code and a security manager.
  • the virtual machine comprises a part (30) outside the specific platform (40), called an off-platform virtual machine, comprising a converter (32), and a part (41) in the card constituting the specific platform (40), called on-board virtual machine (41) ("on-platform") including the pseudocode interpreter.
  • the source program (21) of the application is written, compiled in intermediate pseudocode by a compiler (22), and verified by a verifier (31) of intermediate pseudocode on a conventional station (20), then converted by the converter (32), placed on the same station (20) or another station.
  • the application is then downloaded to the volatile electrically programmable and possibly electrically erasable EEPROM (15) of the portable object or specific platform (40).
  • This loading is carried out by a loader comprising a part off platform called downloader (33) and a part on the specific platform called charger (42).
  • the virtual machine (41) of a specific platform (40), placed in ROM memory with the operating system (48) (Operating System) may include an intermediate pseudocode verifier, which is too heavy to be stored and / or executed in the portable object.
  • the specific platform (40) also does not contain a dynamic class loader. Indeed, for the field of application of the invention, on the virtual machine (30) off-platform, the verifier (31) verifies that the compiled classes are well formed and verifies the language violations specific to the description of the specific platform.
  • the converter (32) does the work required for loading classes and resolving references. The converter performs the static link of the classes, it resolves the symbolic references to the classes, methods and attributes already present on the map. It distributes the store and create data structures to represent classes, create static or native methods and attributes and initialize static variables.
  • the execution environment of the specific platform includes the on-board virtual machine ("onplatform") (41) limited to an interpreter, an API platform and the so-called native methods (43) or associated statics.
  • the API platform includes APIs (44) (Application Programming Interface) defining a set of classes, called system classes (45), and the calling conventions by which an application accesses the execution environment (RE). and static methods (43).
  • the static methods (43) execute the memory allocation, input and output, and cryptographic services of the card.
  • the interpreter of the on-board virtual machine of the card (41) serves as a support for the "Java" language, and reads the intermediate pseudocode sequentially, instruction by instruction.
  • Each standard instruction of this intermediate pseudocode is interpreted in the language of the microprocessor by the interpreter then executed by the microprocessor.
  • the standard instructions of the intermediate pseudocode make it possible to deal with advanced functions such as arithmetic processing and manipulation of objects.
  • the concept of object concerns computer objects such as lists, data tables or the like.
  • the so-called client classes (46) of the applications and the system classes (45) of the APIs are all loaded into the same memory space and are managed by means of a class table (47).
  • the virtual machine (41) is also responsible for managing the classes and objects and for enforcing the partitions or firewalls between the applications in order to allow secure sharing of the data, also called attributes, variables or fields.
  • an application of a specific platform can be activated directly by the execution environment (RE) when a selection Application Protocol Data Unit (APDU) issued by a service or terminal is received by the card.
  • RE execution environment
  • APDU Application Protocol Data Unit
  • the methods (NM1, NM2), respectively (NM3, NM4), and the attributes (NA1, NA2), respectively (NA3, NA4) are encapsulated in classes (NCI3), respectively (NCI2), which themselves are part of packages (Package 1), respectively (Package n) each grouping several classes.
  • a class can be public such as (NCI1 or NCI2) or private such as (NCI3) in relation to a package, which implies, in the latter case, that only classes of the same package can access this class.
  • the methods (example NM2) and the data (example NA1) of a class (NCI3) can be private compared to the class (NM2, NA1), which itself is private compared to the package (Package 1), or public with respect to the package (for example NM1, NA2) or to the class (for example NM4, NA4).
  • This restriction of visibility makes it possible to obtain flexible access between the different sets of packages (Package 1, Package n) stored in the same namespace, but has some drawbacks.
  • the classic or specific platform does not support the notion of subpackages badly.
  • the client classes of a large application must be distributed between different sub-packages which only represent different packages for the virtual machine. To share the resources between these sub-packages, these resources are necessarily declared public, thus making them visible from any other package.
  • the second means provided by the virtual machine of a classic platform is the notion of separation of namespaces.
  • the classes can be loaded, from directories of the local file system, called "ClassPath" previously declared as constituting the location of the system classes forming the API platform standard, or from other directories on the local file system or remote servers.
  • the client classes of an application outside of the "ClassPath", must be loaded by a specifically programmed class loader. This feature is particularly used for loading "Java” applications by "Java” enabled browsers.
  • loaders of different classes For each locator, commonly called URL (Uniform Resource Locator), a specific instance of class "application class loader" is used.
  • URL Uniform Resource Locator
  • the external name of a class is the assembly ⁇ Package Name> + ⁇ Class Name>.
  • a class is loaded, it is stored in an internal class table, and a reference to the class loader used to load this class is added as a prefix to the package name of the class.
  • the class name is then "Class Loader Reference> + ⁇ Package Name> + ⁇ Class Name".
  • the usual policy for class loaders is to search first in the system classes and in case of failure, to search among the class files present in the location where the loader can load the classes.
  • an application cannot directly access the client classes of another application loaded by a loader of different classes.
  • An application can access all the public resources of the public classes of ClassPath, but the classes of ClassPath cannot directly access the classes of an application although they can refer to instances of client classes of the application by converting them into a public type defined in the "Classpath".
  • An application cannot extend or modify system class packages from Classpath or any other application loaded by loaders of different classes.
  • the object of the present invention is to provide a solution providing the advantages of name separation in the context of embedded systems having a virtual machine in two parts, the static link diagram being performed by the off-platform part.
  • a first object of the invention is to propose a loading method making it possible to obtain robust firewalls between the applications while allowing cooperation between the applications and the possibility of upgrading the applications or of loading other applications.
  • This object is achieved by the fact that the method for loading applications on an embedded system according to the invention, comprising a execution environment including a virtual machine comprising an intermediate pseudocode-type language interpreter, application programming interfaces (API), from a station on which the application source code is written, compiled in pseudocode by a compiler, checked by a verifier, converted by a converter and loaded by a charger, is characterized in that
  • the conversion includes the realization of the static link of a plurality of sets of packages intended to be stored in the same name space on the on-board system, called modules, by assigning an identifier to each module (MID), and a number of reference to each class, to each method and to each attribute encapsulated in the classes of the module,
  • modules by assigning an identifier to each module (MID), and a number of reference to each class, to each method and to each attribute encapsulated in the classes of the module
  • the loaded modules are one or more application programming interface modules, called API module, comprising system classes or service modules each corresponding to an application, a reference to an external class being systematically interpreted by the virtual machine as a reference to an application programming interface module.
  • API module application programming interface modules
  • the loading of the modules on the on-board system comprises memorizing on the one hand at least one table representing the modules, the number associated, by the linker between 0 and n, with a module constituting the index of said module in the table, and on the other hand of a table memorizing the association of the index of the representation table with the identifier (MID) of said module, said table and the table being in non-volatile programmable memory, an external reference to an external module in the pseudocode being interpreted by the interpreter of the virtual machine as constituting an access index to the module equivalent to that of the table of modules.
  • MID identifier
  • the loading comprises the memorization, for each module, of a table of representation of its classes, comprising a reference to the index of its module and, for each class, a table of representation of the attributes and methods .
  • the modules are referenced in a single array of modules, the system classes are contained in a single API module, any reference to an external class in the pseudocode different from n will be interpreted by the virtual machine as a reference to said module API.
  • the classes being declared public, or in private package
  • the attributes and methods being declared protected, in private package or in private class
  • the numbering of the classes is carried out according to the order public classes then classes in private packages
  • the numbering of the attributes or methods is carried out by the converter according to the attribute attribute or method public, protected, in private package and in private class.
  • the system classes are contained in several API modules which can be loaded separately, the loader maintains in the programmable non-volatile memory two tables for representing the modules and two corresponding MID / IMi association tables, one for the API modules. and the other for non-API modules, the loader loading the modules into one of the two arrays according to the nature of the module specified in the header thereof, any external reference of a module in the module array being interpreted as a reference to the API module index.
  • the static connection of a module is carried out such that the reference to a class external to a non-API module in the intermediate pseudocode is an index in a table of the header of the module, each entry of which is an identifier (MID) of a referenced API module, the loading of said module on the target platform comprising the replacement of said reference by the number of the API module index obtained from the identifier (MID) of the association table of API modules.
  • MID identifier
  • Another object of the invention is to propose a corresponding on-board system.
  • the embedded system comprising a virtual machine and an API platform including application programming interfaces, a fixed non-volatile memory, a programmable or modifiable non-volatile memory, and a random access memory
  • the programmable non-volatile memory comprises at least one API module comprising system classes and service modules, at least one module representation table, in which the modules are indexed and a table associating the index of a module of the representation table with the identifier of said module, each module comprising a table of representation of the classes, in which the classes are indexed and in which each class presents a reference to the index of its module, each class comprising an array of attributes and methods representation, in which the attributes and methods are indexed, the reference to a e method or an attribute being coded on at least three bytes corresponding to a reference to a class internal or external to the module, a reference external to the module constituting the index of the API module in the module table, a class number
  • the on-board system includes means for comparing the first byte of the three reference coding bytes to a method or to an attribute with a determined value n to decide whether it is an internal or external class.
  • the on-board system comprises a main module comprising the main program of the system.
  • the classes are indexed according to the order public classes then classes in private packages, and the attributes or methods according to the order attribute or method public, protected, in private package and in private class.
  • the programmable non-volatile memory comprises several API modules comprising system classes, two modules representation tables, one for the API modules and the other for the non-API modules and the main module, and two MID / IMi association tables each corresponding to a module representation table.
  • the on-board system comprises an access manager class "Access manager" of an API module comprising a method making it possible to create an instance of a service module, via the main module, said class having protection prohibiting him from having more than one instance.
  • Another object of the invention is to propose a method for executing an application present on a multi-application embedded system.
  • This object is achieved by the fact that the method for executing an application of a multi-application embedded system, comprising an execution environment including a virtual machine comprising a language interpreter of intermediate pseudocode type, and interfaces for Application programming (API), is characterized in that, during the execution of the intermediate pseudocode of a service module, corresponding to an application, referenced in a module table, the reference to a method or an attribute in the pseudocode, coded on at least three bytes corresponding to a reference to a class internal or external to the module, a class number and a method or attribute number, a reference external to the module is interpreted by the machine virtual as a reference to the index of an API module in the table of the API module (s).
  • API Application programming
  • the execution environment accesses the input class of a main module comprising the main program of the system, the main module installs an instance of a special class "Access Manager", of an API module, managing access to a service module and uses a method of this class allowing to create an instance of the input class of the module service requested, via an association table of the identifier to the index of the module in an array in which the module is referenced, the instance being returned by the method to the main program.
  • a special class "Access Manager" of an API module managing access to a service module and uses a method of this class allowing to create an instance of the input class of the module service requested, via an association table of the identifier to the index of the module in an array in which the module is referenced, the instance being returned by the method to the main program.
  • FIG. 1 shows schematically the different elements necessary for loading a portable object according to a first embodiment
  • FIG. 2 shows schematically the different elements necessary for loading a portable object according to a second embodiment
  • FIG. 3 shows the internal representation of a module
  • FIG. 4a shows the conventional diagram of a smart card
  • FIG. 4b shows the system necessary for the constitution of a virtual machine on board a smart card according to the prior art
  • Figure 4c shows the structure of the classes of an application. The method will be described, in conjunction with Figures 1 to 3, without limitation, in the case of the implementation of the invention in an on-board system, for example of a specific type consisting of a smart card or an object similar laptop.
  • the designation byte code or byte code type program covers any pseudocode or intermediate program.
  • the portable object constitutes, for example, a smart card and has a structure similar to that described above with reference to FIGS. 4a and 4b, and in particular comprises a RAM, ROM and EEPROM memory.
  • the specific platform (60) and a conventional station (80) are represented in FIG. 1.
  • the specific platform (60) has in ROM, an execution environment (RE) comprising APIs (62) and a embedded virtual machine (61) ("onplatform").
  • the specific platform (60) is shown in FIG. 1, as comprising all of the ROM and EEPROM memories. It should be noted that the specific platform (60) more specifically designates the execution environment (RE) and the elements present in EEPROM memory.
  • the portable object has an Operating System (63) in ROM.
  • the APIs (62), present in ROM memory constitute the basic APIs of the API platform, loaded with the on-board virtual machine for the operation thereof.
  • the non-portable part (90) of the virtual machine comprises an intermediate pseudocode verifier (91), a converter (92) and possibly a signer (94).
  • the signer issues a signature to validate the passage through the verifier and the converter. This signature will be verified by the portable object at the time of loading.
  • the loading into EEPROM of applications or new APIs to complete the basic APIs is carried out by a charger which can be composed of two parts, a part excluding portable object that can be installed in the virtual machine excluding portable object (90), called downloader (93), and a part on the specific platform, called loader (68).
  • the specific platform (60) comprises two special modules, an API module (65) and a main module (66).
  • the other modules are called service modules (67).
  • Each module corresponds to a set of packages which will be stored in the same namespace.
  • the API platform designates the basic APIs (62) and the set of system classes that define the API module (65) or module of the API platform.
  • the main module includes the main class defining the main program.
  • Each module, except the API module (65), has a unique, specific class, called "Entry Class", which constitutes the access point to the module. For the main module, this "Entry Class" is the main class (CP), the one that contains a static method called "main”.
  • service modules it is a class with only one constructor without parameters and implementing a special public interface, called "service" defined in the API platform.
  • the loading of an application corresponds to the loading of a service module.
  • Each module receives a specific identifier.
  • Such an identifier which is called MID, can for example be a number, a character string, or an array.
  • the identifier is a character string.
  • the module downloader (93) with the charger (68) maintains, when loading new service modules, a table (TRM) (69) of representation of the modules.
  • the number associated with a module is the index (IM) of this module in the table.
  • the loader (68) also maintains a table (70) associating the index (IM) with the identifier (MID) of each module.
  • the API module systematically receives the number 0 for the IMo index, and the main module for the IMi index the number 1.
  • the header of each module includes an indicator allowing the loader to determine the nature of the module, "main", “service” modules or "API” module.
  • the charger (68) can only charge the modules authorized to reside on the portable object, i.e. only the modules having a signature known to the portable object.
  • the charger (68) therefore comprises means of verifying the signature of a module received, of comparing it with the known signature of the portable object and in the event of a negative comparison of blocking the loading.
  • the source program (81) of an application is written and then compiled by a compiler (82) and then verified by the verifier (91).
  • linker linker
  • NCI a number for each class of a module
  • NA a number (NA) for each attribute in a class.
  • the reference to a method or an attribute of a class will thus be coded in the linked pseudocode of the methods of the module on two bytes or bytes.
  • the pseudocode will contain these two bytes ⁇ NCI> for the class and ⁇ NA> for an attribute or ⁇ NM> for a method.
  • the internal representation of an API module (65), of a main module (66) or of a service module (67), will contain a table (TRC) of class representation; the number (NCI) associated by the linker, outside the on-board system, with each class is the index (ICi) of the representation of this class in the table (TRC). Each class also has a reference to the index (IMi) of its module.
  • the representation of each class contains an array of method representations (TRMe) and an array of attribute representations (TRA) belonging to the class.
  • the number (NM), associated by the linker, outside the on-board system, to each method is the index (IMi), of the representation of this method in the table (TRMe), and the number (NA), associated by the linker, outside the on-board system, with each attribute is the index (lAi), of the representation of this attribute in the table (TRA).
  • a module to be able to refer only to its own classes and to the system classes of the API platform, the system classes corresponding to the "ClassPath" classes of a classic platform.
  • an internal (II) or external (IE) indicator is added to the reference to a method or attribute.
  • the resolved reference is then coded on three bytes: ⁇ IE / II> ⁇ NCI> ⁇ NM> or ⁇ IE / II> ⁇ NCI> ⁇ NA>
  • the value n of the first byte ⁇ IE / II> corresponds to an internal reference ⁇ ll> to the module and any other value for the first byte corresponds to an external reference ⁇ IE> to the module.
  • the linker of the converter (92) of the virtual machine excluding portable object (90) first connects the API module (65), which does not have external references ⁇ IE> in its pseudocode, and produces a layout or arrangement, corresponding to a plan of symbolic names of its classes and their methods and attributes. When linking the other modules, this layout will be used to establish external references to system classes of the API module (65).
  • the internal reference to a class of a module does not require any prior knowledge of the namespace that will be assigned to the module.
  • the fact of not a priori defining a fixed namespace during the conversion phase makes it possible to speed up the resolution of the references and to determine the namespace of a module during the loading, after the conversion phase .
  • the virtual machine when interpreting a reference to an attribute or method in the pseudocode, uses the three indexes ⁇ IE / II> ⁇ NCI> ⁇ NM> or ⁇ IE / II> ⁇ NCI> ⁇ NA> in cascade.
  • the index ⁇ NCI> determines the desired entry in the table of classes (TRM) of the module, then the last index ⁇ NM> or ⁇ NA> gives the desired entry in the table methods (TRMe) or the attribute table (TRA).
  • the API module includes a special class (64), called class "access manager” or “Access Manager”, which includes a native method (getServiceInstance) whose role is to render an instance object of the input class of the module service request, from the module identifier (MID).
  • This method uses the MID / lmi association table (70) to find out the index of the module requested in the module table (69) and then creates an instance of the input class for this module, which instance is returned by the method.
  • the class "Access Manager” (64) is protected by construction by a method consisting in prohibiting that this class has more than one instance.
  • This method (getServiceInstance) belongs to the main program contained in the main module.
  • the main module which will be activated first when using the portable object creates an instance and only one of the class "Access Manager", which allows you to use the getServiceInstance method, but prohibits any other service from creating another instance to use this method.
  • the execution environment accesses the input class (EC) of the main module and activates its input method (main).
  • the main module being the first activated, proceeds to the installation of an instance of the class "Access manager" before any other service does so, since to activate other services, the main module must already have such an instance of the access class.
  • This simple device makes it possible to reproduce the protective effect linked to the concept of the namespace of a classic platform.
  • the simple fact of loading a service module in the table of modules and that the presence in the pseudocode of any external reference is interpreted by the virtual machine as a reference to the API module, makes this module completely inaccessible directly by the other modules, creating thus a total firewall.
  • This first embodiment provides the advantages of a firewall provided by the separation of namespaces in the context of a virtual machine in two parts.
  • this embodiment is not very flexible and has two drawbacks.
  • FIG. 2 represents a second embodiment allowing the evolution of the API platform.
  • the API platform is made up of several API modules (100) which can be loaded separately, instead of being made up of a single API module.
  • the downloader (93) and the virtual machine share two tables of modules and two MID / index association tables instead of one of each, a table (101) and an association table (102 ) for API modules and a table (103) and an association table (104) for non-API modules, corresponding to the service module (67) and the main module (66).
  • Each module has in its header an indicator indicating its "Service” or "API” nature allowing the loader to load the module in the table (101) of API modules or in the table (103) of non-API modules. This indicator is placed in the header of the module during the compilation phase by the converter.
  • the firewall formed by the separation of the namespace is only present between non-API modules. Any external reference to a service module will be interpreted by the interpreter of the on-board virtual machine as an index to the table of the API module.
  • API modules (100) will be numbered from 0 to 254 at most, 0 being by example the index of a module called primary API, which contains all the native methods. In accordance with the convention described above, this allows at most 255 (n) different modules in the API platform.
  • the reference to a method or attribute in the pseudocode is: "IE / II> ⁇ NCI> ⁇ NM / NA"
  • the value 255 (n) for the first byte (byte) will indicate, as in the first embodiment, an internal reference to the module. Each value other than 255 will indicate an external reference to a specific module (100) in the API module table of the API platform.
  • the pseudocode of a module comprises a header presenting a table of referenced modules used to link the current module. This table of referenced modules comprises at most 255 entries, each entry corresponding to the identifier (MID) of an API module (100). The first byte of an external reference in the pseudocode will then be an index in this table.
  • the index numbers associated with API modules (100) will be known and thus each first byte of an external reference will be replaced by the number index associated with the API module referred using the MID / IMi association table (102) of the API modules (100).
  • This replacement is the only link operation performed on the specific platform, by the loader (68), the MID / IMi association table (102) being used only to perform this link operation.
  • the table (101) of API modules includes a specific module (105), called “API Access” module which includes a native method (getServiceInstance) in a class "access manager” or “Access Manager” whose role is to render an instance object of the input class of the requested service module.
  • This method uses the MID / IMi association table (104) to find out the index of the service module requested in the table (103) of non-API modules and then creates an instance of the input class of this module which is returned by the method to the main program.
  • the recommended security policy is to make the "Access Manager” class a protected class whose constructor and methods are declared protected.
  • the "API Access” module (105) includes a protection consisting in prohibiting that the "Access Manager” class has more than one instance.
  • This method is reserved for the main program contained in the main module (66).
  • the main module which is activated first creates an instance of the Access manager module, which allows it to use the getServiceInstance method, but prohibits any other service from creating another instance to use this method.
  • the main module can create instances of services.
  • Several methods can be used to obtain this protection consisting in prohibiting that the "Access manager" class has only one instance.
  • the constructor of the class can for example block the request to create an instance when one already exists and throws a security exception.
  • the execution environment (RE) accesses the input class of the main module (66) and activates its input method (main).
  • the main module being the first activated proceeds to the installation of an instance of the "Access Manager" class of the Access module before any other service does so.
  • this strict security policy can be modified by adding to the "Access Manager" class of the API Access module (105) public classes allowing any module to make requests there. These requests will be processed and controlled by the single instance created by the main module. These public classes include a static method for obtaining the single instance. A module having access to the instance object of the "Access Manager” class will be able to activate another service module and use it, but it will not be able to directly reference its classes, methods or attributes without being spotted by the virtual machine , since any external reference in the pseudocode is an internal reference to the module or an external reference to an API module.
  • this double array of modules (101, 103) and association table (102, 104) system makes it easy to replace a single API module with several API modules that can be loaded separately.
  • the replacement of a single API module by several API modules makes it possible to extend the API platform with new modules, without modifying the assembly of modules already loaded, without changing the security offered by firewalls.
  • these two embodiments are not compatible; the modules must be preloaded specifically for one or the other of the embodiments, the pseudocode relating to one of the embodiments not being portable on a platform implementing the other embodiment.
  • the interpreter of the virtual machine differs from one embodiment to another.
  • the virtual machine only manipulates a single table and an association table: the first byte of a reference will be interpreted by the virtual machine as an internal reference for any value equal to n and as a external reference to the single API module for any value other than n.
  • the virtual machine manipulates two tables and two association tables: the first byte of a reference in the pseudocode will be interpreted by the virtual machine as an internal reference to the module for any value equal to n and any a value other than n will be taken directly as an index in the API module table.
  • the interpreter of the virtual machine comprises means for comparing the first byte of the three bytes of coding of a reference to a method or to an attribute.
  • n decides whether it is an internal or external class of the module.
  • the numbering of the API modules can be determined at the time of loading to definitively and very simply fix the external references in the pseudocode.
  • the same mechanisms are used to handle both types of modules, although the way they are used and the security provided is quite different. Any module can freely access API modules since their classes are system classes.
  • the use of the modular approach is used with service modules to provide a rigorous firewall to protect these modules from direct access.
  • the method according to the invention can be carried out on all types of portable object having low resources, such as for example, 16 KB of ROM memory, 8 KB of EEPROM memory and 256 k of RAM memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

La présente invention concerne un procédé de chargement d'applications dans un système embarqué multi-application, le système embarqué correspondant, et le procédé d'exécution d'une application du système embarqué. Le procédé de chargement d'applications sur un système embarqué comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, des interfaces de programmation d'application (API), à partir d'une station sur laquelle le code source de l'application est écrit, compilé en pseudocode, vérifié et converti, se caractérise en ce que la conversion comprend la réalisation de la liaison statique d'une pluralité d'ensemble de paquetages destinés à être stockés dans le même espace nom sur le système embarqué, appelés modules, et constituant un module d'interface de programmation d'application ou un module de service correspondant à une application, et consiste à attribuer un identificateur à chaque module (MID), et un numéro de référence à chaque classe (NCI), à chaque méthode (NM) et à chaque attribut (NA). La référence à une méthode ou un attribut, dans le pseudocode lié d'un module est codée sur trois multiplets constitués par un indicateur indiquant la référence à une classe interne (II) ou externe (IE) au module, le numéro de la classe (NCI) et soit le numéro de la méthode (NM) soit le numéro de l'attribut (NA), une référence (IE) à une classe externe étant systématiquement interprétée par la machine virtuelle comme une référence à un module d'interface de programmation d'application.

Description

PROCEDE DE CHARGEMENT D'APPLICATIONS DANS UN SYSTEME EMBARQUE MULTI-APPLICATION MUNI DE RESSOURCES DE TRAITEMENT DE DONNEES, SYSTEME, ET PROCEDE DΕXECUΗON CORRESPONDANTS
5 La présente invention concerne un procédé de chargement d'applications dans un système embarqué multi-application muni de ressources de traitement de données, le système embarqué correspondant, et le procédé d'exécution d'une application d'un système embarqué correspondant.
10 La présente invention concerne plus particulière la réalisation de pare-feu entre modules partageant le même espace mémoire dans des systèmes embarqués sur des objets portables multi-application utilisant un pseudocode intermédiaire et une machine virtuelle associée.
La technologie "Java" (marque déposée) introduite par la société
15 "Sun" est basée sur un langage de programmation orienté objet "Java" et une machine virtuelle associée. Cette technologie a été développée sur des stations ou PC (Personal Computer), appelées ci-après plate-forme "Java" classique, possédant une puissance CPU et une mémoire importante de l'ordre du méga byte ou mégaoctet.
20 Depuis quelques années, les concepts de la technologie "Java" ont été repris et adaptés pour fonctionner sur des systèmes embarqués dans des objets portables, par exemple au format de carte de crédit ou micromodule SIM incorporant un microprocesseur et appelée communément carte à puce, ou encore de téléphones portables GSM (Global System for
25 Mobile Communication), cartes PCMCIA ou tous autres terminaux portables. Par la suite nous utiliserons le terme carte pour désigner l'un quelconque de ces objets portables. La programmation des systèmes embarqués, jusqu'ici réalisée en assembleur, est désormais possible dans un langage évolué comme "Java", et permet de faciliter et d'accélérer le développement
30 d'applications clientes. Ce nouveau type de plate-forme spécifique aux systèmes embarqués d'un objet portable, appelé ci-après plate-forme spécifique, constitue un sous-ensemble de la plate-forme classique. Les différences résultent du fait de l'environnement réduit des systèmes embarqués. De manière classique, tel que représenté à la figure 4a, une carte à puce (10) comprend un système d'entrée et de sortie (1 1 ) relié au microprocesseur (14), une mémoire volatile RAM (12) (Random Access Memory) une mémoire non volatile constituée par une mémoire morte ROM (13) (Read Only Memory) et une mémoire non volatile programmable (15) constituée d'une flash RAM ou EEPROM (Electrically Erasable Programmable Read Only Memory). L'ensemble de ces éléments est relié au microprocesseur par un BUS de liaison. A titre d'exemple, une carte à puce comprend dans le meilleurs des cas, en utilisant les nouveaux composants actuellement existants, une mémoire ROM, une mémoire EEPROM de 32 kilooctets ou kilo bytes, et une mémoire RAM de 2 Kilo Bytes.
Dans un système "Java" classique, une application est écrite sur une station ou PC. Son code source est compilé dans un pseudocode intermédiaire, appelé "Java Byte Code" ou byte code, qui est indépendant du code machine de la plate-forme utilisée. L'application est ensuite téléchargée sur la plate-forme cible ou plate-forme "Java" classique. L'application chargée, constituée d'un ensemble de classes dites classes clients dont les méthodes ont été compilées dans le pseudocode, s'appuie sur les interfaces de programmation applicatives ou Interface pour la Programmation d'Application ou AP! (Application Programming Interface). Les interfaces de programmation applicatives permettent d'uniformiser l'interface utilisateur, de contrôler un éditeur, un clavier ou une imprimante par exemple. La machine virtuelle d'une plate-forme classique comprend un vérifieur de pseudocode, un chargeur dynamique de classe, un interpréteur de pseudocode qui permet la traduction en code machine et un gestionnaire de sécurité. La principale différence entre une machine virtuelle classique et une machine virtuelle d'un système embarqué, appelée machine virtuelle spécifique, est due au fait que la machine virtuelle d'un système embarqué est décomposée en deux parties séparées. Suivant la figure 4b, la machine virtuelle comprend une partie (30) hors de la plate-forme spécifique (40), appelée machine virtuelle hors plate-forme ("off-platform"), comprenant un convertisseur (32), et une partie (41 ) dans la carte constituant la plate-forme spécifique (40), appelée machine virtuelle embarquée (41 ) ("on-platform") incluant l'interpréteur de pseudocode.
Ainsi, dans le cas d'une plate-forme spécifique, le programme source (21 ) de l'application est écrit, compilé en pseudocode intermédiaire par un compilateur (22), et vérifié par un vérifieur (31 ) de pseudocode intermédiaire sur une station (20) classique, puis converti par le convertisseur (32), placé sur la même station (20) ou une autre station. Après un éventuel passage par un signeur (34), l'application est ensuite téléchargée sur la mémoire volatile programmable électriquement et éventuellement effaçable électriquement EEPROM (15) de l'objet portable ou plate-forme spécifique (40). Ce chargement est effectué par un chargeur comportant une partie hors plate-forme appelée téléchargeur (33) et une partie sur la plate-forme spécifique appelée chargeur (42). Contrairement à ce qui existe sur une plate-forme classique pour une station, la machine virtuelle (41 ) d'une plate- forme spécifique (40), placée en mémoire ROM avec le système d'exploitation (48) (Operating System) ne peut comporter de vérifieur de pseudocode intermédiaire, celui-ci étant trop lourd pour être stocké et/ou exécuté dans l'objet portable. La plate-forme spécifique (40) ne contient pas non plus de chargeur dynamique de classes. En effet, pour le domaine d'application de l'invention, sur la machine virtuelle (30) hors plate-forme, le vérifieur (31 ) vérifie que les classes compilées sont bien formées et vérifie les violations de langage spécifiques à la description de la plate-forme spécifique. Le convertisseur (32) effectue le travail requis pour le chargement des classes et la résolution des références. Le convertisseur effectue la liaison statique des classes, il résout les références symboliques aux classes, méthodes et attributs déjà présents sur la carte. Il répartit le stockage et crée les structures des données pour représenter les classes, crée les méthodes et attributs statiques ou natifs et initialise les variables statiques.
L'environnement d'exécution de la plate-forme spécifique (Runtime Environment ou RE) comprend la machine virtuelle embarquée ("onplatform") (41 ) se limitant à un interpréteur, une plate-forme API et les méthodes dites natives (43) ou encore statiques associées. La plate-forme API comprend les API (44) (Application Programming Interface) définissant un ensemble de classes, dites classes système (45), et les conventions d'appel par lesquelles une application accède à l'environnement d'exécution (RE) et aux méthodes statiques (43). Les méthodes statiques (43) exécutent les services d'allocation de mémoire, d'entrée et sortie, et cryptographique de la carte.
L'interpréteur de la machine virtuelle embarquée de la carte (41 )(on- platform), sert de support au langage "Java", et lit de façon séquentielle le pseudocode intermédiaire, instruction par instruction. Chaque instruction standard de ce pseudocode intermédiaire est interprétée dans le langage du microprocesseur par l'interpréteur puis exécutée par le microprocesseur. En règle générale, les instructions standards du pseudocode intermédiaire permettent de traiter des fonctions évoluées telle que le traitement arithmétique et la manipulations d'objets. La notion d'objet concerne les objets informatiques tels que listes, tableaux de données ou analogues. Les classes dites clients (46) des applications et les classes systèmes (45) des API sont toutes chargées dans le même espace mémoire et sont gérées par l'intermédiaire d'une table de classe (47).
La machine virtuelle (41 ) est également chargée de gérer les classes et objets et de faire respecter les séparations ou pare-feu entre les applications afin de permettre un partage sécurisé des données, appelées également attributs, variables ou champs (fields). Dans le cas d'un objet portable de type carte à puce, une application d'une plate-forme spécifique peut être activée directement par l'environnement d'exécution (RE) lorsqu'une APDU (Application Protocol Data Unit) de sélection émise par un service ou terminal est reçue par la carte.
Afin de restreindre l'accès aux données entre les parties de code partageant le même espace mémoire, une des méthodes classiques sur une plate-forme classique est basée sur la restriction explicite de visibilité déclarée dans le code source. Suivant la figure 4c, les méthodes (NM1 , NM2), respectivement (NM3, NM4), et les attributs (NA1 , NA2), respectivement (NA3, NA4) sont encapsulés dans des classes (NCI3), respectivement (NCI2), qui elles-mêmes font partie de paquetages (Paquetage 1 ), respectivement (Paquetage n) regroupant chacun plusieurs classes. Une classe peut être publique telle que (NCI1 ou NCI2) ou privée telle que (NCI3) par rapport à un paquetage, ce qui implique, dans le dernier cas, que seules les classes du même paquetage peuvent accéder à cette classe. Les méthodes (exemple NM2) et les données (exemple NA1 ) d'une classe (NCI3) peuvent être privées par rapport à la classe (NM2, NA1 ), qui elle-même est privée par rapport au paquetage (Paquetage 1 ), ou publiques par rapport au paquetage (par exemple NM1 , NA2) ou à la classe (par exemple NM4, NA4). Cette restriction de la visibilité permet d'obtenir un accès flexible entre les différents ensembles de paquetages (Paquetage 1 , Paquetage n) stockés dans le même espace nom, mais présente quelques inconvénients. La plate-forme classique ou spécifique supporte mal la notion de sous-paquetages. Les classes client d'une application de grande taille doivent être réparties entre différents sous-paquetages qui représentent uniquement pour la machine virtuelle des paquetages différents. Pour partager les ressources entre ces sous-paquetages, ces ressources sont nécessairement déclarées publiques, les rendant ainsi visibles de tout autre paquetage. Il est ainsi difficile d'organiser de façon claire le paquetage d'applications différentes pour des applications de grande taille et d'obtenir des pare-feu entre les applications. Dans le cas de la plate-forme classique, sur une station, le respect de la confidentialité des ressources, telle que déclarée dans les programmes sources, repose sur des vérifications dynamiques. Pour effectuer ces vérifications dynamiques, la machine virtuelle doit posséder toutes les informations concernant les déclarations de restriction d'accès pour chaque classe, méthode ou attribut, ce qui ne peut être possible dans le cas de l'espace mémoire disponible sur la machine virtuelle embarquée (onplatform) utilisant le pseudocode intermédiaire ou byte code prélié de la machine virtuelle hors plate-forme (off platform). Dans le cas d'une plate-forme spécifique d'un objet portable, les restrictions d'accès peuvent se vérifier statiquement lors de la compilation et peuvent être vérifiées à nouveau par le vérifieur de la partie hors plate-forme. Il est en effet supposé que ce qui est chargé sur la plate-forme spécifique de l'objet portable est correct, car aucune vérification ne peut être effectuée sur la plate-forme spécifique du fait de la perte des informations lors de la phase de conversion. De plus il n'est pas garanti qu'un paquetage ne puisse pas être étendu ou modifié par de nouvelles classes venant de sources étrangères, ce qui peut détruire toute la sécurité basée sur l'utilisation de paquetages privés.
Le deuxième moyen procuré par la machine virtuelle d'une plate- forme classique est la notion de séparation des espaces nom. Avec le schéma de liaison dynamique d'une plate-forme classique, les classes peuvent être chargées, à partir de répertoires du système de fichier local, appelé "ClassPath" préalablement déclaré comme constituant l'emplacement des classes systèmes formant la plate-forme API standard, ou à partir d'autres répertoires du système de fichier local ou de serveurs éloignés. Les classes client d'une application, extérieures au "ClassPath", doivent être chargées par un chargeur de classe spécifiquement programmé. Cette caractéristique est particulièrement utilisée pour le chargement des applications "Java" par des navigateurs habilités "Java". Ainsi, les applications venant de différentes sources, sont chargées par des chargeurs de classes différents. Pour chaque localisateur, communément appelé URL (Uniform Resource Locator), une instance spécifique de classe "chargeur de classe d'application" est utilisée. Le nom externe d'une classe est l'assemblage <Nom Du Paquetage > + <Nom De La Classe>. Quand une classe est chargée, elle est stockée dans une table de classe interne, et une référence relative au chargeur de classe utilisé pour charger cette classe est ajoutée en préfixe du nom de paquetage de la classe. Le nom de la classe est alors «Référence du Chargeur de Classe> + <Nom Du Paquetage> + <Nom De La Classe». Ainsi des classes déclarées comme appartenant au même paquetage mais chargées par des chargeurs de classes différents ne sont pas perçues par la machine virtuelle comme appartenant au même paquetage.
Lors de la résolution d'une référence, la politique habituelle des chargeurs de classe est de rechercher d'abord dans les classes système et en cas d'échec, de rechercher parmi les fichiers de classe présents à l'emplacement où le chargeur peut charger les classes. Selon ce principe de fonctionnement du chargeur, une application ne peut directement accéder aux classes clients d'une autre application chargée par un chargeur de classes différent. Une application peut accéder à toutes les ressources publiques des classes publiques du ClassPath, mais les classes du ClassPath ne peuvent accéder directement aux classes d'une application bien qu'elles puissent faire référence à des instances de classes clients de l'application en les convertissant en un type public défini dans le "Classpath". Une application ne peut étendre ou modifier des paquetages de classes système du Classpath ou de toutes autres applications chargées par des chargeurs de classes différents. L'utilisation de la séparation des espaces nom en insérant une référence du chargeur de classe dans le nom de la classe, ajoutée au typage complet fourni par le langage "Java", permet de procurer un pare-feu efficace entre les applications. Le mécanisme inné de séparation de nom d'espace permet facilement le chargement de nouvelles applications. Les applications peuvent échanger des objets par l'entremise des classes spécifiquement programmées à cette fin et localisées dans le "Classpath". Une application peut utiliser un objet venant d'une autre application chargée par un chargeur de classe différent, si cet objet peut être changé en un type public défini dans le "Classpath".
Malheureusement ce mécanisme de séparation de nom, basé sur une machine virtuelle classique et son processus de liaison dynamique ne peut être effectué sur une plate-forme spécifique. La liaison dynamique ne peut être effectuée par la machine virtuelle d'une plate forme spécifique, celle-ci nécessitant un espace mémoire permettant le stockage de fichier de classe d'une plate-forme "Java" classique, présentant des références non résolues. Dans une plate-forme spécifique, les classes systèmes des API et les classes clients des applications ne sont pas isolées dans des espaces de nommage particuliers.
L'objet de la présente invention est de proposer une solution procurant les avantages de la séparation de nom dans le cadre de systèmes embarqués possédant une machine virtuelle en deux parties, le schéma de liaison statique étant effectué par la partie hors plate-forme.
Dans le contexte de systèmes embarqués, tels que par exemple les terminaux de paiement, multi-application, il est nécessaire d'avoir des pare- feu performants entre les applications "Java" fournies par différentes sources, telles que différents systèmes de paiement (Visa, Mastercard...). Il peut être utile de permettre une coopération flexible entre les applications venant des différentes sources. Le système embarqué doit aussi être facilement mis à jour en téléchargeant de nouvelles applications ou de nouveaux modules utilitaires ou encore des mises à jour sans perturber les applications déjà chargées.
Un premier but de l'invention est de proposer un procédé de chargement permettant d'obtenir des pare-feu robustes entre les applications tout en autorisant une coopération entre les applications et la possibilité de faire évoluer les applications ou de charger d'autres applications. Ce but est atteint par le fait que le procédé de chargement d'applications sur un système embarqué selon l'invention, comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, des interfaces de programmation d'application (API), à partir d'une station sur laquelle le code source de l'application est écrit, compilé en pseudocode par un compilateur , vérifié par un vérificateur, converti par un convertisseur et chargé par un chargeur, se caractérise en ce que
- la conversion comprend la réalisation de la liaison statique d'une pluralité d'ensembles de paquetages destinés à être stockés dans le même espace nom sur le système embarqué, appelés modules, en attribuant un identificateur à chaque module (MID), et un numéro de référence à chaque classe, à chaque méthode et à chaque attribut encapsulés dans les classes du module,
- la référence à une méthode ou un attribut, dans le pseudocode lié d'un module, étant codée sur trois multiplets constitués par un indicateur indiquant la référence à une classe interne ou externe au module, le numéro de la classe et soit le numéro de la méthode soit le numéro de l'attribut,
- les modules chargés sont un ou plusieurs modules d'interface de programmation d'application, appelé Module API, comprenant des classes système ou des modules de services correspondant chacun à une application, une référence à une classe externe étant systématiquement interprétée par la machine virtuelle comme une référence à un module d'interface de programmation d'application.
Selon une autre particularité, le chargement des modules sur le système embarqué comprend la mémorisation d'une part d'au moins un tableau de représentation des modules, le numéro associé, par le lieur compris entre 0 et n, à un module constituant l'index dudit module dans le tableau, et d'autre part d'une table mémorisant l'association de l'index du tableau de représentation à l'identificateur (MID) dudit module, ledit tableau et la table étant en mémoire programmable non volatile, une référence externe à un module externe dans le pseudocode étant interprétée par l'interpréteur de la machine virtuelle comme constituant un index d'accès au module équivalent à celui du tableau des modules.
Selon une autre particularité, le chargement comprend la mémorisation, pour chaque module, d'un tableau de représentation de ses classes, comprenant une référence à l'index de son module et, pour chaque classe, un tableau de représentation des attributs et des méthodes.
Selon une autre particularité, les modules sont référencés dans un tableau de modules unique, les classes système sont contenues dans un module API unique, toute référence à une classe externe dans le pseudocode différente de n sera interprétée par la machine virtuelle comme une référence audit module API.
Selon une autre particularité, les classes étant déclarées publiques, ou en paquetage privé, les attributs et méthodes étant déclarés protégés, en paquetage privée ou en classe privée, la numérotation des classes s'effectue suivant l'ordre classes publiques puis classes en paquetages privés, la numérotation des attributs ou méthodes est effectuée par le convertisseur suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée.
Selon une autre particularité, les classes système sont contenues dans plusieurs modules API chargeables séparément, le chargeur maintient dans la mémoire non volatile programmable deux tableaux de représentation des modules et deux tables d'association MID/IMi correspondantes, l'un pour les modules API et l'autre pour les modules non-API, le chargeur chargeant les modules dans l'un des deux tableaux selon la nature du module spécifié dans l'entête de celui-ci, toute référence externe d'un module du tableau de module étant interprétée comme une référence à l'index du module API.
Selon une autre particularité, la liaison statique d'un module est effectuée de telle sorte que la référence à une classe externe à un module non API dans le pseudocode intermédiaire est un index dans un tableau de l'entête du module, dont chaque entrée est un identificateur (MID) d'un module API référencé, le chargement dudit module sur la plate-forme cible comprenant le remplacement de ladite référence par le numéro de l'index du module API obtenu à partir de l'identificateur (MID) de la table d'association des modules API.
Un autre but de l'invention est de proposer un système embarqué correspondant.
Ce but est atteint par le fait que le système embarqué selon l'invention, comprenant une machine virtuelle et une plate-forme API incluant des interfaces de programmation d'application, une mémoire non volatile fixe, une mémoire non volatile programmable ou modifiable, et une mémoire vive, se caractérise en ce que la mémoire non volatile programmable comprend au moins un module API comprenant des classes système et des modules de services, au moins un tableau de représentation des modules, dans lequel les modules sont indexés et une table associant l'index d'un module du tableau de représentation à l'identificateur dudit module, chaque module comprenant un tableau de représentation des classes, dans lequel les classes sont indexées et dans lequel chaque classe présente une référence à l'index de son module, chaque classe comprenant un tableau de représentation des attributs et des méthodes, dans lesquels les attributs et méthodes sont indexés, la référence à une méthode ou un attribut étant codée sur au moins trois multiplets correspondant à une référence à une classe interne ou externe au module, une référence externe au module constituant l'index du module API dans le tableau de module, un numéro de classe correspondant à l'index de la classe dans la table de représentation des classes du module, et un numéro de méthode ou d'attribut correspondant à l'index de la méthode ou de l'attribut dans le tableau de représentation des méthodes ou attributs de la classe du module.
Selon une autre particularité, le système embarqué comporte des moyens de comparaison du premier multiplet des trois multiplets de codage de référence à une méthode ou à un attribut avec une valeur déterminée n pour décider s'il s'agit d'une classe interne ou externe. Selon une autre particularité, le système embarqué comprend un module principal comprenant le programme principal du système.
Selon une autre particularité, les classes sont indexées suivant l'ordre classes publiques puis classes en paquetages privés, et les attributs ou méthodes suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée.
Selon une autre particularité, la mémoire non volatile programmable comprend plusieurs modules API comprenant des classes système, deux tableaux de représentation des modules, l'un pour les modules API et l'autre pour les modules non-API et le module principal, et deux tables d'association MID/IMi correspondant chacune à un tableau de représentation des modules.,
Selon une autre particularité, le système embarqué comprend une classe gestionnaire d'accès "Access manager" d'un module API comprenant une méthode permettant de créer une instance d'un module de service, par l'intermédiaire du module principal, ladite classe présentant une protection lui interdisant d'avoir plus d'une instance.
Un autre but de l'invention est de proposer un procédé d'exécution d'une application présente sur un système embarqué multi-application. Ce but est atteint par le fait que le procédé d'exécution d'une application d'un système embarqué multi-application, comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, et des interfaces de programmation d'applications (API), se caractérise en ce que, lors de l'exécution du pseudocode intermédiaire d'un module de service, correspondant à une application, référencée dans un tableau de module, la référence à une méthode ou un attribut dans le pseudocode, codée sur au moins trois multiplets correspondant à une référence à une classe interne ou externe au module, un numéro de classe et un numéro de méthode ou d'attribut, une référence externe au module est interprétée par la machine virtuelle comme une référence à l'index d'un module API du tableau du ou des modules API.
Selon une autre particularité, sur réception d'une demande d'exécution d'un module de service présentant un identificateur, l'environnement d'exécution accède à la classe d'entrée d'un module principal comprenant le programme principal du système, le module principal installe une instance d'une classe spéciale "Access Manager", d'un module API, gérant l'accès à un module de service et utilise une méthode de cette classe permettant de créer une instance de la classe d'entrée du module de service demandée, par l'intermédiaire d'une table d'association de l'identificateur à l'index du module dans un tableau dans lequel le module est référencé, l'instance étant retournée par la méthode au programme principal.
D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après faite en référence aux dessins annexés dans lesquels :
- la figure 1 représente de façon schématique les différents éléments nécessaires pour le chargement d'un objet portable selon un premier mode de réalisation ;
- la figure 2 représente de façon schématique les différents éléments nécessaires pour le chargement d'un objet portable selon un deuxième mode de réalisation ;
- la figure 3 représente la représentation interne d'un module ;
- la figure 4a représente le schéma classique d'une carte à puce ;
- la figure 4b représente le système nécessaire à la constitution d'une machine virtuelle embarquée sur une carte à puce selon l'art antérieur;
- la figure 4c représente la structure des classes d'une application. Le procédé sera décrit, en liaison avec les figures 1 à 3, de manière non limitative, dans le cas de la mise en œuvre de l'invention dans un système embarqué, par exemple de type spécifique constitué par une carte à puce ou un objet portable similaire. La désignation byte code ou programme de type byte code recouvre tout pseudocode ou programme intermédiaire.
L'objet portable constitue par exemple une carte à puce et présente une structure similaire de celle décrite précédemment en référence aux figures 4a et 4b, et comprend notamment une mémoire RAM, ROM et EEPROM. La plate-forme spécifique (60) et une station classique (80) sont représentées sur la figure 1. La plate-forme spécifique (60) possède en ROM, un environnement d'exécution (RE) comprenant des API (62) et une machine virtuelle (61 ) embarquée ("onplatform"). La plate-forme spécifique (60) est représentée sur la figure 1 , comme comprenant l'ensemble des mémoires ROM et EEPROM. Il est à noter que la plate-forme spécifique (60) désigne plus particulièrement l'environnement d'exécution (RE) et les éléments présents en mémoire EEPROM. L'objet portable possède en ROM un système d'exploitation (Operating System) (63). Les API (62), présentes en mémoire ROM, constituent les API de base de la plate-forme API, chargées avec la machine virtuelle embarquée pour le fonctionnement de celle-ci.
La partie (90) hors objet portable de la machine virtuelle comprend un vérifieur (91 ) de pseudocode intermédiaire, un convertisseur (92) et éventuellement un signeur (94). Le signeur délivre une signature pour valider le passage par le vérifieur et le convertisseur. Cette signature sera vérifiée par l'objet portable au moment du chargement. Le chargement en EEPROM d'applications ou de nouvelles API pour compléter les API de base s'effectue par un chargeur qui peut être composé de deux parties, une partie hors objet portable pouvant être installée dans la machine virtuelle hors objet portable (90), appelée téléchargeur (93), et une partie sur la plate-forme spécifique, appelée chargeur (68).
Selon un premier mode de réalisation, la plate-forme spécifique (60) comprend deux modules spéciaux, un module API (65) et un module principal (66). Les autres modules sont appelés modules de services (67). Chaque module correspond à un ensemble de paquetages qui sera stocké dans le même espace nom. La plate forme API désigne les API de base (62) et l'ensemble des classes système qui définissent le module API (65) ou module de la plate-forme API. Le module principal comprend la classe principale définissant le programme principal. Chaque module, excepté le module API (65), possède une classe unique, particulière, appelée "Entry Class", qui constitue le point d'accès au module. Pour le module principal, cette "Entry Class" est la classe principale (CP), celle qui contient une méthode statique appelée "main". Pour les modules de services, c'est une classe avec seulement un constructeur sans paramètres et implémentant une interface publique spéciale, appelée "service" définie dans la plate-forme API. Le chargement d'une application correspond au chargement d'un module de service. Chaque module reçoit un identificateur spécifique. Un tel identificateur, qui est appelé MID, peut par exemple être un nombre, une chaîne de caractères, ou un tableau. A titre d'exemple, l'identificateur est une chaîne de caractères.
Quand ils sont chargés dans la plate-forme, par des mécanismes de téléchargement distincts de la machine virtuelle de la plate-forme spécifique, les modules reçoivent un nombre, compris entre 0 et n. Ainsi, selon cette convention, n+1 modules au plus peuvent être présents sur la plate-forme spécifique. Le téléchargeur (93) de module avec le chargeur (68) maintient, lors du chargement de nouveaux modules de service, un tableau (TRM) (69) de représentation des modules. Le numéro associé à un module est l'index (IM) de ce module dans le tableau. Le chargeur (68) maintient également une table (70) associant l'index (IM) à l'identificateur (MID) de chaque module. Le module API reçoit systématiquement pour index IMo le numéro 0, et le module principal pour index IMi le numéro 1 . L'entête (header) de chaque module comprend un indicateur permettant au chargeur de déterminer la nature du module, "principal", modules "de service" ou module "API". Le chargeur (68) ne peut charger que les modules autorisés à résider sur l'objet portable, c'est à dire uniquement les modules présentant une signature connue de l'objet portable. Le chargeur (68) comporte donc des moyens de vérifier la signature d'un module reçu, de la comparer avec la signature connue de l'objet portable et en cas de comparaison négative de bloquer le chargement. De manière classique, tel que défini dans l'art antérieur cité précédemment, le programme source (81 ) d'une application est écrit puis compilé par un compilateur (82) et ensuite vérifié par le vérifieur (91 ).
La liaison statique, réalisée dans le convertisseur (92) par un composant dit lieur (linker) du convertisseur, va résoudre des références symboliques en attribuant
- un numéro (NCI) à chaque classe d'un module,
- un numéro (NM) pour chaque méthode dans une classe et
- un numéro (NA) pour chaque attribut dans une classe.
Chacun de ces numéros (NCI, NM, NA) est compris entre 0 et n et peut ainsi être représenté sur un byte ou multiplet. A titre d'exemple, chacun de ces nombres sera compris entre 0 et 255 (n=255). La référence à une méthode ou un attribut d'une classe sera ainsi codée dans le pseudocode lié des méthodes du module sur deux multiplets (bytes) ou octets. Le pseudocode contiendra ces deux multiplets < NCI> pour la classe et < NA> pour un attribut ou <NM> pour une méthode.
Suivant la figure 3, la représentation interne d'un module API (65), d'un module principal (66) ou d'un module de service (67), contiendra un tableau (TRC) de représentation de classes ; le numéro (NCI) associé par le lieur, hors du système embarqué, à chaque classe est l'index (ICi) de la représentation de cette classe dans le tableau (TRC). Chaque classe présente également une référence à l'index (IMi) de son module. De la même manière, la représentation de chaque classe contient un tableau des représentations de méthodes (TRMe) et un tableau de représentation des attributs (TRA) appartenant à la classe. Le numéro (NM), associé par le lieur, hors du système embarqué, à chaque méthode est l'index (IMi), de la représentation de cette méthode dans le tableau (TRMe), et le numéro (NA), associé par le lieur, hors du système embarqué, à chaque attribut est l'index (lAi), de la représentation de cet attribut dans le tableau (TRA).
A titre d'exemple, nous voulons qu'un module puisse référer uniquement à ses propres classes et aux classes systèmes de la plate-forme API, les classes système correspondant aux classes du "ClassPath" d'une plate-forme classique. Selon l'invention, pour permettre la distinction entre une référence à une classe interne au module et la référence à une classe système (ou externe au module), un indicateur interne (II) ou externe (IE) est ajouté à la référence à une méthode ou à un attribut. La référence résolue est alors codée sur trois multiplets : <IE/II> <NCI> < NM> ou <IE/II> <NCI> <NA>
Selon une convention posée, pour la valeur n du premier multiplet <IE/II> la valeur 255 d'après notre exemple, correspond à une référence interne <ll> au module et toute autre valeur pour le premier multiplet correspond à une référence externe <IE> au module.
Le lieur du convertisseur (92) de la machine virtuelle hors objet portable (90), relie en premier le module API (65), qui ne possède pas de références externes <IE> dans son pseudocode, et produit une implantation ou agencement, correspondant à un plan de noms symboliques de ses classes et de leurs méthodes et attributs. Lors de la mise en liaison des autres modules, cette implantation sera utilisée pour établir les références externes à des classes systèmes du module API (65).
Suivant notre convention des multiplets (bytes) encodant les références, il peut y avoir au plus 256 (n+1 ) classes dans le module API et 256 classes dans chaque module supplémentaire.
Lors de l'exécution d'un module de service, quand la machine virtuelle (61 ) trouve une référence à une méthode <NM> ou un attribut <NA> dans le pseudocode, en connaissant la classe <NCI> où se trouve cette référence, elle peut retrouver directement l'index <IMi> du module concerné, celui-ci correspondant à la référence externe (IE) ou interne (II). Toute référence externe <IE> dans le pseudo code d'un module de service sera systématiquement interprétée par la machine virtuelle comme une référence au module API. Un module de service ou le module principal ne peut pas référer aux classes de tout autre module excepté celles du module API. Les classes systèmes de ce module API ne peuvent pas référer aux classes d'un module de service ou du module principal. La référence interne à une classe d'un module, correspondant à la valeur n pour le premier multiplet, ne nécessite aucune connaissance a priori de l'espace nom qui sera attribué au module. Le fait de ne pas définir a priori d'espace de nommage fixe lors de la phase de conversion permet d'accélérer la résolution des références et de déterminer l'espace de nommage d'un module lors du chargement, postérieurement à la phase de conversion. La machine virtuelle, lors de l'interprétation d'une référence à un attribut ou à une méthode dans le pseudocode, utilise les trois index <IE/II> <NCI> < NM> ou <IE/II> <NCI> <NA> en cascade. L'espace mémoire du module étant déterminé, l'index <NCI> détermine l'entrée désirée dans le tableau des classes (TRM) du module, puis le dernier index < NM> ou <NA> donne l'entrée désirée dans le tableau des méthodes (TRMe) ou le tableau des attributs (TRA).
Le module API comprend une classe spéciale (64), appelée classe "gestionnaire d'accès" ou "Access Manager", qui comprend une méthode native (getServiceInstance) dont le rôle est de rendre un objet instance de la classe d'entrée du module de service demandé, à partir de l'identificateur (MID) du module. Cette méthode utilise la table (70) d'association MID/lmi pour connaître l'index du module demandé dans le tableau de module (69) puis crée une instance de la classe d'entrée de ce module, instance qui est retournée par la méthode. Selon l'invention la classe "Access Manager" (64) est protégée par construction par une méthode consistant à interdire que cette classe ait plus d'une instance. Cette méthode (getServiceInstance) appartient au programme principal contenu dans le module principal. Le module principal qui sera activé en premier à utilisation de l'objet portable crée une instance et une seule de la classe "Access Manager", ce qui lui permet d'utiliser la méthode getServiceInstance, mais interdit à tout autre service de créer une autre instance pour utiliser cette méthode.
En fonctionnement, de la même façon que sur une plate-forme classique, l'environnement d'exécution (RE) accède à la classe d'entrée (EC) du module principal et active sa méthode d'entrée (main). Le module principal, étant le premier activé, procède à l'installation d'une instance de la classe "Access manager" avant que tout autre service le fasse, puisque pour activer d'autres services, le module principal doit déjà posséder une telle instance de la classe accès. Ce simple dispositif permet de reproduire l'effet de protection lié au concept d'espace de nommage d'une plate-forme classique. Le simple fait de charger un module de service dans le tableau des modules et que la présence dans le pseudocode de toutes référence externe soit interprétée par la machine virtuelle comme une référence au module API, rend ce module complètement inaccessible directement par les autres modules, créant ainsi un pare-feu total.
Ce premier mode de réalisation permet d'apporter les avantages de pare-feu procuré par la séparation des espaces nom dans le contexte d'une machine virtuelle en deux parties. Toutefois ce mode de réalisation se révèle peu flexible et présente deux inconvénients.
Premièrement, il empêche toute modification ou extension des classes systèmes avec des modules déjà préliés. Une architecture "Java" classique permet de modifier et d'étendre les classes de la plate-forme API sans avoir d'impact sur les classes déjà compilées de modules supplémentaires. Mais dans le mode de réalisation décrit précédemment, toute modification des classes système, même invisible pour des modules étrangers, modifierait l'agencement de la plate-forme API et nécessiterait de modifier le pseudocode prélié de chaque module déjà lié avec une version antérieure de l'agencement et en conséquence l'interpréteur. Deuxièmement, les modules préliés sont supposés être portables entre les différentes plates-formes ou terminaux embarqués, ce qui impose que chacune de ces plates-formes doit avoir le même agencement que la plate-forme API, ce qui interdit l'utilisation de toute extension propriétaire.
Afin de remédier partiellement à ces inconvénients, une variante du premier mode de réalisation, consiste à imposer que, dans la numérotation de l'implantation, les classes publiques viennent en premier avant les classes en paquetage privé. De plus, les méthodes publiques ou les attributs publics viennent avant ceux qui sont protégés et ceux qui sont en paquetages privés et en classes privées. Ceci permet d'ajouter librement de nouvelles classes publiques dans le module API (65). La figure 2 représente un deuxième mode de réalisation permettant l'évolution de la plate-forme API. La plate-forme API est constituée de plusieurs modules API (100) pouvant être chargés séparément, au lieu d'être constituée d'un module API unique.
Dans ce mode de réalisation, le téléchargeur (93) et la machine virtuelle partagent deux tableaux de modules et deux tables d'association MID/index au lieu d'un de chaque, un tableau (101 ) et une table d'association (102) pour les modules API et un tableau (103) et une table d'association (104) pour les modules non-API, correspondant au module de service (67) et au module principal (66). Chaque module présente dans son entête un indicateur indiquant sa nature "Service" ou "API" permettant au chargeur de charger le module dans le tableau (101 ) de modules API ou dans le tableau (103) de modules non- API. Cet indicateur est placé dans l'entête du module lors de la phase de compilation par le convertisseur. Le pare-feu constitué par la séparation de l'espace nom est présent uniquement entre les modules non-API. Toute référence externe à un module de service sera interprétée par l'interpréteur de la machine virtuelle embarquée comme un index du tableau du module API.
Les modules non-API seront numérotés de 0 jusqu'à 255 au plus, dans l'exemple où n=255. 0 est par exemple l'index du module principal (66). Les modules API (100) seront numérotés de 0 à 254 au plus, 0 étant par exemple l'index d'un module dit API primaire, qui contient toutes les méthodes natives. Conformément à la convention décrite précédemment, ceci permet au plus, 255 (n) modules différents dans la plate-forme API. La référence à une méthode ou attribut dans le pseudocode est : « IE/II> <NCI > < NM/NA»
La valeur 255 (n) pour le premier multiplet (byte) indiquera, comme dans le premier mode de réalisation, une référence interne au module. Chaque valeur différente de 255 indiquera une référence externe à un module spécifique (100) du tableau de module API de la plate-forme API. Après la réalisation de la liaison par le lieur (92) hors plate-forme, le pseudocode d'un module comporte une entête présentant un tableau de modules référencés utilisé pour lier le module courant. Ce tableau de modules référencés comprend au plus 255 entrées, chaque entrée correspondant à l'identificateur (MID) d'un module API (100). Le premier multiplet (byte) d'une référence externe dans le pseudocode sera alors un index dans ce tableau. Lors du chargement sur la plate-forme d'un module non API (67, 66), les numéros d'index associés à des modules API (100) seront connus et ainsi chaque premier octet d'une référence externe sera remplacé par le numéro d'index associé au module API référé en utilisant la table (102) d'association MID/IMi des modules API (100). Ce remplacement est la seule opération de liaison réalisée sur la plate-forme spécifique, par le chargeur (68), la table (102) d'association MID/IMi étant utilisée uniquement pour réaliser cette opération de liaison.
A titre d'exemple, supposons que dans le pseudocode d'un module de service "TEST", nous avons la référence à un numéro de méthode 5 du numéro de classe 7 d'un module API dont l'identificateur (MID) est "F00". Supposons de plus que "F00" est l'identificateur du quatrième module API externe trouvé référencé dans le module de service "TEST". La référence dans le pseudocode est alors constituée par les trois valeurs suivantes : 3, 7, 5. Le numéro 3 correspond au quatrième index dans le tableau de modules référencés présent dans l'entête du module, venant en tête du pseudocode, la valeur de cette entrée étant l'identificateur (MID) "FOO". Supposons que lors du chargement du module API "FOO, l'index interne 34 lui ait été attribué sur la plate-forme cible dans la table d'association (102) des modules API. Alors, le chargeur (68), à l'aide de la table d'association (102) modifie la référence dans le pseudocode du module de service "TEST" pour devenir : 34, 7, 5.
Lors de l'exécution du pseudocode d'un module, une référence externe au module est systématiquement interprétée par la machine virtuelle comme une entrée dans la table de module API. Les modules du tableau de module non API restent invisibles les uns des autres ainsi que par rapport aux modules API. Ce simple dispositif permet de reproduire l'effet de protection lié au concept d'espace de nommage d'une plate-forme classique. Le simple fait de charger un module dans le tableau de module non API le rend complètement inaccessible directement par les autres modules, créant ainsi un pare-feu total.
Le tableau (101 ) de modules API comprend un module spécifique (105), appelé module "API Access" qui comprend une méthode native (getServiceInstance) dans une classe "gestionnaire d'accès" ou "Access Manager" dont le rôle est de rendre un objet instance de la classe d'entrée du module de service demandé. Cette méthode utilise la table (104) d'association MID/IMi pour connaître l'index du module de service demandé dans le tableau (103) de modules non-API puis crée une instance de la classe d'entrée de ce module qui est retournée par la méthode au programme principal. La politique de sécurité préconisée est de faire de la classe "Access Manager" une classe protégée dont le constructeur et les méthodes sont déclarés protégés. De plus, le module "API Access" (105) comprend une protection consistant à interdire que la classe "Access Manager" ait plus d'une instance. Cette méthode est réservée au programme principal contenu dans le module principal (66). Le module principal qui est activé en premier crée une instance du module Access manager, ce qui lui permet d'utiliser la méthode getServiceInstance, mais interdit à tout autre service de créer une autre instance pour utiliser cette méthode. Ainsi le module principal pourra créer des instances de services. Plusieurs méthodes peuvent être utilisées pour obtenir cette protection consistant à interdire que la classe "Access manager" n'ait qu'une seule instance. Le constructeur de la classe peut par exemple bloquer la demande de création d'instance lorsqu'il en existe déjà une et lance une exception de sécurité. En fonctionnement, l'environnement d'exécution (RE) accède à la classe d'entrée du module principal (66) et active sa méthode d'entrée (main). Le module principal étant le premier activé, procède à l'installation d'une instance de la classe "Access Manager" du module Access avant que tout autre service le fasse.
Afin de permettre à un module de service d'activer un autre module de service, cette politique stricte de sécurité peut être modifiée en ajoutant à la classe "Access Manager" du module API Access (105) des classes publiques permettant à tout module d'y faire des requêtes. Ces requêtes seront traitées et contrôlées par l'unique instance créée par le module principal. Ces classes publiques comprennent notamment une méthode statique permettant d'obtenir l'unique instance. Un module ayant accès à l'objet instance de la classe "Access Manager" pourra activer un autre module de service et l'utiliser, mais il ne pourra pas référencer directement ses classes, ses méthodes ou ses attributs sans être repéré par la machine virtuelle, étant donné que toute référence externe dans le pseudocode est une référence interne au module ou une référence externe à un module API.
Pour une réalisation simple de cette solution, il est nécessaire de ne pas avoir de références circulaires parmi les modules API. En conséquence, la fermeture transitive de la relation "réfère à"("refers to") doit être un ordre strict partiel sur un jeu de modules. Il est ainsi possible de concevoir dans le lieur du convertisseur (92) une stratégie simple pour lier et produire l'agencement des modules API en traitant en premier les éléments minimums non encore liés. Il est possible de suivre la même stratégie basée sur un ordre partiel pour le téléchargement des modules API, de telle sorte que lors du téléchargement d'un module M, tous les modules auquel il se réfère aient déjà été téléchargés et qu'un numéro leur aient été assigné. L'assignation de l'index interne sur la plate-forme cible se fait par le chargeur (68) de module en assignant l'index n-1 à l'API d'ordre n. Un module API ne peut référer à un autre API module d'index supérieur.
L'utilisation de ce système de double tableau de modules (101 , 103) et de table d'association (102, 104), permet de remplacer facilement un module API unique par plusieurs modules API chargeables séparément. Le remplacement d'un module API unique par plusieurs modules API permet d'étendre la plate-forme API avec de nouveau modules, sans modifier l'assemblage des modules déjà chargés, sans changer la sécurité offerte par les pare-feu. Bien entendu, ces deux modes de réalisation ne sont pas compatibles ; les modules doivent être préliés spécifiquement pour l'un ou l'autre des modes de réalisation, le pseudocode relatif à un des modes de réalisation n'étant pas portable sur une plate-forme implémentant l'autre mode de réalisation. De plus, l'interpréteur de la machine virtuelle diffère d'un mode de réalisation à l'autre. Dans le premier mode de réalisation, la machine virtuelle ne manipule qu'un seul tableau et une table d'association : le premier multiplet d'une référence sera interprété par la machine virtuelle comme une référence interne pour toute valeur égale à n et comme une référence externe à l'unique module API pour toute valeur différente de n. Dans le second mode de réalisation, la machine virtuelle manipule deux tableaux et deux tables d'association : le premier multiplet d'une référence dans le pseudocode sera interprété par la machine virtuelle comme une référence interne au module pour toute valeur égale à n et toute valeur différente de n sera prise directement comme index dans le tableau de module API. Dans les deux modes de réalisation l'interpréteur de la machine virtuelle comprend des moyens de comparaison du premier multiplet des trois multiplets de codage d'une référence à une méthode ou à un attribut avec une valeur déterminée n pour décider s'il s'agit d'une classe interne ou externe au module. La numérotation des modules API peut être déterminée au moment du chargement pour fixer définitivement et de manière très simple les références externes dans le pseudocode. Les mêmes mécanismes sont utilisés pour manier les deux types de modules, bien que la façon dont ils sont utilisés et la sécurité procurée soient tout à fait différentes. Tout module peut accéder librement aux modules API puisque leurs classes sont des classes système. L'utilisation de l'approche modulaire est utilisée avec les modules services pour procurer un pare-feu rigoureux pour protéger ces modules de tout accès direct.
Le procédé selon l'invention peut être réalisé sur tous types d'objet portable présentant de faibles ressources, tel que par exemple, 16 Ko de mémoire ROM, 8ko de mémoire EEPROM et 256 k de mémoire RAM.
D'autres modifications à la portée de l'homme de métier font également partie de l'esprit de l'invention.

Claims

REVENDICATIONS
1. Procédé de chargement d'applications sur un système embarqué comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, des interfaces de programmation d'application (API), à partir d'une station sur laquelle le code source de l'application est écrit, compilé en pseudocode par un compilateur (82), vérifié par un vérificateur (91 ), converti par un convertisseur (92), et chargé par un chargeur (93, 68), caractérisé en ce que - la conversion comprend la réalisation de la liaison statique d'une pluralité d'ensembles de paquetages destinés à être stockés dans le même espace nom sur le système embarqué, appelés modules, en attribuant un identificateur à chaque module (MID), et un numéro de référence à chaque classe (NCI), à chaque méthode (NM) et à chaque attribut (NA) encapsulés dans les classes du module,
- la référence à une méthode ou un attribut, dans le pseudocode lié d'un module, étant codée sur trois multiplets constitués par un indicateur indiquant la référence à une classe interne (II) ou externe (IE) au module, le numéro de la classe (NCI) et soit le numéro de la méthode (NM) soit le numéro de l'attribut (NA),
- les modules sont un ou plusieurs modules d'interface de programmation d'application comprenant des classes système ou des modules de services correspondant chacun à une application, une référence (IE) à une classe externe étant systématiquement interprétée par la machine virtuelle comme une référence à un module d'interface de programmation d'application.
2. Procédé de chargement d'applications sur un système embarqué selon la revendication 1 , caractérisé en ce que le chargement des modules sur le système embarqué comprend la mémorisation d'une part d'au moins un tableau (69, 101 , 103) de représentation des modules, le numéro (IMi) associé, par le lieur compris entre 0 et n, à un module constituant l'index dudit module dans le tableau, et d'autre part d'une table (70, 102, 104) mémorisant l'association de l'index du tableau de représentation à l'identificateur (MID) dudit module, ledit tableau et la table étant en mémoire programmable non volatile, une référence externe (IE) à un module externe dans le pseudocode étant interprétée par l'interpréteur de la machine virtuelle comme constituant un index d'accès au module équivalent à celui du tableau des modules.
3. Procédé de chargement d'applications sur un système embarqué selon la revendication 2, caractérisé en ce que le chargement comprend la mémorisation, pour chaque module, d'un tableau de représentation (TRC) de ses classes, comprenant une référence à l'index de son module et, pour chaque classe, un tableau de représentation (TRA) des attributs et des méthodes (TRMe).
4. Procédé de chargement d'applications dans un système embarqué selon la revendication 2, caractérisé en ce que les modules sont référencés dans un tableau de modules unique, les classes système sont contenues dans un module API unique, toute référence à une classe externe dans le pseudocode différente de n sera interprétée par la machine virtuelle comme une référence audit module API.
5. Procédé de chargement d'applications dans un système embarqué selon la revendication 4, caractérisé en ce que les classes étant déclarées publiques, ou en paquetage privé, les attributs et méthodes étant déclarés protégés, en paquetage privée ou en classe privée, la numérotation des classes s'effectue suivant l'ordre classes publiques puis classes en paquetages privés, la numérotation des attributs ou méthodes est effectuée par le convertisseur (92) suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée.
6. Procédé de chargement d'applications sur un système embarqué selon la revendication 2, caractérisé en ce que les classes système sont contenues dans plusieurs modules API chargeables séparément, le chargeur (68) maintient dans la mémoire non volatile programmable deux tableaux de représentation des modules et deux tables d'association MID/lmi correspondantes, l'un pour les modules API et l'autre pour les modules non- API, le chargeur chargeant les modules dans l'un des deux tableaux selon la nature du module spécifié dans l'entête de celui-ci, toute référence externe d'un module du tableau de module étant interprétée comme une référence à l'index du module API.
7. Procédé de chargement d'applications sur un système embarqué selon la revendication 6, caractérisé en ce que la liaison statique d'un module est effectuée de telle sorte que la référence à une classe externe à un module non API dans le pseudocode intermédiaire est un index dans un tableau de l'entête du module, dont chaque entrée est un identificateur (MID) d'un module API référencé, le chargement dudit module sur la plate-forme cible comprenant le remplacement de ladite référence par le numéro de l'index du module API obtenu à partir de l'identificateur (MID) de la table d'association MID/IMi des modules API.
8. Système embarqué comprenant une machine virtuelle et une plate-forme API incluant des interfaces de programmation d'application, une mémoire non volatile fixe, une mémoire non volatile programmable ou modifiable, et une mémoire vive, caractérisé en ce que la mémoire non volatile programmable comprend au moins un module API comprenant des classes système et des modules de services, au moins un tableau de représentation des modules (TRM), dans lequel les modules sont indexés et une table (70, 104) associant l'index (IM) d'un module du tableau de représentation à l'identificateur (MID) dudit module, chaque module comprenant un tableau de représentation des classes (TRC), dans lequel les classes sont indexées et dans lequel chaque classe présente une référence à l'index (IM) de son module, chaque classe comprenant un tableau de représentation des attributs (TRA) et des méthodes (TRMe), dans lesquels les attributs et méthodes sont indexés, la référence à une méthode ou un attribut étant codée sur au moins trois multiplets (bytes) correspondant à une référence à une classe interne (II) ou externe (IE) au module, une référence externe au module constituant l'index du module API dans le tableau de module, un numéro de classe (NCI) correspondant à l'index de la classe dans la table de représentation des classes du module, et un numéro de méthode (NM) ou d'attribut (NA) correspondant à l'index de la méthode ou de l'attribut dans le tableau de représentation des méthodes ou attributs de la classe du module.
9. Système embarqué selon la revendication 8, caractérisé en ce qu'il comporte des moyens de comparaison du premier multiplet des trois multiplets de codage de référence à une méthode ou à un attribut avec une valeur déterminée n pour décider s'il s'agit d'une classe interne ou externe.
10. Système embarqué selon la revendication 8, caractérisé en ce qu'il comprend un module principal comprenant le programme principal du système.
1 1. Système embarqué selon la revendication 8, caractérisé en ce que les classes sont indexées suivant l'ordre classes publiques puis classes en paquetages privés, et les attributs ou méthodes suivant l'ordre attribut ou méthode public, protégé, en paquetage privé et en classe privée.
12. Système embarqué selon la revendication 11 , caractérisé en ce que la mémoire non volatile programmable comprend plusieurs modules API comprenant des classes système, deux tableaux de représentation (101 , 103) des modules, l'un pour les modules API et l'autre pour les modules non- API, et le module principal, et deux tables (102, 104) d'association MID/IMi correspondant chacune à un tableau de représentation des modules.
13. Système embarqué selon la revendication 10, caractérisé en ce qu'il comprend une classe gestionnaire d'accès "Access manager" d'un module API (105) comprenant une méthode permettant de créer une instance d'un module de service, par l'intermédiaire du module principal, ladite classe présentant une protection lui interdisant d'avoir plus d'une instance.
14. Procédé d'exécution d'une application d'un système embarqué multi-application, comprenant un environnement d'exécution incluant une machine virtuelle comprenant un interpréteur de langage de type pseudocode intermédiaire, et des interfaces de programmation d'application (API), caractérisé en ce que, lors de l'exécution du pseudocode intermédiaire d'un module de service, correspondant à une application, référencée dans un tableau de module, la référence à une méthode ou un attribut dans le pseudocode, codée sur au moins trois multiplets (bytes) correspondant à une référence à une classe interne (II) ou externe (IE) au module, un numéro de classe (NCI) et un numéro de méthode (NM) ou d'attribut (NA), une référence externe au module est interprétée par la machine virtuelle comme une référence à l'index d'un module API du tableau du ou des modules API .
15. Procédé d'exécution d'une application d'un système embarqué multi-application selon la revendication 14, caractérisé en ce que, sur réception d'une demande d'exécution d'un module de service présentant un identificateur (MID), l'environnement d'exécution accède à la classe d'entrée d'un module principal comprenant le programme principal du système, le module principal installe une instance d'une classe spéciale "Access Manager" d'un module API, gérant l'accès à un module de service, et utilise une méthode de cette classe permettant de créer une instance de la classe d'entrée du module de service demandée, par l'intermédiaire d'une table d'association de l'identificateur à l'index du module dans un tableau dans lequel le module est référencé, l'instance étant retournée par la méthode au programme principal.
PCT/FR2000/003193 1999-11-17 2000-11-17 Procede de chargement d'applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d'execution correspondants WO2001037085A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
BR0007569-8A BR0007569A (pt) 1999-11-17 2000-11-17 Método para o carregamento de aplicações em um sistema de multi-aplicações sobre plataforma equipado com recursos de processamento de dados, sistema e método de execução correspondentes
CA002360431A CA2360431A1 (fr) 1999-11-17 2000-11-17 Procede de chargement d'applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d'execution correspondants
US09/889,416 US6983460B1 (en) 1999-11-17 2000-11-17 Method for loading applications into a multiapplication embedded system equipped with data processing resources, corresponding embedded system and execution method
JP2001539111A JP3689368B2 (ja) 1999-11-17 2000-11-17 データ処理リソースを備えたマルチアプリケーション組込システムにアプリケーションをローディングする方法、対応するシステムおよび実行方法
EP00981423A EP1147467A1 (fr) 1999-11-17 2000-11-17 Procede de chargement d'applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d'execution correspondants
HK02104110.5A HK1042151B (zh) 1999-11-17 2002-05-31 在配備數據處理資源的多用途平臺式系統中加載應用的方法，對應的執行系統和方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9914454A FR2801118B1 (fr) 1999-11-17 1999-11-17 Procede de chargement d'applications dans un systeme embarque multi-application, systeme embarque correspondant, et procede d'execution d'une application du systeme embarque
FR99/14454 1999-11-17

Publications (1)

Publication Number Publication Date
WO2001037085A1 true WO2001037085A1 (fr) 2001-05-25

Family

ID=9552215

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/003193 WO2001037085A1 (fr) 1999-11-17 2000-11-17 Procede de chargement d'applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d'execution correspondants

Country Status (10)

Country Link
US (1) US6983460B1 (fr)
EP (1) EP1147467A1 (fr)
JP (1) JP3689368B2 (fr)
CN (1) CN1162775C (fr)
AR (1) AR034105A1 (fr)
BR (1) BR0007569A (fr)
CA (1) CA2360431A1 (fr)
FR (1) FR2801118B1 (fr)
HK (1) HK1042151B (fr)
WO (1) WO2001037085A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2198198A1 (es) * 2002-01-29 2004-01-16 Airtel Movil S A Sistema de personalizacion de las aplicaciones de una tarjeta sim o usim de un terminal movil.
JP2004185593A (ja) * 2002-07-26 2004-07-02 Ricoh Co Ltd 画像形成装置およびアプリケーション実行方法
WO2004072849A1 (fr) * 2003-02-17 2004-08-26 Giesecke & Devrient Gmbh Procede pour etablir un code de programme
WO2011054498A1 (fr) * 2009-11-05 2011-05-12 Trusted Logic Objet portatif sûr

Families Citing this family (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7493616B2 (en) * 2001-05-30 2009-02-17 Research In Motion Limited Mobile communication device application processing system
US20100174717A1 (en) * 2002-02-28 2010-07-08 Olivier Fambon Interative serialisation procedure for structured software objects
US7069442B2 (en) * 2002-03-29 2006-06-27 Intel Corporation System and method for execution of a secured environment initialization instruction
WO2003107182A1 (fr) * 2002-06-12 2003-12-24 松下電器産業株式会社 Plate-forme a extensibilite securisee de services
US7246347B1 (en) * 2002-06-26 2007-07-17 Sun Microsystems, Inc Method and apparatus for loading class files into non-volatile memory
BR0312989A (pt) * 2002-07-26 2008-03-04 Ron Everett base de dados e sistema de operação de conhecimento
JP3912278B2 (ja) * 2002-12-20 2007-05-09 株式会社日立製作所 組込みコントローラ及び組込みコントローラ開発ツール
US6945957B2 (en) * 2002-12-30 2005-09-20 Scimed Life Systems, Inc. Valve treatment catheter and methods
US7051324B2 (en) * 2003-01-16 2006-05-23 International Business Machines Corporation Externalized classloader information for application servers
US8225302B2 (en) * 2003-02-13 2012-07-17 Lawrence Taylor Waugh System and method for managing source code and acquiring metrics in software development
GB0315165D0 (en) * 2003-05-02 2003-08-06 Transitive Ltd Improved architecture for generating intermediate representations for program code conversion
FR2864650B1 (fr) * 2003-12-24 2006-03-24 Trusted Logic Procede de mise a jour d'applications pour carte a puce
US7917898B2 (en) * 2004-02-02 2011-03-29 Intel Corporation Methods and apparatus to provide a modular native method invocation system
AU2005218326A1 (en) * 2004-02-27 2005-09-15 Aortx, Inc. Prosthetic heart valve delivery systems and methods
US7574705B2 (en) * 2004-06-29 2009-08-11 Sun Microsystems, Inc. Method and apparatus for efficiently resolving symbolic references in a virtual machine
US7454748B2 (en) * 2004-07-27 2008-11-18 Nokia Corporation System and method for specifying virtual machines
CN100442234C (zh) * 2005-06-21 2008-12-10 国际商业机器公司 用于嵌入式系统的软件包构建方法和系统
US8286158B2 (en) * 2006-02-06 2012-10-09 Imation Corp. Method and system for installing portable executable applications
CA2657433A1 (fr) * 2006-06-20 2007-12-27 Aortx, Inc. Arbre de torsion et transmission de couple
US20080005160A1 (en) * 2006-06-30 2008-01-03 Microsoft Corporation Assembly Sensitive Dynamic Classloading Of .Net Types in J#
KR101059633B1 (ko) * 2006-07-14 2011-08-25 인텔 코오퍼레이션 멀티태스킹 가상 머신을 위한 힙 구성
US9477495B2 (en) * 2006-08-17 2016-10-25 International Business Machines Corporation Conservative class preloading for real time Java execution
GB2459682B (en) * 2008-04-30 2012-04-25 Vmware Inc A computer system and a method of deploying an application in a computer system
US8621601B2 (en) * 2008-05-21 2013-12-31 Sandisk Technologies Inc. Systems for authentication for access to software development kit for a peripheral device
CN101819526B (zh) * 2009-09-18 2013-08-28 华为技术有限公司 调用底层软件的方法、装置和嵌入式系统
WO2011091323A1 (fr) 2010-01-21 2011-07-28 Qst Holdings, Llc Procédé et appareil pour un système universel multicœur permettant de mettre en œuvre des calculs reposant sur des flux
WO2011101972A1 (fr) * 2010-02-18 2011-08-25 株式会社東芝 Programme
US20110265058A1 (en) * 2010-04-26 2011-10-27 Microsoft Corporation Embeddable project data
EP2601577B1 (fr) 2010-08-06 2019-02-13 Frederick Furtek Procédé et appareil pour compilateur et composants apparentés pour des calculs par flux dans un système multi-coeurs à usage général
US10402208B2 (en) 2012-06-18 2019-09-03 Microsoft Technology Licensing, Llc Adaptive portable libraries
US8990839B2 (en) * 2013-04-22 2015-03-24 Microsoft Technology Licensing, Llc Controlling runtime access to application programming interfaces
DE102013114763A1 (de) * 2013-10-16 2015-04-16 Semvox Gmbh Sprachsteuerungsverfahren sowie Computerprogrammprodukt und Vorrichtung zur Durchführung des Verfahrens
US10025602B2 (en) * 2014-06-03 2018-07-17 Mentor Graphics Corporation Prelinked embedding
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US9413626B2 (en) 2014-12-05 2016-08-09 Amazon Technologies, Inc. Automatic management of resource sizing
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
US9930103B2 (en) * 2015-04-08 2018-03-27 Amazon Technologies, Inc. Endpoint management system providing an application programming interface proxy service
US10104090B2 (en) 2015-08-25 2018-10-16 Oracle International Corporation Restrictive access control for modular reflection
US10394528B2 (en) 2016-03-30 2019-08-27 Oracle International Corporation Returning a runtime type loaded from an archive in a module system
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US10191753B2 (en) 2016-03-30 2019-01-29 Oracle International Corporation Generating verification metadata and verifying a runtime type based on verification metadata
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
CN106201896A (zh) * 2016-07-26 2016-12-07 华中科技大学 一种嵌入式环境下基于检查点的调试方法、系统及装置
US10387142B2 (en) 2016-09-16 2019-08-20 Oracle International Corporation Using annotation processors defined by modules with annotation processors defined by non-module code
US10282184B2 (en) 2016-09-16 2019-05-07 Oracle International Corporation Metadata application constraints within a module system based on modular dependencies
US10848410B2 (en) 2017-03-29 2020-11-24 Oracle International Corporation Ranking service implementations for a service interface
CN110390184B (zh) * 2018-04-20 2022-12-20 伊姆西Ip控股有限责任公司 用于在云中执行应用的方法、装置和计算机程序产品
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
DE102018122920A1 (de) * 2018-09-19 2020-03-19 Endress+Hauser Conducta Gmbh+Co. Kg Verfahren zur Installation eines Programms auf einem eingebetteten System, ein eingebettetes System für ein derartiges Verfahren sowie ein Verfahren zur Erstellung einer Zusatzinformation
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
AU2019372246A1 (en) * 2018-11-02 2021-05-27 Lzlabs Gmbh Selective substitution of legacy load module programs with classes for execution in a java virtual machine
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
US11861386B1 (en) 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
CN114860204A (zh) * 2022-04-27 2022-08-05 恒宝股份有限公司 程序处理、运行方法、装置、终端、智能卡及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2673476A1 (fr) * 1991-01-18 1992-09-04 Gemplus Card Int Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur.
WO1998019237A1 (fr) * 1996-10-25 1998-05-07 Schlumberger Systemes Utilisation de langage de programmation evolue avec un controleur microprogramme

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6363436B1 (en) * 1997-01-27 2002-03-26 International Business Machines Corporation Method and system for loading libraries into embedded systems
US6430570B1 (en) * 1999-03-01 2002-08-06 Hewlett-Packard Company Java application manager for embedded device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2673476A1 (fr) * 1991-01-18 1992-09-04 Gemplus Card Int Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur.
WO1998019237A1 (fr) * 1996-10-25 1998-05-07 Schlumberger Systemes Utilisation de langage de programmation evolue avec un controleur microprogramme

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZHIQUN CHEN, RINALDO DI GIORGIO: "Understanding Java Card 2.0", INTERNET DOCUMENT, March 1998 (1998-03-01), XP002146332 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2198198A1 (es) * 2002-01-29 2004-01-16 Airtel Movil S A Sistema de personalizacion de las aplicaciones de una tarjeta sim o usim de un terminal movil.
JP2004185593A (ja) * 2002-07-26 2004-07-02 Ricoh Co Ltd 画像形成装置およびアプリケーション実行方法
WO2004072849A1 (fr) * 2003-02-17 2004-08-26 Giesecke & Devrient Gmbh Procede pour etablir un code de programme
WO2011054498A1 (fr) * 2009-11-05 2011-05-12 Trusted Logic Objet portatif sûr
US9311588B2 (en) 2009-11-05 2016-04-12 Trusted Logic Secure portable object

Also Published As

Publication number Publication date
HK1042151A1 (en) 2002-08-02
CN1162775C (zh) 2004-08-18
HK1042151B (zh) 2005-04-22
US6983460B1 (en) 2006-01-03
FR2801118A1 (fr) 2001-05-18
FR2801118B1 (fr) 2001-12-21
BR0007569A (pt) 2002-02-05
JP2003515215A (ja) 2003-04-22
EP1147467A1 (fr) 2001-10-24
JP3689368B2 (ja) 2005-08-31
CN1341238A (zh) 2002-03-20
AR034105A1 (es) 2004-02-04
CA2360431A1 (fr) 2001-05-25

Similar Documents

Publication Publication Date Title
WO2001037085A1 (fr) Procede de chargement d&#39;applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d&#39;execution correspondants
US8234622B2 (en) Cross platform compositional widgets
US7958489B2 (en) Out of band data augmentation
US20200065124A1 (en) Shortening just-in-time code warm up time of docker containers
CN111095338A (zh) 用于执行不同类型区块链合约的系统和方法
EP3123387B1 (fr) Sécurisation du chargement de données dans une mémoire non-volatile d&#39;un élément sécurisé
EP2649522B1 (fr) Methode de mise a disposition d&#39;une application en tant que librairie dans une machine virtuelle
CN104798075A (zh) 应用随机化
FR3017725A1 (fr) Procede de deploiement d&#39;un ensemble d&#39;application (s) logicielle (s)
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
CN108351923A (zh) 与统一可扩展固件接口系统可执行的脚本有关的阈值
WO2001097026A1 (fr) Systeme informatique modulaire et procede associe
EP1960934B1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
EP2453356B1 (fr) Procédé, programme d&#39;ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle
FR2683061A1 (fr) Systeme de segmentation de memoire.
CN101512972A (zh) 将网络环境中的空间个性化
EP1112536A1 (fr) Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce
CN113590144B (zh) 一种依赖处理方法及装置
FR2867929A1 (fr) Procede d&#39;authentification dynamique de programmes par un objet portable electronique
WO2018162810A1 (fr) Procede d&#39;acces a une ressource informatique securisee par une application informatique
WO2024074036A1 (fr) Identification de sous-classe d&#39;objet inconnu
EP3411821B1 (fr) Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus
Daubaris Towards Adaptive WebAssembly Applications: Leveraging Capabilities of the Execution Environment
CN116069515A (zh) 请求处理方法及装置、电子设备及存储介质
CN117992133A (zh) 包管理器适配方法、装置、设备、存储介质及程序产品

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 00804077.X

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): BR CA CN JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: 2000981423

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2360431

Country of ref document: CA

Ref document number: 2360431

Country of ref document: CA

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2001 539111

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 09889416

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2000981423

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2000981423

Country of ref document: EP