KR100996632B1

KR100996632B1 - Apparatus and method of dynamically upgrading an execution code image

Info

Publication number: KR100996632B1
Application number: KR20080080551A
Authority: KR
Inventors: 이민석
Original assignee: (주)세븐코아
Priority date: 2008-08-18
Filing date: 2008-08-18
Publication date: 2010-11-25
Also published as: KR20100021892A

Abstract

The apparatus for dynamically upgrading an executable code image includes a memory unit for storing at least a portion of the executable code image, a download agent unit for downloading the upgrade image upgraded in units of functions and storing the downloaded upgrade image in the memory unit; Extracting a first function requiring an upgrade from the at least some executable code images based on the upgrade image, checking whether the extracted first function is at a safety point, and installing a first trap code in the first function An image upgrade agent unit and a trap handler for processing the first trap code when the first function is called. Therefore, a device for dynamically upgrading an executable code image can be upgraded dynamically without rebooting when upgrading a specific device.

Description

Device and method for dynamically upgrading executable code images {APPARATUS AND METHOD OF DYNAMICALLY UPGRADING AN EXECUTION CODE IMAGE}

Embodiments of the present invention are directed to an apparatus and method for dynamically upgrading an executable code image without rebooting.

Embedded System is a system with special functions by embedding the software that operates the system into the hardware. Unlike personal computers, embedded systems have specific requirements and perform predefined tasks. In embedded systems, operating systems and applications are stored as images in nonvolatile RAM (random access memory), such as flash memory.

Embedded systems can be used in cellular phones, spaceships, robot controls, smartphones, personal digital assistants or satellites, and frequently require operating systems and applications for bug fixes, performance enhancements, or feature additions. Upgrade.

One embodiment is to provide an apparatus for dynamically upgrading an executable code image.

One embodiment is to provide a method for dynamically upgrading an executable code image.

One embodiment is to provide a system for dynamically upgrading an executable code image.

In an embodiment, the apparatus for dynamically upgrading an executable code image may include: a memory unit storing at least a portion of the executable code image; downloading an upgrade image upgraded by a function unit, and storing the downloaded upgrade image in the memory unit; The download agent unit extracts a first function that needs to be upgraded from the at least some executable code images based on the upgrade image, checks whether the extracted first function is located at a safety point, and adds the first function to the first function. And an image upgrade agent unit for installing a first trap code, and a trap handler for processing the first trap code when the first function is called.

The trap handler may call an upgrade function corresponding to the first trap code. If necessary, the trap handler temporarily stores and deletes the contents stored in the stack when the first function is called, and when the first function is called, the temporary stored contents are returned from the upgrade function. May be restored to the stack to return to the function that called the first function.

The memory unit may include an upgrade table including a trap identifier indicating the first trap code and an upgrade function corresponding to the trap identifier.

The image upgrade agent unit may examine the call tree of a function currently being executed and determine that the first function is at the safety point if the first function is not included in the call tree.

The apparatus may further include a flash memory unit including a full executable code image (including the at least some executable code images), wherein the image upgrade agent unit is further configured to upgrade from the full executable code image based on the upgrade image. The second function may be extracted and stored in the flash memory unit so as to restore the extracted second function, and a second trap code may be installed in the second function to upgrade the entire execution code image.

For example, the device for dynamically upgrading the executable code image may correspond to a wirelessly communicable device including a cellular phone.

The image upgrade agent unit may upgrade the first function to an upgrade function corresponding to the first trap code when the device for dynamically upgrading the executable code image is rebooted.

In one or more embodiments, a method for dynamically upgrading an executable code image may include downloading an upgraded image that is upgraded by a function unit and storing the downloaded upgraded image in a memory unit. Extracting a first function requiring an upgrade from an executable code image, checking whether the extracted first function is at a safe point, installing a first trap code in the first function, and calling the first function Processing the first trap code as such.

Processing the first trap code may include calling an upgrade function corresponding to the first trap code.

The invoking the upgrade function may include temporarily storing and deleting contents stored in a stack when the first function is called, invoking the upgrade function, and temporarily returning from the upgrade function. Restoring the stored contents to the stack and returning to the function calling the first function.

