How to relink software components installed on a device that is being updated

Abstract

The present invention relates to a method for relinking software components installed on a device being updated, the device including a CAP file, the method including creating a CAP file component called a link component (30), the link component (30) including a proprietary constant pool portion (31) constructed by using the original constant pool component of the CAP file, and a proprietary reference location portion (32) constructed by using the original reference location component and the original method component of the CAP file.

Description

[Technical Field]

[0001] The present invention relates to upgrading software / firmware (hereinafter referred to as software components or software) that is characterized by components that interact with each other and widely used concepts such as component dependencies, type hierarchies, extensions, and instance-based objects.

[0002] The invention applies in particular to electronic devices such as smartphones, M2M (Machine to Machine) equipment, and in particular IoT (Internet of Things) devices with small computing capabilities and power, that cooperate with a secure element such as a smart card, a SIM card, a UICC (Universal Integrated Circuit Card), an e-UICC (embedded UICC) or an ie-UICC (integrated embedded UICC).

[0003] Software component upgrades may be required to fix bugs, add new features, improve performance or security, or upgrade the complete API or component version. However, to ensure that applications run on new versions of software components, existing data must be preserved and the upgrade must be performed.

[0004] However, for complex updates, it can be very difficult to update the software while keeping existing data that it depends on intact.

[0005] For upgrading software, two solutions are known: dynamic linking and static linking.

[0006] With dynamic linking, shared libraries and dependencies are linked during software execution. Because linking is performed during execution, the base API can be updated without issue as long as compatibility is enforced. However, dynamic linking requires significant processing power and memory requirements, which makes this solution suitable for high-resource / powerful hardware. Maintaining efficient and fast execution can be very challenging in embedded environments where resources are scarce and processing power is limited (e.g., for M2M applications, IoT devices), or on systems with high memory access penalties.

[0007] In such constrained environments, static linking is usually the preferred implementation method, as it allows for fast execution despite the required initial linking step.

[0008] In statically linked software components, inter-component dependencies make upgrading base libraries (e.g., APIs) very complex, requiring very careful and memory-intensive custom patching. Therefore, due to risk and workload considerations, full-scale upgrades of base APIs on constrained platforms such as embedded chips or smart cards are usually not considered possible after the product (device) has been issued in the field.

[0009] CN-103914351, entitled "Method for achieving JAVA card system patches," discloses a method for achieving JAVA card system patches, which includes the steps of generating a patch application, downloading the patch application, installing the patch application, removing the service pack and the patch application, and executing the patch.

[0010] The problem with this solution is that it does not address the situation where the entire Java API must be replaced. In other words, only tweaked patch updates are addressed by this document, not API replacements.

[0011] Another prior art technique is disclosed in U.S. Patent No. 11,099,764, entitled "Method for amending the firmware of a resource constrained device." The proposed solution relates to a method for amending the firmware of a device with limited resources.

[0012] Each call that addresses one of the public functions of a functional component is dispatched using a call dispatch unit.

[0013] The problem with this solution is that it only addresses dynamic linking.

[0014] The proposed invention aims to provide a solution that enables seamless component upgrades using an efficient relinking process for complex software based on static linking, which can be native code components or virtual machines (VMs).

[0015] In this regard, the present invention proposes a method for relinking software components installed on a device being updated, the device including a CAP file, the method comprising creating a CAP file component, called a link component, the link component including a proprietary constant pool portion constructed by using the original constant pool component of the CAP file, and a proprietary reference location portion constructed by using the original reference location component and the original method component of the CAP file.

[0016] In one embodiment, the link component is generated off-device using knowledge of the binaries on which the CAP file depends.

[0017] In another embodiment, the link component is generated during loading of the CAP file onto the device.

[0018] Link components are preferably compressed when created.

[0019] Advantageously, the device's OS includes additional metadata that provides details about the updated CAP file portion of the OS to improve the relinking process.

[0020] In a preferred embodiment, these details include a list of updated CAP files so that only downloaded CAP files that depend on modified CAP files are relinked.

[0021] The invention will be better understood by reading the following description of a unique diagram illustrating the creation of a link component according to the invention.

[0022] A typical example of the use of the present invention is applied to software installed on a Java Card product and executed by the Java Card Virtual Machine (JCV).

