How to relink software components installed on a device during an update

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, software component or software) characterized by components that interact with each other and widely used concepts such as component dependencies, type hierarchies, extensions, instance-based objects, etc.

[0002] The present invention is particularly applicable to electronic devices such as smartphones and M2M (Machine to Machine) devices that cooperate with secure elements such as smart cards, Sim cards, UICC (Universal Integrated Circuit Card), e-UICC (embedded UICC), or ie-UICC (integrated embedded UICC), especially IoT (Internet of Things) devices with small-scale computing functions and power.

[0003] Upgrading software components may be required to fix bugs, add new features, improve performance or security, and upgrade complete APIs or component versions. However, in order to ensure that an application runs on a new version of a software component, it is necessary to retain existing data and perform the upgrade.

[0004] However, in complex updates, it can be very difficult to update software while maintaining existing dependent data as it is.

[0005] Two solutions are known for upgrading software. Dynamic linking and static linking.

[0006] In dynamic linking, shared libraries and dependencies are linked during software execution. Because linking occurs during execution, the base API can be updated without issue, as long as compatibility is maintained. However, dynamic linking requires considerable processing power and memory, making this solution suitable for high-resource / powerful hardware. Maintaining efficient and fast execution is extremely difficult in embedded environments with limited resources and processing power (e.g., for M2M applications and IoT devices) or on systems with high memory access penalties.

[0007] In such constrained environments, static linking is usually the preferred implementation because it enables fast execution despite the required initial linking phase.

[0008] In statically linked software components, component dependencies make upgrading the base libraries (such as APIs) extremely complex, requiring very careful and memory-intensive custom patching. Therefore, considering the risks and workload, a full-scale upgrade of the base API on a constrained platform such as an embedded chip or smart card after the product (device) has been released to the field is generally not considered feasible.

[0009] A method for achieving Java card system patches is known from CN-103914351, titled "Method for achieving Java card system patches." This method includes the steps of generating a patch application, downloading the patch application, installing the patch application, removing service packs and the patch application, and running the patch.

[0010] The problem with this solution is that it doesn't address situations where the entire Java API needs to be replaced. In other words, this document only addresses tweaked patch updates, not API replacements.

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