The at least some execution code images may include an upgrade table including a trap identifier representing the first trap code and an upgrade function corresponding to the trap identifier.

The step of installing the first trap code in the first function is to examine the call tree of a function that is currently being executed, and if the first function is not included in the call tree, the first function is at the safety point. Determining may include.

Among embodiments, a system for dynamically upgrading an executable code image includes a development host that generates a program code or executable code image, an upgrade server that generates an upgrade image based on the generated program code or executable code image, and the upgrade. A target system that can be wirelessly connected to a server, the target system comprising: a memory unit for storing at least a portion of an executable code image; A download agent unit which downloads the upgrade image upgraded by a function unit and stores the downloaded upgrade image in the memory unit; Extracting a first function requiring an upgrade from the at least some executable code images based on the upgrade image, checking whether the extracted first function is at a safety point, and installing a first trap code in the first function An image upgrade agent unit; And a trap handler that processes the first trap code when the first function is called.

One embodiment may perform the upgrade dynamically without rebooting in upgrading a particular device. If desired, one embodiment may dynamically upgrade the executable code image by installing trap code based on whether a function that needs to be upgraded is at a safe point.

One embodiment may ensure a secure upgrade in upgrading a particular device. If desired, one embodiment may manipulate the stack in the course of processing the trap code.

In one embodiment, when a specific device is booted, the execution code image may be upgraded by removing the trap code.

Since the description of the embodiments is merely illustrated for structural to functional descriptions, the scope of the claims should not be construed as limited by the embodiments described herein. That is, the embodiments may be variously modified and may have various forms, and thus, the scope of rights should be understood to include equivalents for realizing the technical spirit of the embodiments.

On the other hand, the meaning of the terms described in the specification should be understood as follows.

The terms " first ", " second ", and the like are used to distinguish one element from another and should not be limited by these terms. For example, the first component may be named a second component, and similarly, the second component may also be named a first component.

The term “and / or” should be understood to include all combinations that can be presented from one or more related items. For example, "first item, second item, and / or third item" means "at least one or more of the first item, second item, and third item", and means first, second, or third item. A combination of all items that can be presented from two or more of the first, second and third items as well as the third item.

When a component is referred to as being "connected" to another component, it should be understood that there may be other components in between, although it may be directly connected to the other component. On the other hand, when an element is referred to as being "directly connected" to another element, it should be understood that there are no other elements in between. On the other hand, other expressions describing the relationship between the components, such as "between" and "immediately between" or "neighboring to" and "directly neighboring to", should be interpreted as well.

Singular expressions should be understood to include plural expressions unless the context clearly indicates otherwise, and terms such as "include" or "have" refer to features, numbers, steps, operations, components, parts, or parts thereof described. It is to be understood that the combination is intended to be present, but not to exclude in advance the possibility of the presence or addition of one or more other features or numbers, steps, operations, components, parts or combinations thereof.

Each step may occur differently from the stated order unless the context clearly dictates the specific order. That is, each step may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

All terms used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and shall be construed to have ideal or overly formal meanings unless expressly defined herein. Can't be.

1 is a diagram illustrating a dynamic upgrade system according to an embodiment, and FIG. 5 is a flowchart illustrating the operation of the upgrade system.

Referring to FIG. 1, the dynamic upgrade system 100 includes a development host 110, an upgrade server 120, and a target system 130.

The development host 110 may write program code for upgrading the target system 130, and convert the generated code into an executable code image as needed. That is, development host 110 generates a program code or an executable code image. In one embodiment, development host 110 may provide an Integrated Development Environment (IDE) so that programmers may conveniently perform this process. The development host 110 transmits the program code or the executable code image to the upgrade server 120 (step S510).

The upgrade server 120 stores the transmitted program code or execution code image (step S520). In one embodiment, if the program code has been transmitted, the upgrade server 120 may convert the program code into an executable code image. As a result, the upgrade server 120 generates an upgrade image based on the program code or executable code image.

The upgrade server 120 transmits the upgrade image to the target system 130 to upgrade the target system 130 (steps S540 and S550).