[0023] A typical Java Card CAP file consists of the following set of standard components: COMPONENT_Header COMPONENT_Directory COMPONENT_Import COMPONENT_Applet COMPONENT_Class COMPONENT_Method COMPONENT_StaticField COMPONENT_Export COMPONENT_ConstantPool COMPONENT_ReferenceLocation COMPONENT_Descriptor (Optional)

[0024] The header component contains general information about this CAP file and the package it defines.

[0025] The directory component lists the size of each of the components defined in this CAP file. If an optional component, such as an applet component or a debug component, is not included, it is represented in the directory component.

[0026] The Imports component lists the set of packages imported by classes in this package. This does not include entries for packages defined in this CAP file.

[0027] The Applets component contains an entry for each of the applets defined in this package.

[0028] The Class component describes each of the classes and interfaces defined in this package. It does not contain complete access information and content details for each class and interface. Instead, the information contained is limited to what is needed to perform the operations associated with a particular class or interface without performing validation. Complete details about the classes and interfaces defined in this package are contained in the Descriptor component. The information contained in the Class component for each interface is sufficient to uniquely identify the interface and to test whether a cast to that interface is valid.

[0029] The Methods component describes each of the methods declared in this package. The Methods component does not include complete access information and descriptive details for each method. Instead, the information is optimized for size and therefore limited to what is needed to execute each method without performing validation.

[0030] Static field components have the static modifier in their declaration and are also called class variables. They are associated with a class, not with any object. All instances of a class share the class variables in one fixed location in memory.

[0031] The constant pool component contains an entry for each class, method, and field referenced by an element in the method component. The referenced element in the method component can be an instruction in a method or an exception handler catch type in the exception handler table.

[0032] Entries in a constant pool component reference elements in class, method, and static field components. Package tokens are also used to access import components to describe references to classes, methods, and fields defined in imported packages. Entries in a constant pool component do not reference other entries within themselves.

[0033] The CONSTANT_Classref_info structure is used to represent a reference to a class or interface, which may be defined in this package or an imported package.

[0034] The export component lists all static elements in this package that can be imported by classes in other packages. Instance fields and virtual methods are not represented in the export component.

[0035] The reference location component 15 is the exact offset of the object within the method component. A reference is a variable used to access an object.

[0036] The descriptor component 14 provides enough information to parse and validate all elements of the CAP file.

[0037] The constant pool component contains the constants needed to run a particular class of code. It is essentially a runtime data structure similar to a symbol table. It is a runtime representation of each class or interface in a Java class file.

[0038] The contents of the constant pool consist of compiler-generated symbolic references. These references are the names of variables, methods, interfaces, and classes referenced by your code. The JCVM uses them to link your code with other classes it depends on.

[0039] The static fields component contains all the information necessary to create and initialize images, called static field images, of all static fields defined within this package.

[0040] The offset for a particular static field is the offset into the static field image, not the offset into the static field component.

[0041] During the linking phase, external references in the CAP file are converted from token format to the internal representation used by the virtual machine on the device. The reference location component represents a list of offsets into the information items of the method component for items that contain an index into the constant pool array of the constant pool component. [Brief explanation of the drawings]

[0042] [Figure 1] The unique diagram shows a header component 10, a directory component 11, a constant pool component 12, a static field component 13, a descriptor component 14, a reference location component 15, a debug component 16, an applet component 20, an import component 21, a method component 22, a class component 23, and an export component 24.

[0043] On the left side of the diagram, components 10-13 and 15 are used during the linking operation but can be discarded after the linking operation. They are typically removed from the device after the linking operation to conserve memory space. Components 14 and 16 are not used during the linking operation and are not required on the device, but can be used by tools external to the device for other purposes. On the right side of the diagram, components 20-24 are used during the linking operation and must be stored on the device after the linking operation for proper use and execution of the CAP file by the JCVM. The linked method component 22 stored on the device after the linking operation is not the original method component, but rather the one modified during the linking operation that is suitable for execution of the CAP file by the JCVM.

[0044] During the linking operation, a proprietary link component 30 (with subpart constant pool 31 and reference location 32) is created and must also be stored on the device.

[0045] The link component 30 is When the CAP file is loaded onto a device and linked by the device, or CAP files can be generated when off-device using knowledge of dependent binaries, leading to improved linking times on device.

[0046] In a typical scenario, a device OS initially contains some CAP files (e.g., implementing built-in APIs), and then additional CAP files that depend on the initially present CAP files can later be downloaded to the device to add complementary functionality to the device.