[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. The software may 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 referred to as 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 binary on which the CAP file depends.

[0017] In another embodiment, the link component occurs while loading the CAP file into the device.

[0018] Link components are preferably compressed during creation.

[0019] Advantageously, the device's OS includes additional metadata that provides details about the updated CAP file portion of the OS in order 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 the modified CAP file are relinked.

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

[0022] A typical example of using the present invention is software installed on a Java Card product and run 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 component defined within this CAP file. If no optional components such as applet components or debug components are included, they are represented within the directory component.

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

[0027] The applet component contains an entry for each applet defined in this package.

[0028] The class component describes each class and interface defined in this package. It does not include complete access information and content details for each class and interface. Instead, the information included is limited to what is necessary to perform the operations associated with a particular class or interface without performing verification. The complete details regarding the classes and interfaces defined in this package are included in the descriptor component. The information included in the class component for each interface is sufficient to uniquely identify the interface and test whether a cast to that interface is valid.

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

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

[0031] A constant pool component contains entries for each class, method, and field referenced by elements within a method component. Reference elements within a method component can be instructions within a method or exception handler catch types within an exception handler table.

[0032] Entries within a constant pool component refer to elements within class components, method components, and static field components. They also use package tokens to access import components, describing references to classes, methods, and fields defined within imported packages. Entries within a constant pool component do not refer to other entries within itself.

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

[0034] Export components list all static elements in this package that may be imported by classes in other packages. Instance fields and virtual methods are not represented in export components.

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

[0036] Descriptor component 14 provides sufficient information to analyze and verify all elements of the CAP file.

[0037] The constant pool component contains the constants necessary to execute the code of a particular class. Essentially, it's a runtime data structure similar to a symbol table. It's a per-class or per-interface runtime representation in a Java class file.

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

[0039] The static field component contains all the information necessary to create and initialize images for all static fields defined within this package, which are referred to as static field images.

[0040] An offset for a specific static field is an offset to the static field image, not an offset to the static field component.

[0041] During the linking phase, external references within the CAP file are converted from tokenized form on the device to an internal representation used by the virtual machine. The reference location component represents a list of offsets from the method component's information item to the item containing the index of the constant pool component into the constant pool array. [Brief explanation of the drawing]

[0042] [Figure 1] The single diagram shows the header component 10, directory component 11, constant pool component 12, static field component 13, descriptor component 14, reference location component 15, debug component 16, applet component 20, import component 21, method component 22, class component 23, and 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 afterward. They are typically removed from the device after the linking operation to save 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 external tools 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 afterward for the correct 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 a modified version used during the linking operation, and is suitable for execution of the CAP file by the JCVM.

[0044] During the linking operation, a proprietary link component 30 (having a sub-constant pool 31 and a reference position 32) is generated and must also be stored on the device.

[0045] Link component 30 is ○When the CAP file is loaded onto the device and linked by the device, ○CAP files are off-device and use knowledge of the binaries they depend on, and can be generated when this leads to improved linking times on the device.

[0046] In a typical scenario, the device OS initially contains several CAP files (e.g., those implementing built-in APIs), and then additional CAP files that depend on the initially existing CAP files are later downloaded to the device, allowing complementary functionality to be added to the device.

[0047] If the device OS is updated later, especially if the CAP file originally present in the OS is updated, it may be necessary to relink the downloaded CAP file because the CAP file 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 file present in the OS may have changed.

[0048] A simple relinking implementation involves retaining all components necessary for the linking operation, including the original method components. However, this approach significantly impacts the memory size required to store the CAP file, posing a problem for memory-constrained devices.

[0049] The proprietary link component 30 consists of two parts. ○ A proprietary constant pool portion 31 (step 40) is constructed using the original constant pool component 12, but is preferably reorganized to reduce its size. ○ A proprietary reference location portion 32 constructed using the original reference location component 15 (step 41) and the 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 section 31 is described below.

[0053] [Table 2]

[0054] The contents of the proprietary constant pool portion 31 are equivalent to those of the standard constant pool component 12, but are reorganized and sorted by type, thus eliminating the need for padding bytes (as used in the standard component) and thus reducing the overall size of the proprietary component. However, as a result of this transformation, the indices to the standard constant pool component 12 found within the original method component must be converted to indices to the proprietary constant pool portion 31. This issue is addressed in the next step of constructing the proprietary reference position 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 the OFFSETS within the method component that can find the index in the constant pool component. In each stream, when a byte has a value of 0xFF (255), it must be added to the value of the next byte, and so on, until the byte value is different from 0xFF, to obtain the OFFSET within the method component. 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 1-byte value (in byte_index_part) or a 2-byte value (in byte2_index_part) immediately after each OFFSET. For each OFFSET, the value to be inserted is an index in the proprietary constant pool portion 31, which is converted from the index found in the OFFSET within the original method component. The result of this conversion is shown below.

[0058] [Table 4]

[0059] As a result of this conversion, the information required 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 link component 30 is retained and used instead, it is not necessary to retain the original method component, constant pool component 12, and reference position component 15 in order to relink the CAP file. This method significantly reduces the memory size impact of supporting the CAP file relinking mechanism and the memory size required to support OS update scenarios.

[0061] The link component 30 can be further compressed when it is created to further reduce its size and can be decompressed on the fly during the relinking operation.

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

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

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

[0065] If a new API component contains non-binary compatible changes, 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. A method for relinking software components installed on a device being updated, wherein the device includes a CAP file and processing circuitry. The method described above includes the processing circuit creating a CAP file component referred to as a link component (30), The aforementioned link component (30) is A proprietary constant pool portion (31) constructed by using the original constant pool component of the CAP file, A method comprising: 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 according to claim 1, wherein the link component (30) is generated by the processing circuit off-device using knowledge of the binary on which the CAP file depends.

3. The method according to claim 1, wherein the link component (30) is generated by the processing circuit while loading the CAP file onto the device.

4. The method according to any one of claims 1 to 3, wherein the link component (30) is compressed by the processing circuit when it is created.

5. The method according to any one of claims 1 to 3, wherein the OS of the device includes additional metadata that provides details about the updated CAP file portion of the OS in order to improve the relinking process.

6. The method according to claim 5, wherein the details include a list of the updated CAP files, so that only downloaded CAP files that depend on the modified CAP files are relinked by the processing circuit.

Images