Method for loading applications into a multiapplication embedded system equipped with data processing resources, corresponding embedded system and execution method6983460Abstract A method for loading applications into an embedded system from a station on which the source code of the application is written, compiled, verified and converted. The conversion includes the performance of the static linking of a plurality of sets of packages, called modules, and an application program interface module or a service module corresponding to an application, and consists of assigning an identifier to each module and a reference number to each class, each method and each attribute. The reference to a method or an attribute in the linked pseudocode of a module is coded in three bytes referencing a class internal or external to the module, the number of the class, and either the number of the method or the number of the attribute, a reference to an external class being interpreted as a reference to an API module. Claims What is claimed is: Description FIELD OF THE INVENTION
According to another characteristic, the loading of the modules into the embedded system comprises the storage of at least one array representing the modules, the number between 0 and n associated by the linker with a module constituting the index of said module in the array, and a table storing the association of the index in the array representing the identifier (MID) of said module, said array and the table being in programmable nonvolatile memory, an external reference to an external module in the pseudocode being interpreted by the interpreter of the virtual machine as constituting an index for access to the module equivalent to the one in the module array. According to another characteristic, the loading comprises the storage, for each module, of an array representing its classes, comprising a reference to the index of its module and, for each class, an array representing attributes and methods. According to another characteristic, the modules are referenced in a single module array, the system classes are contained in a single API module, and any reference to an external class in the pseudocode different from n will be interpreted by the virtual machine as a reference to said API module. According to another characteristic, the classes being declared public, or in private packages, the attributes and methods being declared protected, in private packages or in private classes, the numbering of the classes is done in order of the public classes followed by the classes in private packages; the numbering of the attributes or methods is done by the converter in order of the attributes or methods that are public, protected, in private packages, and in private classes. According to another characteristic, the system classes are contained in several API modules that can be loaded separately, the loader maintains in the programmable nonvolatile memory two arrays representing modules and two corresponding MID/IMi association tables, one for the API modules and the other for the non-API modules, the loader loading the modules into one of the two arrays based on the nature of the module specified in its header, any external reference of a module of the module array being interpreted as a reference to the index of the API module. According to another characteristic, the static linking of a module is performed in such a way that the reference to a class external to a non-API module in the intermediate pseudocode is an index in an array of the header of the module, wherein each entry is an identifier (MID) of a referenced API module, the loading of said module into the target platform comprising the replacement of said reference with the number of the index of the API module obtained from the identifier (MID) in the MID/IMi association table of the API modules. Another object of the invention is to offer a corresponding embedded system. This object is achieved through the fact that the embedded system according to the invention, comprising a virtual machine and an API platform including application program interfaces, a fixed nonvolatile memory, a programmable or modifiable nonvolatile memory, and a random access memory, is characterized in that the programmable nonvolatile memory comprises at least one API module comprising system classes and service modules, at least one array representing modules, in which the modules are indexed, and a table associating the index of a module in the representing array with the identifier of said module, each module comprising an array representing classes, in which the classes are indexed and in which each class has a reference to the index of its module, each class comprising an array representing attributes and methods, in which the attributes and methods are indexed, the reference to a method or an attribute being coded in 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 array, a class number corresponding to the index of the class in the table representing the classes of the module, and a method or attribute number corresponding to the index or the method or the attribute in the array representing the methods or attributes of the class of the module. According to another characteristic, the embedded system includes means for comparing the first byte of the three bytes encoding a reference to a method or an attribute to a given value n in order to decide whether it is an internal or an external class. According to another characteristic, the embedded system comprises a main module comprising the main program of the system. According to another characteristic, the classes are indexed in order of the public classes, followed by the classes in private packages, and the attributes and methods are indexed in order of the attributes or methods that are public, protected, in private packages, and in private classes. According to another characteristic, the programmable nonvolatile memory comprises several API modules comprising system classes, two arrays representing modules, 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 an array representing modules. According to another characteristic, the embedded system comprises an access manager class "Access Manager" of an API module comprising a method that makes it possible to create an instance of a service module, via the main module, said class having a protection that prohibits it from having more than one instance. Another object of the invention is to offer a method for executing an application present in a multi-application embedded system. This object is achieved through the fact that the method for executing an application of a multi-application embedded system, comprising a runtime environment including a virtual machine comprising an intermediate pseudocode language interpreter and application programming interfaces (API), is characterized in that during the execution of the intermediate pseudocode of a service module, corresponding to an application, referenced in a module array, the reference to a method or an attribute in the pseudocode, coded in 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 virtual machine as a reference to the index of an API module in the array of the API module or modules. According to another characteristic, upon reception of a request for execution of a service module having an identifier, the runtime 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 that controls access to a service module and uses a method of this class for creating an instance of the input class of the requested service module, by means of a table associating the identifier with 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. BRIEF DESCRIPTION OF THE DRAWINGS Other characteristics and advantages of the present invention will emerge more clearly with the reading of the description below, written in reference to the attached drawings in which: FIG. 1 schematically represents the various elements required for loading a portable object according to a first embodiment; FIG. 2 schematically represents the various elements required for loading a portable object according to a second embodiment; FIG. 3 represents the internal representation of a module; FIG. 4a represents the conventional diagram of a smart card; FIG. 4b represents the system required to constitute a virtual machine embedded in a smart card according to the prior art. FIG. 4c represents the structure of the classes of an application. DESCRIPTION OF THE PREFERRED EMBODIMENTS The method will be described in connection with FIGS. 1 through 3, in a non-limiting way, in the case of the implementation of the invention in an embedded system, for example of the specific type constituted by a smart card or a similar portable object. The designation byte code or byte code program covers any intermediate pseudocode or program. The portable object constitutes, for example, a smart card and has a structure similar to the one described above in reference to FIGS. 4a and 4b, and specifically comprises a RAM, ROM and EEPROM. The specific platform (60) and a conventional station (80) have, in ROM, a runtime environment (RE) comprising APIs (62) and an "on-platform" virtual machine (61). The specific platform (60) is represented in FIG. 1 as comprising the set of memories ROM and EEPROM. It should be noted that the specific platform (60) more specifically designates the runtime environment (RE) and the elements present in EEPROM. The portable object has, in ROM, an operating system (63). The APIs (62) present in ROM constitute the basic APIs of the API platform, loaded with the on-platform virtual machine for running the latter. The part (90) of the virtual machine outside the portable object comprises an intermediate pseudocode verifier (91), a converter (92) and possibly a signer (94). The signer delivers a signature for validating 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 for complementing the basic APIs is done by a loader, which can be composed of two parts, a part outside the portable object that can be installed in the virtual machine outside the portable object (90), called a downloader (93), and a part in the specific platform, called a loader (68). In a first embodiment, 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 that will be stored in the same name space. The API platform designates the basic APIs (62) and all of the system classes that define the API module (65) or the module of the API platform. The main module comprises the main class defining the main program. Each module, except for the API module (65), has one particular class called "Entry Class," which constitutes the point of access to the module. For the main module, this "Entry Class" is the main class (CP), the one that contains a static method called "main." For the service modules, it is a class with only one constructor, without parameters and implementing a special public so-called "service" interface 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. For the sake of example, the identifier is a character string. When they are loaded into the platform by downloading mechanisms distinct from the virtual machine of the specific platform, the modules receive a number between 0 and n. Thus, based on this convention, n+1 modules at most can be present in the specific platform. During the loading of new service modules, the module downloader (93), along with the loader (68), maintains an array (TRM) (69) representing the modules. The number associated with a module is the index (IM) of this module in the array. The loader (68) also maintains a table (70) associating the index (IM) with the identifier (MID) of each module. The API module systematically receives, for the index IM0, the number 0, and the main module receives for the index IM1 the number 1. The header of each module includes an indicator that allows the loader to determine the nature of the module—"main," "service," or "API" module. The loader (68) can only load modules that are authorized to reside in the portable object, i.e., only modules having a signature recognized by the portable object. The loader (68) therefore includes means for verifying the signature of a received module, for comparing it to the signature recognized by the portable object, and in case of a negative comparison, for prohibiting the loading. Conventionally, as defined in the prior art mentioned above, the source program (81) of an application is written, then compiled by a compiler (82), and then verified by the verifier (91). The static linking, performed in the converter (92) by a component of the converter called a linker, will resolve the symbolic references by assigning
Each of these numbers (NCI, NM, NA) is between 0 and n, and can thus be represented by a byte. For example, each of these numbers is between 0 and 255 (n=255). The reference to a method or an attribute of a class will thus be coded into the linked pseudocode of the methods of the module in two bytes. The pseudocode will contain these two bytes, <NCI> for the class, and <NA> for an attribute or <NM> for a method. According to FIG. 3, the internal representation of an API module (65), a main module (66), or a service module (67) will contain an array (TRC) representing classes; the number (NCI) associated by the linker outside the embedded system with each class is the index (ICi) of the representation of this class in the array (TRC). Each class also has a reference to the index IMi of its module. Likewise, the representation of each class contains an array representing the methods (TRMe) and an array representing the attributes (TRA) belonging to the class. The number (NM) associated by the linker outside the embedded system with each method is the index IMi of the representation of this method in the array (TRMe), and the number (NA) associated by the linker outside the embedded system with each attribute is the index (IAi) of the representation of this attribute in the array (TRA). For example, we want 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 classes of the "ClassPath" of a conventional platform. According to the invention, in order to make it possible to distinguish between a reference to a class internal to the module and the reference to a system class (or class external to the module), an internal (II) or external (IE) indicator is added to the reference to a method or an attribute. The resolved reference is then coded in three bytes: <IE/II><NCI><NM> or <IE/I><NCI><NA>. In accordance with an established convention, for the value n of the first byte <IE/II>, the value 255 in our example, corresponds to a reference <II> internal to the module, and any other value for the first byte corresponds to a reference <IE> external to the module. The linker of the converter (92) of the virtual machine outside the portable object (90), first links the API module (65), which does not have any external references <IE> in its pseudocode, and produces a layout or arrangement corresponding to a scheme of symbolic names of its classes and their methods and attributes. During the linking of the other modules, this layout will be used to establish the external references to system classes of the API module (65). Based on our convention for the bytes encoding the references, there can be at most 256 (n+1) classes in the API module and 256 classes in each additional module. During the execution of a service module, when the virtual machine (61) finds a reference to a method <NM> or an attribute <NA> in the pseudocode, knowing the class <NCI> in which this reference is found, it can directly retrieve the index <IMi> of the module in question, the latter corresponding to the external (IE) or internal (II) reference. Any external reference <IE> in the pseudocode of a service module will be systematically interpreted by the virtual machine as a reference to the API module. A service module or the main module cannot refer to the classes of any other module except those of the API module. The system classes of this API module cannot refer to the classes of a service module or the main module. The internal reference to a class of a module, corresponding to the value n for the first byte, does not require any knowledge a priori of the name space that will be assigned to the module. The fact that no fixed name space is defined a priori during the conversion phase makes it possible to accelerate the resolution of the references and to determine the naming space of a module during the loading, after the conversion phase. The virtual machine, during the interpretation of a reference to an attribute or a method in the pseudocode, uses the three cascaded indexes <IE/II><NCI><NM> or <IE/II><NCI><NA>. The memory space of the module being determined, the index <NCI> determines the desired entry into the array (TRM) of the classes of the module, then the last index <NM> or <NA> gives the desired entry into the method array (TRMe) or the attribute array (TRA). The API module comprises a special class (64), called class "Access Manager", which comprises a native method (getServiceInstance) whose role is to return an object that is an instance of the input class of the requested service module, from the identifier (MID) of the module. This method uses the MID/IMi association table (70) to find the index of the requested module in the module array (69), then creates an instance of the input class of this module, an instance that is returned by the method. According to the invention, the class "Access Manager" (64) is protected by construction by a method that consists of prohibiting this class from having more than one instance. This method (getServiceInstance) belongs to the main program contained in the main module. The main module, which is activated first when the portable object is used, creates one and only one instance of the class "Access Manager", which allows it to use the method getServiceInstance, but bars any other service from creating another instance for using this method. In operation, just like in a conventional platform, the runtime environment (RE) accesses the input class (EC) of the main module and activates its input method (main). The main module, being the first one activated, installs an instance of the class "Access Manager" before any other service does so, since in order 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 a naming space in a conventional platform. The simple fact that a service module is loaded into the module array, and that the presence in the pseudocode of any external references is interpreted by the virtual machine as a reference to the API module, renders this module completely inaccessible directly by the other modules, thus creating a total firewall. This first embodiment makes it possible to obtain the advantages of a firewall produced by name space separation in the context of a two-part virtual machine. However, this embodiment is not very flexible, and has two drawbacks. First, it prevents any modification or extension of the system classes with modules that are already pre-linked. A conventional Java architecture makes it possible to modify and extend the classes of the API platform without having an impact on the already compiled classes of additional modules. But in the embodiment described above, any modification of the system classes, although invisible for alien modules, would modify the layout of the API platform and would make it necessary to modify the pre-linked pseudocode of each module already linked with a prior version of the layout, and consequently the interpreter. Secondly, the pre-linked modules are assumed to be portable between the various embedded platforms or terminals, which requires each of these platforms to have the same layout as the API platform, thus prohibiting the utilization of any proprietary extension. In order to partially remedy these drawbacks, a variant of the first embodiment consists of requiring that, in the numbering of the layout, the public classes come first, before the classes in private packets. In addition, the public methods or public attributes come before those that are protected and those that are in private packages and in private classes. This makes it possible to freely add new public classes into the API module (API). FIG. 2 represents a second embodiment that allows upgrading of the API platform. The API platform is constituted by several API modules (100) that can be loaded separately, instead of being constituted by a single API module. In this embodiment, the downloader (93) and the virtual machine share two module arrays and two MID/index association tables instead of one of each, an array (101) and an association table (102) for the API modules and an array (103) and an association table (104) for the non-API modules corresponding to the service module (67) and the main module (66). Each module has in its header an indicator indicating its nature, "Service" or "API", which allows the loader to load the module into the API module array (101) or into the non-API module array (103). This indicator is placed in the header of the module during the compilation phase by the converter. The firewall constituted by the separation of the name space is present only between the non-API modules. Any external reference to a service module will be interpreted by the interpreter of the on-platform virtual machine as an index of the API module array. The non-API modules are numbered from 0 to 255 at most, in the example in which n=255. For example, 0 is the index of the main module (66). The API modules (100) are numbered from 0 to 254 at most, 0 being for example the index of a so-called primary API module, which contains all of the native methods. According to 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:
The value 255 (n) for the first byte indicates, as in the first embodiment, a reference internal to the module. Each value different from 255 indicates a reference external to a specific module (100) of the API module array of the API platform. After the performance of the linking by the off-platform linker (92), the pseudocode of a module includes a header having an array of referenced modules used to link the current module. This referenced module array 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 therefore be an index in this array. When a non-API module (67, 66) is loaded into the platform, the index numbers associated with API modules (100) are known, and thus each first byte of an external reference is replaced by the index number associated with the referenced API module using the MID/IMi association table (102) of the API modules (100). This replacement is the only linking operation performed in the specific platform by the loader (68), the MID/IMi association table (102) being used only for performing this linking operation. For the sake of example, let's assume that in the pseudocode of a service module "TEST", we have the reference to a method number 5 of class number 7 of an API module whose identifier (MID) is "F00". Let's also assume that "F00" is the identifier of the fourth external API module found referenced in the service module "TEST". The reference in the pseudocode is therefore constituted by the following three values: 3, 7, 5. The number 3 corresponds to the fourth index in the array of referenced modules present in the header of the module, which comes at the beginning of the pseudocode, the value of this entry being the identifier (MID) "F00". Let's assume that at the time the API module "F00" is loaded, the internal index 34 has been assigned to it in the target platform, in the association table (102) of the API modules. Therefore, the loader (68), using the association table (102), modifies the reference in the pseudocode of the service module "TEST" so that it becomes: 34, 7, 5. During the execution of the pseudocode of a module, a reference external to the module is systematically interpreted by the virtual machine as an entry in the API module array. The modules of the non-API module array remain invisible to one another as well as to the other API modules. This simple device makes it possible to reproduce the protective effect linked to the concept of a naming space in a conventional platform. The simple fact that a module is loaded into the non-API module array makes it completely inaccessible directly by the other modules, thus creating a total firewall. The API module array (101) comprises a specific module (105), called an "API Access" module, which comprises a native method (getServiceInstance) in a class "Access Manager" whose role is to return an object that is an instance of the input class of the requested service module. This method uses the MID/IMi association table (104) to find the index of the requested service module in the non-API module array (103), 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 class "Access Manager" a protected class whose constructor and methods are declared protected. In addition, the "API Access" module (105) includes a protection consisting of prohibiting the class "Access Manager" from having 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 module Access Manager, which allows it to use the method getServiceInstance, but prohibits any other service from creating another instance for using this method. Thus, the main module can create service instances. Several methods can be used to obtain this protection, which consists of prohibiting the class "Access Manager" from having more than one instance. The constructor of the class "Access Manager" can, for example, inhibit the request for creating an instance when one already exists and trigger a security exception. In operation, the runtime environment (RE) accesses the input class of the main module (66) and activates its input method (main). The main module, being the first one activated, installs an instance of the class "Access Manager" of the Access module before any other service does so. In order to allow a service module to activate another service module, this strict security policy can be modified by adding to the class "Access Manager" of the API Access module (105) public classes that will allow any module to send requests to it. These requests will be processed and controlled by the sole instance created by the main module. These public classes specifically include a static method that makes it possible to obtain the sole instance. A module having access to the object that is the instance of the class "Access Manager" can activate another service module and use it, but it cannot directly reference its classes, its methods or its attributes without being referred by the virtual machine, given that any external reference in the pseudocode is a reference internal to the module or a reference external to an API module. For a simple embodiment of this solution, it is necessary not to have circular references among the API modules. Consequently, the transitive closure of the relation "refers to" must be a strict partial order on a set of modules. It is thus possible to design, in the linker of the converter (92), a simple strategy for linking and producing the layout of the API modules by first processing the minimum elements not yet linked. It is possible to use the same strategy based on a partial order for downloading the API modules, so that when a module M is downloaded, all of the modules to which it refers have already been downloaded, and a number has been assigned to them. The assignment of the internal index in the target platform is done by the module loader (68) by assigning the index n-1 to the API of order n. An API module cannot refer to another API module with a higher index. The utilization of this system of dual module arrays (101, 103) and association tables (102, 104) 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 with several API modules makes it possible to extend the API platform with new modules, without modifying the linking of the modules already loaded, and without changing the security provided by the firewalls. Of course, these two embodiments are not compatible; the modules must be pre-linked specifically for one embodiment or the other, the pseudocode related to one of the embodiments not being portable to a platform implementing the other embodiment. Moreover, the interpreter of the virtual machine differs form one embodiment to the other. In the first embodiment, the virtual machine manipulates only one array and one association table; the first byte of a reference is interpreted by the virtual machine as an internal reference for any value equal to n, and as an external reference to the sole API module for any value different from n. In the second embodiment, the virtual machine manipulates two arrays and two association tables: the first byte of a reference in the pseudocode is interpreted by the virtual machine as a reference internal to the module for any value equal to n, and any value different from n will be taken directly as an index in the API module array. In both embodiments, the interpreter of the virtual machine comprises means for comparing the first byte of the three coding bytes of a reference to a method or an attribute with a given value n in order to decide whether it refers to a class that is internal or external to the module. The numbering of the API modules can be determined at the time of loading, in order to permanently set the external references in the pseudocode in a very simple way. The same mechanisms are used to handle both types of modules, although the way in which they are used and the security obtained are entirely different. Any module can freely access the API modules, since their classes are system classes. The utilization of the modular approach is used with the service modules to obtain a strong firewall for protecting these modules from any direct access. The method according to the invention can be implemented in any type of portable object having limited resources, such as for example 16 Kb of ROM, 8 Kb of EEPROM and 256 k of RAM. While this invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, the preferred embodiments of the invention as set forth herein, are intended to be illustrative, not limiting. Various changes may be made without departing from the true spirit and full scope of the invention as set forth herein and defined in the claims.
|
Same subclass Same class Consider this |
||||||||||