[0047] If the device OS is later updated, especially if the CAP files originally present in the OS are updated, it may be necessary to relink the downloaded CAP files, since the CAP files present in the OS on which they depend may have been modified. In fact, the internal representation used by the JCVM for each token in the CAP files present in the OS may have changed.

[0048] A simple relinking implementation would be to retain all components necessary for the linking operation, including the original method components. However, this approach has a significant impact on the memory size required to store the CAP file, which is problematic for memory-constrained devices.

[0049] The proprietary link component 30 consists of two parts. a proprietary constant pool portion 31 (step 40), constructed using the original constant pool components 12, but preferably reorganized to reduce size; A proprietary reference location portion 32 constructed using the original reference location component 15 (step 41) and data extracted and transformed from the original method component (step 42) before being modified into the linked method component 22.

[0050] The structure of the proprietary link component 30 is described below.

[0051] [Table 1]

[0052] The structure of the proprietary constant pool portion 31 is described below.

[0053] [Table 2]

[0054] The contents of proprietary constant pool portion 31 are equivalent to the contents of standard constant pool component 12, but are reorganized and sorted by type, thus eliminating the need for padding bytes (as used in standard components) and therefore reducing the overall size of the proprietary component. However, as a result of this transformation, indices into standard constant pool component 12 found within the original method component must be converted into indices into proprietary constant pool portion 31. This issue is addressed in the next step of constructing proprietary reference location portion 32.

[0055] Note that the standard reference position component 15 is structured as a concatenation of two consecutive byte streams called byte_index_part and byte2_index_part. Each byte stream encodes OFFSETS in the method component where an index in the constant pool component can be found. In each stream, when a byte has a value of 0xFF (255), it must be added to the value of the next byte, obtaining an OFFSET in the method component, until the byte value differs from 0xFF. An example is shown below:

[0056] [Table 3]

[0057] The proprietary reference location portion 32 is constructed by modifying the standard reference location component 15 by inserting a one-byte value (in the byte_index_part) or a two-byte value (in the byte2_index_part) immediately after each OFFSET. For each OFFSET, the value inserted is an index in the proprietary constant pool portion 31, which is converted from the index found at the OFFSET in the original method component. The result of this conversion is shown below:

[0058] [Table 4]

[0059] As a result of this conversion, the information needed from the original method component to perform the linking operation becomes available in the proprietary constant pool portion 31 and can be used if the CAP file needs to be relinked.

[0060] Finally, since the proprietary linking component 30 is retained and used instead, there is no need to retain the original method component, constant pool component 12, and reference location component 15 in order to be able to relink CAP files. This method significantly reduces the memory size impact of supporting a CAP file relinking mechanism and the memory size required to support OS update scenarios.

[0061] Link components 30 can be further compressed when created to further reduce their size, and can be decompressed on the fly during a relinking operation.

[0062] The device OS generates the link component 30 only if it was not generated off-device. If the component was generated off-device, the device OS detects that it is included in the loaded CAP file and knows not to generate it.

[0063] When updating a device OS, additional information can be provided about which CAP files have changed within the OS, so that only loaded CAP files that depend on them (as identified by checking CAP file dependencies) are relinked.

[0064] This method is suitable for binary compatible changes in software components.

[0065] If non-binary compatible changes are included in the new API component, the current software upgrade / loading process should be prohibited or dependent software components should be disabled. This binary compatibility check can be performed during the generation of the new software component or during the software update process itself.

Claims

1. 1. A method for relinking software components installed on a device being updated, the device including a CAP file, the method comprising creating a CAP file component called a link component (30), the link component (30) including a proprietary constant pool portion (31) constructed by using the original constant pool component of the CAP file, and a proprietary reference location portion (32) constructed by using the original reference location component and the original method component of the CAP file.

2. The method of claim 1 , wherein the link component (30) is generated off-device using knowledge of the binaries on which the CAP file depends.

3. The method of claim 1 , wherein the link component (30) is generated during loading of the CAP file onto the device.

4. The method of any one of claims 1 to 3, wherein the link components (30) are compressed when they are created.

5. 5. The method of claim 1, wherein the device's OS includes additional metadata that provides details about the updated CAP file portion of the OS to improve the relinking process.

6. The method of claim 5 , wherein the details include a list of the updated CAP files, whereby only downloaded CAP files that depend on modified CAP files are relinked.

Images