Meanwhile, the development host 110 or the upgrade server 120 converts the program code so that the executable code image can be upgraded in units of functions. 4 is a diagram for describing an execution code image, according to an exemplary embodiment.

In FIG. 4, the executable code image may be implemented in a form similar to the Executable and Linking Format (ELF) file format, and may be upgraded by a function unit.

Execution code image 400 (hereinafter referred to as "upgrade image") includes dynamic upgrade header 410, text section 420, data section 430, symbol section 440, symbol table header 442, string Section 450 and section header table 460.

The dynamic upgrade header 410 may include information such as Central Processing Unit (CPU) and operating system information, and may include text section 420, data section 430, symbol section 440, symbol table header. 442, link information of the string section 450 and the section header table 460.

Text section 420 contains instruction code executable for each function. The data section 430 contains information about the data used when dynamically performing data upgrades. The symbol section 440 includes a symbol header table 442, and the symbol header table 442 may include a string table index, a symbol offset, a symbol size, a symbol value, and a symbol type as information about a symbol. The string table index may represent a string table address for the symbol, the symbol offset, symbol size and symbol value may indicate the position, size and address of the symbol in the upgrade image, respectively, and the symbol type is a code symbol or a data symbol. Can be used to distinguish cognition. The string section 40 may include a symbol name. The section header table 460 may include information about a section.

Referring back to FIG. 1, the target system 130 corresponds to an apparatus for dynamically upgrading an executable code image without rebooting, and corresponds to an embedded system that performs a particular task. For example, target system 130 may correspond to a wirelessly communicable device including a cellular phone.

FIG. 2 is a diagram for describing an upgrade server of FIG. 1.

2, the upgrade server 120 includes a control unit 210, an upgrade database 220, an image storage unit 230, and an upgrade agent unit 240.

The controller 210 controls the overall operation of the upgrade server 120. For example, the controller 210 may control an operation required by the upgrade server 120 when performing communication between the development host 110 and the upgrade server 120 or between the upgrade server 120 and the target system 130. Can be.

The upgrade database 220 stores the target system information and the upgrade history information. In one embodiment, if the target system 130 corresponds to a cellular phone, the target system information may store an identifier such as a cellular phone number and a cellular phone type. In one embodiment, the upgrade history information includes a current version of the executable code image operated on the target system 130 and may further include past versions of the executable code image that were operated on the target system 130 as needed. .

The image storage unit 230 stores the execution code image according to the target system information and the upgrade history information defined in the upgrade database 220. For example, even though the executable code image may have the same version, it may vary depending on the target system information.

The upgrade agent unit 240 includes a transmission manager 242 and a security manager 244. When the security manager 244 transmits the executable code image stored in the image storage 230 to the target system 130, the security manager 244 encrypts the executable code image. In one embodiment, the security management unit 244 may employ a symmetric cryptographic algorithm, such as the Data Encryption Standard (DES), and in another embodiment, the security management unit 244 is associated with a Rivest-Shamir-Adelman (RSA). The same asymmetric cryptographic algorithm can be adopted. The transmission manager 242 transmits the encrypted execution code image to the target system 130. In one embodiment, the delivery management unit 242 may transmit the wirelessly encrypted execution code image, in another embodiment, the transmission management unit 242 may transmit the encrypted execution code image by wire.

FIG. 3 is a diagram for describing the target system of FIG. 1, and FIG. 6 is a flowchart for explaining an upgrade process of the target system.

Referring to FIG. 3, the target system 130 includes a controller 310, a download agent 320, a memory 330, a flash memory 340, and an image upgrade agent 350.

The controller 310 includes a trap handler 312, controls the overall operation of the target system 130, and executes an executable code image. In one embodiment, if the target system 130 corresponds to a cellular phone, the controller 310 may correspond to an application processor in the cellular phone. The trap handler 312 will be described later.

The download agent unit 320 includes a download unit 322 and a security agent unit 324. The download unit 322 downloads the encrypted executable code image from the upgrade server 120. The security agent unit 324 decrypts the downloaded executable code image. The download agent 320 downloads the decrypted execution code image (hereinafter referred to as an "upgrade image") and stores the downloaded upgrade image in the memory unit 330 (step S610).

The memory unit 330 may store at least some executable code images. That is, the memory unit 330 may store a part of the execution code image of the current version for the operation of the target system 130. In addition, the memory unit 330 may store an upgrade table for managing the upgrade for each function.

The flash memory unit 340 includes an entire executable code image including some executable code images operated by the memory unit 330. Here, the flash memory unit 340 corresponds to a concept including a nonvolatile random access memory (NRAM).

The image upgrade agent unit 350 may include an image upgrade unit 352, a version manager 354, a flash upgrade unit 356, and a safety point manager 358. The image upgrade agent unit 350 extracts a first function that needs to be upgraded from at least some executable code images stored in the memory unit 330 based on the upgrade image, and checks whether the extracted first function is at a safety point. To install the first trap code in the first function.

7 is a diagram for explaining a process of installing a trap code.

Although FIG. 7 assumes that the trap code corresponds to the interrupt code, the trap code may correspond to a code according to a separate function or processor as necessary.

In FIG. 7, when the current display function 710 needs to be upgraded, the image upgrade agent unit 350 interrupts the first portion of the current display function 710 to perform another display function in the upgrade image. Replace with code to create the upgraded display function 720.

3 and 6 again, the image upgrader 352 checks the version of the upgraded image through the version manager 354 (steps S620 and S630). The version manager 354 determines whether to upgrade the current executable code image to the upgrade image based on the versions of the current executable code image and the upgrade image. If the version manager 354 decides to upgrade the current executable code image, the version manager 354 generates a list of functions that need to be upgraded among the entire executable code images and transmits the list to the image upgrade unit 352. (Step S640).

The image upgrader 352 extracts a first function from at least some executable code images stored in the memory unit 330 by comparing the functions included in the list with functions in at least some executable code images stored in the memory unit 330. (Step S650).

The image upgrader 352 checks whether the first function is at the safety point through the safety point manager 358 (step S660). In one embodiment, the safety point manager 358 may examine the call tree of a function currently being executed and determine that the first function is at a safe point if the first function is not included in the call tree.

If the safety point management unit 358 determines that the first function is at the safety point, the image upgrade unit 352 installs a first trap code in the first function, and the image upgrade unit 352 stores the memory unit 330. The upgrade table stored in the server is updated (step S670). The upgrade table may be composed of a trap identifier representing the first trap code and an upgrade function corresponding to the trap identifier. Otherwise, the image upgrade unit 352 repeats the above processes with respect to the other first function, and later upgrades the first function if the first function is at a safety point.

The flash upgrade unit 356 extracts a second function that needs to be upgraded from the entire execution code image based on the upgrade image, and stores the flash function in the flash memory unit 340 so as to restore the second function. Install the trap code to upgrade the entire executable code image. That is, the flash upgrade unit 356 stores a function to be upgraded to restore the current executable code image in the flash memory unit 340 and upgrades the current executable code image.

When the controller 310 encounters the trap code while executing the upgrade image, the controller 310 processes the trap code through the trap handler 312. The trap handler 312 processes the first trap code when the first function is called. In one embodiment, the trap handler 312 may call an upgrade function corresponding to the first trap code. The trap handler 312 temporarily stores and deletes the contents stored on the stack in the memory unit 330 when the first function is called, and calls the upgrade function and then temporarily stores the contents stored on the stack when returning from the upgrade function. You can restore it and return to the function that called the first function.

8 is a diagram for describing a processing procedure of a trap handler.

In Fig. 8, when the original function (that is, the function in which the trap code is installed) is called (step S810), the controller 310 finds a trap code (step S820). The trap handler 312 retrieves the upgrade function corresponding to the trap code from the upgrade table after manipulating the stack (step S830).

The trap handler 312 retrieves the retrieved upgrade function (step S840) and calls the upgrade function (step S850). When the upgrade function is returned (step S860), the trap handler 312 again manipulates the stack and returns the original function to the calling function (step S870).

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the present invention as defined by the following claims It can be understood that

Embodiments presented above may have the effect of including the following advantages. However, it is not to be understood that the scope of the present invention is limited thereto, because it does not mean that all embodiments should include all or specific embodiments should include only the following advantages.

One embodiment may upgrade the executable code image by removing the trap code when a particular device is booted.

1 is a diagram illustrating a dynamic upgrade system according to an exemplary embodiment.

FIG. 2 is a diagram for describing an upgrade server of FIG. 1.

FIG. 3 is a diagram for describing the target system of FIG. 1.

4 is a diagram for describing an execution code image, according to an exemplary embodiment.

5 is a flowchart illustrating the operation of the upgrade system.

6 is a flowchart illustrating an upgrade process of a target system.

7 is a diagram for explaining a process of installing a trap code.

8 is a diagram for describing a processing procedure of a trap handler.

Claims

A memory unit for storing an upgrade table for managing upgrades for at least some executable code images and functions;

A download agent unit which downloads the upgrade image upgraded by a function unit and stores the downloaded upgrade image in the memory unit;

Generate a list of functions that need to be upgraded among all executable code images based on the upgrade image to extract a first function that needs to be upgraded from the at least some executable code images, and determine whether the extracted first function is at a safety point. An image upgrade agent unit checking whether or not to install a first trap code in the first function, wherein the image upgrade agent unit examines a call tree of a function currently being executed and does not include the first function in the call tree. Determine that the first function is at the safety point; And

A trap handler that processes the first trap code when the first function is called,

The image upgrade agent unit

And if the device is rebooted, dynamically upgrading an executable code image that upgrades the first function to an upgrade function corresponding to the first trap code.

The method of claim 1, wherein the trap handler is

And an upgrade function corresponding to the first trap code.

The method of claim 2, wherein the trap handler is

When the first function is called, the contents stored in the stack are temporarily stored and deleted in the memory unit, and the temporary stored contents are restored to the stack when the upgrade function is called and then returned from the upgrade function. 1 A device for dynamically upgrading an executable code image, characterized by a return to the function that called the function.

The method of claim 2 or 3, wherein the memory unit

And an upgrade table comprising a trap identifier representing the first trap code and an upgrade function corresponding to the trap identifier.

delete

The method of claim 1,

Further comprising a flash memory unit including a full executable code image (including the at least part of the executable code image),

The image upgrade agent unit extracts a second function that needs to be upgraded from the entire execution code image based on the upgrade image, and stores the extracted second function in the flash memory unit so as to restore the extracted second function. And installing a second trap code to upgrade the entire executable code image.

2. The apparatus of claim 1, wherein the apparatus for dynamically upgrading an executable code image corresponds to a wirelessly communicable device including a cellular phone.

delete

Downloading the upgrade image upgraded by a function unit and storing the downloaded upgrade image in a memory unit;

Generating a list of functions to be upgraded among all executable code images based on the upgrade image and extracting a first function to be upgraded from at least some executable code images;

Checking whether the extracted first function is at a safety point and installing a first trap code in the first function;

Processing the first trap code when the first function is called; And

If rebooting, upgrading the first function to an upgrade function corresponding to the first trap code;

Installing the first trap code is

Dynamically upgrading the executable code image comprising examining the call tree of a function currently being executed and determining that the first function is at the safe point if the call tree does not include the first function. Way.

10. The method of claim 9, wherein processing the first trap code

Invoking an upgrade function corresponding to the first trap code.

The method of claim 10, wherein the step of calling the upgrade function

Temporarily storing and deleting contents stored on a stack in the memory unit when the first function is called;

Calling the upgrade function; And

Restoring the temporarily stored content to the stack when returning from the upgrade function, and returning to the function that called the first function.

12. The method of claim 10 or 11, wherein the at least some executable code images are

delete

A development host for generating a program code or executable code image, wherein the executable code image may be implemented in the form of an Executable and Linking Format (ELF) file;

An upgrade server for generating an upgrade image based on the generated program code or executable code image; And

Including a target system that can be wirelessly connected to the upgrade server,

The upgrade server encrypts the upgrade image through a Data Encryption Standard (DES) or Rivest-Shamir-Adelman (RSA) encryption algorithm.

The target system

The image upgrade agent unit

A system for dynamically upgrading an executable code image that upgrades the first function to an upgrade function corresponding to the first trap code when the device is rebooted.