Method for starting an embedded system, a startup program, and an embedded system

Abstract

To suppress delay of starting time while ensuring the integrity of a program when starting a built-in system.SOLUTION: In a method for starting a built-in system (100), a processor is included in the built-in system having a main storage section (150), and a nonvolatile storage section (140) that stores a snapshot image (250) on the basis of a state of the main storage section (150) which is at least a first program (230). The processor performs alteration verification to the snapshot image (250) transferred from the nonvolatile storage section (140) to the main storage section (150) when starting and executes the first program (230) restored on the main storage section (150) from the snapshot image (250a) transferred to the main storage section (150) when confirmed to be normal in the alteration verification.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] The present disclosure relates to a method for starting an embedded system, a startup program, and an embedded system.

Background Art

[0002] An electronic device incorporating an electronic board equipped with a processor, a memory, a flash memory, etc. is also called an embedded system. In an embedded system, in order to start programs such as an OS (Operating System) at high speed, a RAM (Random Access Memory) image including the execution state of a program during program execution is stored in advance in a flash memory or the like, and at the next startup, the RAM image is loaded from the flash memory or the like into the RAM. Here, Patent Document 1 discloses a technique of pre-loading a part of the RAM image into the RAM at startup and sequentially loading pages that have caused page faults during program execution into the RAM. Note that the RAM image is also called a snapshot image.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In recent years, embedded systems have been required to have high security, and the integrity of target programs must be verified before execution. Therefore, if an embedded system uses a fast startup method that reads a snapshot image at startup, it is necessary to perform security checks such as tamper checks on the snapshot image. However, simply performing security checks on the snapshot image at the time of startup of an embedded system increases the read processing from flash memory, etc., resulting in a problem of slow startup time. It should be noted that the technology described in Patent Document 1 mentioned above does not deal with tamper checks on snapshot images.

[0005] This disclosure has been made in view of the above-mentioned issues, and aims to provide an embedded system startup method and startup program, as well as an embedded system, that can suppress startup time delays while ensuring program integrity during the startup of the embedded system. [Means for solving the problem]

[0006] A first aspect of this disclosure provides a startup method for an embedded system, comprising a processor in an embedded system having a main memory and a non-volatile storage unit storing a snapshot image based on the state of the main memory while at least a first program is running, wherein at startup, the processor performs tamper-proof verification on the snapshot image transferred from the non-volatile storage unit to the main memory, and if the tamper-proof verification confirms normal operation, executes the first program restored on the main memory from the snapshot image transferred to the main memory.

[0007] A second aspect of this disclosure provides a startup program for an embedded system having a main memory unit and a non-volatile storage unit storing a snapshot image based on the state of the main memory unit while at least a portion of a program is being executed. The program causes the system to perform, at startup, a process of verifying that the snapshot image transferred from the non-volatile storage unit to the main memory unit has been tampered with, and, if the tampering verification confirms that the system is functioning correctly, a process of executing the program restored on the main memory unit from the snapshot image transferred to the main memory unit.

[0008] A third aspect of this disclosure provides an embedded system comprising a main memory unit and a non-volatile storage unit that stores a snapshot image based on the state of the main memory unit while at least a portion of a program is being executed, wherein at startup, tampering verification is performed on the snapshot image transferred from the non-volatile storage unit to the main memory unit, and if the tampering verification confirms normal operation, the program restored on the main memory unit from the snapshot image transferred to the main memory unit is executed. [Effects of the Invention]

[0009] This disclosure provides an embedded system startup method and startup program, as well as an embedded system, that ensure program integrity during startup while suppressing startup time delays. [Brief explanation of the drawing]

[0010] [Figure 1] This is a block diagram showing the configuration of the embedded system according to this embodiment 1. [Figure 2] This figure shows an example of data stored in the non-volatile memory unit according to this embodiment 1. [Figure 3] This is a block diagram showing the functional configuration of the embedded system according to this first embodiment. [Figure 4] This flowchart shows the startup process flow of the embedded system according to this embodiment 1. [Figure 5] This is a sequence diagram showing the flow of the snapshot image startup process according to this embodiment 1. [Figure 6] This is a diagram illustrating the concept of the snapshot image startup process according to this first embodiment. [Figure 7] This is a sequence diagram showing the flow of the snapshot image startup process according to another embodiment of this embodiment 1. [Figure 8] This is a diagram illustrating the concept of the snapshot image startup process according to another embodiment of this first embodiment. [Figure 9] This is a block diagram showing the functional configuration of the embedded system according to this second embodiment. [Figure 10] This is a flowchart showing the flow of the snapshot image storage process according to this second embodiment. [Figure 11] This is a diagram illustrating the concept of the snapshot image storage process according to this second embodiment. [Modes for carrying out the invention]

[0011] In the following, specific embodiments of this disclosure will be described in detail with reference to the drawings. In each drawing, the same elements are denoted by the same reference numerals, and redundant explanations will be omitted where necessary for clarity.

[0012] <Embodiment 1> Figure 1 is a block diagram showing the configuration of the embedded system 100 according to this embodiment 1. The embedded system 100 is a computer system for realizing a specific function. The embedded system 100 is an electronic device equipped with a microcomputer, etc., which is mounted on, for example, home appliances, industrial equipment, mobile devices, etc. Examples of electronic devices include, but are not limited to, car navigation systems, television receivers, hard disk recorders, etc. The embedded system 100 comprises at least a processor 110, a BootROM (Read Only Memory) 120, a 1timeROM 130, a non-volatile storage unit 140, and a main memory unit 150.

[0013] The processor 110 is a control device that controls each part of the embedded system 100. The processor 110 may be, for example, a CPU (Central Processing Unit), and may also include an MMU (Memory Management Unit). Alternatively, it may be a combination of multiple CPUs, FPGAs (Field Programmable Gate Arrays), ASICs (Application Specific Integrated Circuits), etc., that work together to control each part.

[0014] BootROM120 is a memory device that stores initial processing programs, such as the system BIOS (Basic Input / Output System), which the processor 110 reads when power is applied to the embedded system 100. The initial processing program is a computer program that implements the process of verifying the first boot program (described later), and loading and starting the first boot program if the verification is successful. BootROM120 may be configured by dividing it into areas on the non-volatile memory unit 140 (described later).

[0015] The one-time ROM 130 is, for example, but not limited to, a ROM that can be written only once. The one-time ROM 130 stores cryptographic key information such as the public key 131 and device-specific ID information. The public key 131 is the public key used by the above-described initial processing program during verification. The Boot ROM 120 and the one-time ROM 130 are preferably configured as a secure area and may be configured on-chip together with the processor 110.

[0016] The non-volatile memory unit 140 is a non-volatile memory device that stores various programs and data executed in the embedded system 100. The non-volatile memory unit 140 may be a semiconductor memory such as a flash memory or a hard disk or the like. The non-volatile memory unit 140 includes, for example, but is not limited to, eMMC (embedded Multi Media Card), a flash ROM, etc. as an example of a flash memory. Incidentally, the non-volatile memory unit 140 is also referred to as an external memory device or an auxiliary storage device.

[0017] FIG. 2 is a diagram showing an example of data stored in the non-volatile memory unit 140 according to Embodiment 1. The non-volatile memory unit 140 stores a first startup program 210, a second startup program 220, a first program 230, a second program 240, and a snapshot image 250.

[0018] The first boot program 210 is a computer program that verifies the second boot program 220 and loads and starts the second boot program if the verification confirms that it is functioning correctly. The first boot program 210 is a program that implements the so-called boot loader processing. The first boot program 210 may also be encrypted and signed with a private key (not shown). Here, the private key is the key paired with the public key 131 described above. The first boot program 210 is assumed to implement more complex processing than the initial processing program described above. Specifically, the first boot program 210 implements processing to verify that the second boot program 220 and the snapshot image 250 have not been tampered with. The first boot program 210 also implements processing to instruct the second boot program 220 to transfer the snapshot image 250 to the main memory 150. Furthermore, the first startup program 210 has implemented a process to instruct the restoration of the snapshot image 250 if the tampering verification confirms that there has been no tampering and that the system is functioning correctly.

[0019] The second startup program 220 is a computer program that implements more complex processing than the first startup program 210 described above. Specifically, the second startup program 220 implements the process of transferring the snapshot image 250 from the non-volatile storage unit 140 to the main memory unit 150 in response to a transfer instruction from the first startup program 210. In particular, the second startup program 220 transfers the snapshot image 250 from the non-volatile storage unit 140 to the main memory unit 150 in the form of compressed data in a predetermined format. That is, the second startup program 220 copies the snapshot image 250 from the non-volatile storage unit 140 to the main memory unit 150. Any known format can be used for data compression, and is not limited here. Furthermore, the second startup program 220 implements the process of restoring the snapshot image 250 in response to a restore instruction from the first startup program 210. More specifically, the second startup program 220 decompresses the compressed data in the main memory 150 and restores the first program. Here, the process of restoring the snapshot image 250 is, for example, the process of restoring the state of the processor 110's hardware registers and memory to the same state as when the snapshot image 250 was created, that is, to a state where it can be executed again. Alternatively, the process of restoring the snapshot image 250 may be a process of unpacking the necessary operations as needed. By creating the snapshot image 250 in a form that allows for the decompression and restoration of compressed data to be performed together, the process from startup to snapshot restoration can be completed efficiently. Then, the second startup program 220 transitions to a state where the restored first program is executed.

[0020] The first program 230 includes one or more computer programs. Here, the first program 230 includes an OS (Operating System) 231, an application program 232, an application program 233, ... The OS 231 is the basic software and includes the kernel. Application programs 232 and 233 ... are application software that implements functions provided to the user in an electronic device.

[0021] The second program 240 includes one or more computer programs other than the OS. Here, the second program 240 includes application program 241, ... Application program 241 is application software different from the application programs 232 and 233 etc. mentioned above.

[0022] The snapshot image 250 is data outputting the state of the main memory 150 while the first program 230 is being executed. The snapshot image 250 includes the state in which the OS 231, application programs 232 and 233, etc., are loaded into the main memory 150. The snapshot image 250 also includes the contents of the registers, program counter, stack pointer, etc., during the execution of the OS 231, application programs 232 and 233, etc. The snapshot image 250 may also be compressed data compressed in a predetermined format. If the embedded system 100 does not require updating the snapshot image 250 and always starts the system with the same snapshot image 250, the configurations of the first program and the second program shown by the dashed lines in Figure 2 may not be necessary.

[0023] Returning to Figure 1, we continue the explanation. The main memory unit 150 is a storage area for temporarily holding information during the operation of the processor 110. The main memory unit 150 is also called a volatile memory unit, primary memory unit, or simply "memory". The main memory unit 150 is, for example, a high-speed volatile memory device such as RAM. Specifically, the main memory unit 150 may be DRAM (Dynamic RAM), SRAM (Static RAM), etc. For example, the main memory unit 150 stores the initial processing program, the first startup program 210, the second startup program 220, the first program 230, the second program 240, and the snapshot image 250, etc.

[0024] Furthermore, the embedded system 100 shall also include a general microcomputer configuration, although this configuration is not shown in the figures.

[0025] Figure 3 is a block diagram showing the functional configuration of the embedded system 100 according to this embodiment 1. Figure 3 shows the functional blocks when the processor 110 of the embedded system 100 loads various programs into the main memory 150 and executes them. Specifically, the processor 110 functions as an initial processing unit 160 by loading an initial processing program from the BootROM 120 into the main memory 150 and executing it. The initial processing unit 160 is a functional block that implements the initial processing of the embedded system 100 when it starts up, as implemented in the initial processing program described above.

[0026] Furthermore, the processor 110 functions as the first startup processing unit 161 by loading the first startup program 210 from the non-volatile memory unit 140 into the main memory unit 150 and executing it. The first startup processing unit 161 is a functional block implemented in the first startup program 210 that realizes the first startup process of the embedded system 100.

[0027] Furthermore, the processor 110 functions as a second startup processing unit 162 by loading the second startup program 220 from the non-volatile memory unit 140 into the main memory unit 150 and executing it. The second startup processing unit 162 is a functional block implemented in the second startup program 220 that realizes the second startup process of the embedded system 100.

[0028] Furthermore, the processor 110 functions as a functional block that implements the main processing of the embedded system 100, such as the snapshot unit 163, the basic function unit 170, and the application 171, by loading the first program 230 from the non-volatile storage unit 140 into the main memory unit 150 and executing it. The snapshot unit 163 generates a snapshot image 250 from the state of the main memory unit 150 while the program is running at a predetermined timing, for example, periodically or at a timing specified externally, and stores it in the non-volatile storage unit 140. The basic function unit 170 is a functional block that implements the processing implemented in the OS 231. Note that the snapshot unit 163 may also be implemented by processing implemented in the OS 231. The application 171 is a functional block that implements the processing implemented in application programs 232 and 233, ... Note that the processor 110 may implement the processing of a predetermined application by loading the second program 240 from the non-volatile storage unit 140 into the main memory unit 150 and executing it.

[0029] Figure 4 is a flowchart showing the startup process of the embedded system according to this embodiment 1. It is assumed that, as a prerequisite, the embedded system 100 has already stored the state of the main memory 150 of the various programs running during previous startups as a snapshot image 250 in the non-volatile storage unit 140.

[0030] First, the embedded system 100 is powered on. That is, the embedded system 100 receives a power-on notification (S101). As a result, the embedded system 100 starts the startup process. The processor 110 of the embedded system 100 reads the initial processing program described above from the BootROM 120 and executes the initial processing program (S102). As a result, the processor 110 functions as the initial processing unit 160.

[0031] Next, the initial processing unit 160 verifies the first startup program 210 (S103). Specifically, the initial processing unit 160 loads the first startup program 210 from the non-volatile storage unit 140 into the main memory unit 150. Then, the initial processing unit 160 verifies the encryption and signature of the first startup program 210 on the main memory unit 150 using the public key 131 in the 1timeROM 130. Note that the verification process by the initial processing unit 160 may use known techniques or other verification processes.

[0032] The initial processing unit 160 then determines whether the first startup program 210 has been successfully verified (S104). If the verification fails (NO in S104), the embedded system 100 terminates without starting. In this case, the embedded system 100 may output a message indicating that the verification failed.

[0033] Here, it is assumed that the first startup program 210 has been encrypted and signed in advance using the public key 131 and its corresponding private key. Therefore, the initial processing unit 160 uses the public key 131 to decrypt the first startup program 210 and verify its signature, and the verification is successful (YES in S104). Thus, the initial processing unit 160 executes the first startup program 210 (S105). As a result, the processor 110 functions as the first startup processing unit 161.

[0034] Next, the first startup processing unit 161 verifies the second startup program 220 (S106). Specifically, the first startup processing unit 161 loads the second startup program 220 from the non-volatile storage unit 140 into the main memory unit 150. Then, the first startup processing unit 161 calculates a hash value from the second startup program 220 on the main memory unit 150 and verifies it by comparing the calculated hash value with a pre-held verification hash value (not shown).

[0035] The first startup processing unit 161 then determines whether the second startup program 220 has successfully verified the results (S107). For example, verification is deemed to have failed if the verified hash values ​​are different. If verification fails (NO in S107), the embedded system 100 terminates without starting. At this point, the embedded system 100 may be rebooted by the Watchdog. Alternatively, the embedded system 100 may output a message indicating that verification has failed.

[0036] On the other hand, if the matched hash values ​​match, the verification is successful (YES in S107), and the first boot processing unit 161 performs the snapshot image boot process (S108). First, the first boot processing unit 161 executes the second boot program 220. As a result, the processor 110 also functions as the second boot processing unit 162.

[0037] Figure 5 is a sequence diagram showing the flow of the snapshot image startup process according to this embodiment 1. Figure 6 is a diagram illustrating the concept of the snapshot image startup process according to this embodiment 1. In the following description, Figures 5 and 6 will be referred to as appropriate.

[0038] First, the first startup processing unit 161 issues an initialization instruction to the second startup processing unit 162 (S111). In response, the second startup processing unit 162 performs initialization processing of the second startup program 220 (S112). After initialization is complete, the second startup processing unit 162 notifies the first startup processing unit 161 that initialization is complete (S113).

[0039] Then, the first startup processing unit 161 issues an instruction to the second startup processing unit 162 to transfer the snapshot image 250 (S114). At this time, the first startup processing unit 161 specifies the destination address of the snapshot image 250 in the main memory unit 150, that is, the starting address, and includes it in the transfer instruction. For example, the destination address is address addr1 in Figure 6.

[0040] In response, the second startup processing unit 162 transfers the snapshot image 250 from the non-volatile storage unit 140 to the main memory unit 150 (S115). At this time, the second startup processing unit 162 reads the snapshot image 250 from the non-volatile storage unit 140, transfers it to the main memory unit 150 using address addr1 as the starting address, and stores the snapshot image 250a. In the startup process, a simple image validation check may be performed on the snapshot image 250 in the non-volatile storage unit 140 before step S115. For example, the first startup processing unit 161 or the second startup processing unit 162 may perform a header and file SUM check of the snapshot image 250, and if there are no problems, proceed to step S115. At this point, the snapshot image 250a in the main memory unit 150 is assumed to be compressed data. In other words, the snapshot image 250a has been transferred to the main memory unit 150, but the internal programs have not yet been executed.

[0041] After step S115, the second startup processing unit 162 obtains the data size size from address addr2, which corresponds to the end of the snapshot image 250a transferred to the main memory unit 150, and notifies the first startup processing unit 161 of the completion of the transfer, including the data size size (S116).

[0042] In response, the first startup processing unit 161 performs tampering verification on the destination and pre-deployment snapshot image 250a (S117). In other words, the first startup processing unit 161 performs tampering verification on the snapshot image 250a in the main memory unit 150. Specifically, the first startup processing unit 161 calculates the end address, address addr2, by adding the data size size included in the transfer completion notification to the address addr1 specified in step S114. Then, the first startup processing unit 161 performs tampering verification on the range from address addr1 to addr2 in the main memory unit 150.

[0043] For example, the first startup processing unit 161 calculates a hash value for the snapshot image 250a and compares the calculated hash value with a pre-stored verification hash value (not shown). In other words, the first startup processing unit 161 determines whether the verification was successful or not. If the compared hash values ​​match, it is determined that the tampering verification was successful, that is, that the normal status was confirmed during the tampering verification. If the tampering verification fails, the embedded system 100 terminates without starting (not shown). In this case, the embedded system 100 may output a message indicating that the verification failed.

[0044] If the tampering verification confirms that the system is functioning correctly, the first startup processing unit 161 instructs the second startup processing unit 162 to restore the snapshot image 250a (S118). In response, the second startup processing unit 162 restores the first program 230a in the main memory unit 150 by expanding the snapshot image 250a (S119). For example, as shown in Figure 6, the first program 230a, including the OS 231a, application programs 232a and 233a, etc., is ultimately transferred to the main memory unit 150. At the same time, the second startup processing unit 162 sets the register contents, program counter, stack pointer, etc., of the OS 231a, application programs 232a and 233a, etc., included in the snapshot image 250a. The second startup processing unit 162 may release the snapshot image 250a from the main memory unit 150 after restoration.

[0045] Subsequently, the second startup processing unit 162 executes the restored first program 230a (S120). As a result, the embedded system 100 resumes program execution in the state it was in when the snapshot image 250 was taken. In other words, the embedded system 100 starts up. Because this startup process uses the snapshot image 250a, it can start up much faster than when the first program 230 in the non-volatile storage unit 140 is loaded and each program is initialized and executed.

[0046] As described above, the startup process of the embedded system according to this embodiment 1 is a process that supports and extends so-called secure boot, and in order to meet the increasingly important security requirements of recent years, it performs integrity verification of the target program before executing the main program of the embedded system, thereby achieving high-speed startup. In particular, in this embodiment 1, a snapshot image 250 is transferred from the non-volatile storage unit 140 to the main memory unit 150 for tamper verification, and after tamper verification, the snapshot image 250a on the main memory unit 150 is then unpacked and restored, and program execution is resumed. Therefore, the number of times the snapshot image is transferred from the non-volatile storage unit 140 to the main memory unit 150 can be minimized. Thus, it is possible to achieve both high-speed startup and integrity assurance of the embedded system.

[0047] moreover, First startup processing unit 161 Since tampering verification is performed on the compressed snapshot image 250a, the amount of data to be verified is smaller compared to the decompressed data, thus shortening the tampering verification time. Furthermore, when tampering verification is performed on the compressed data before decompression, unexpected problems associated with the decompression process can be suppressed, allowing the process to be executed in a safe state.

[0048] Furthermore, through steps S114 to S116, the first startup processing unit 161 can accurately determine the actual address range of the main memory unit 150 in the snapshot image 250a that it did not transfer itself. Therefore, the first startup processing unit 161 can perform tampering verification on the appropriate target.

[0049] Next, another embodiment of this first embodiment will be described. The configuration of the embedded system 100 according to this embodiment is the same as that shown in Figure 1 above. This embodiment differs from the above embodiment in that the unpacking process of the snapshot image 250a is performed in parallel with at least a part of the transfer process of the snapshot image 250 from the non-volatile storage unit 140 to the main storage unit 150.

[0050] Figure 7 is a snapshot image of another embodiment of this first embodiment. boot This is a sequence diagram showing the processing flow. Figure 8 is a snapshot image of another embodiment of this embodiment 1. boot This diagram illustrates the concept of the process. The following explanation will refer to Figures 7 and 8 as appropriate. Similar components will be assigned the same or corresponding symbols, and redundant content will be omitted as appropriate.

[0051] The first startup processing unit 161 instructs the second startup processing unit 162 to transfer, restore, and verify for tampering of the snapshot image 250 (S114b). In this embodiment, the second startup processing unit 162 is described as performing tampering verification immediately after the transfer. This eliminates the need to specify a starting address.

[0052] In response to the instructions in step S114b, the second startup processing unit 162 transfers the snapshot image 250 from the non-volatile storage unit 140 to the main memory unit 150, and sequentially expands the snapshot image 250a in the main memory unit 150 to restore the first program 230a (S121). For example, the second startup processing unit 162 sequentially saves partial data of the snapshot image 250 transferred from the non-volatile storage unit 140 as snapshot image 250a in the main memory unit 150, and sequentially expands the saved partial data. Therefore, the second startup processing unit 162 transfers at least the snapshot image 250 Before the transfer is complete, the snapshot image stored in the main memory 150 at that time 250a The second startup processing unit 162 starts the unpacking process for the partial data of the snapshot image. In this way, at least part of the snapshot image transfer process and the unpacking process are performed in parallel. In other words, the second startup processing unit 162 starts the unpacking process for the snapshot image 250 The first program 230a is restored by starting the decompression of the compressed data on the main memory unit 150 between the time the transfer of the data from the non-volatile storage unit 140 to the main memory unit 150 is initiated and the transfer is completed.

[0053] Next, the second startup processing unit 162 performs tampering verification on the snapshot image 250a transferred to the main memory unit 150 (S122). In other words, the second startup processing unit 162 performs tampering verification on the compressed data after transfer. At this time, the second startup processing unit 162 may also be in parallel with the decompression of the snapshot image 250a, that is, the restoration of the first program 230a. Therefore, there may be a period of time when the tampering verification process for the transferred but undecompressed snapshot image 250a and the decompression process (restoration process) from the snapshot image 250a to the first program 230a are executed in parallel.

[0054] If the tampering verification in step S122 confirms that the system is functioning correctly, the second startup processing unit 162 executes the already restored first program 230a (S120). As a result, the embedded system 100 resumes program execution in the state it was in when the snapshot image 250 was taken. In other words, the embedded system 100 starts up.

[0055] Furthermore, if the tampering verification in step S122 does not confirm normal operation, or if an area error occurs during the expansion process in step S121, the second startup processing unit 162 will terminate without starting (not shown). The second startup processing unit 162 may also return processing to the first startup processing unit 161 and terminate the startup process.

[0056] As described above, the second startup processing unit 162 performs part of the snapshot image transfer and expansion processes in parallel in step S121, and expands the snapshot image 250a in advance on the memory of the main memory unit 150, but the execution is in steps S122 Since this is performed after tampering verification, the integrity of the program can be ensured. In this embodiment, by performing the transfer and decompression processes in parallel, memory resources including the cache of the processor 110 can be handled efficiently, thereby achieving faster startup with even shorter processing times.

[0057] <Embodiment 2> This second embodiment is a modification of the first embodiment described above. In the first embodiment described above, the target of tampering verification was a snapshot image of the first program 230 while it was running. Therefore, the second program 240, which was not yet executed, i.e., not loaded into the main memory 150 at the time the snapshot image was taken, was not included in the snapshot image and was not subject to tampering verification. Thus, it was necessary to perform tampering verification for the second program 240 separately. In contrast, in this second embodiment, by including the unexecuted second program 240 in the snapshot image, the first program 230 and the second program 240 are checked together during the tampering check at startup. This makes the tampering verification process more efficient. As a prerequisite, the size of the second program 240 is assumed to be smaller than the free space in the main memory 150 when the first program 230 is running.

[0058] Figure 9 is a block diagram showing the functional configuration of the embedded system 100a according to this second embodiment. Note that the physical configuration of the embedded system 100a according to this second embodiment is the same as that of Figure 1 described above, so any redundant content will be omitted as appropriate. The embedded system 100a differs from Figure 3 in that the snapshot unit 163 has been changed to a snapshot unit 163a. ​​Furthermore, the main memory unit 150 includes an execution area and an unexecuted area. Here, the execution area is the area where the processor 110 stores the first program that is currently being executed. The unexecuted area is the area where the processor 110 stores the second program that is not yet being executed.

[0059] An example of the procedure for generating and storing a snapshot image in this embodiment will be described. In this embodiment 2, the snapshot unit 163a transfers a pre-specified second program from the non-volatile storage unit 140 to the unexecuted area of ​​the main memory unit 150 when generating a snapshot image. In other words, the snapshot unit 163a transfers the second program from the non-volatile storage unit 140 to the unexecuted area of ​​the main memory unit 150 while the embedded system 100a is running. The snapshot unit 163a then generates a snapshot image based on the state of the execution area and the state of the unexecuted area of ​​the main memory unit 150 and stores it in the non-volatile storage unit 140. In other words, the snapshot image includes the first program that is currently running and the second program that is not yet running.

[0060] Figure 10 is a flowchart illustrating the snapshot image storage process according to this second embodiment. Figure 11 is a diagram illustrating the concept of the snapshot image storage process according to this second embodiment. The following description will refer to Figures 10 and 11 as appropriate.

[0061] For example, during the development of the embedded system 100a, the developers may investigate which programs are not being executed while the first program 230a is running, from among the programs installed on the embedded system 100a. For example, the developers may use a development terminal or the like to select a second program 240 that is not being executed while the first program 230a is running, because it has not been loaded into the execution area of ​​the main memory unit 150.

[0062] The snapshot unit 163a transfers the second program 240 from the non-volatile storage unit 140 to the unexecuted area of ​​the main memory unit 150 (S201). For example, Figure 11 As shown, a second program 240a, including the application program 241a, is transferred to the unexecuted area 152 of the main memory unit 150.

[0063] Subsequently, the snapshot unit 163a stores the snapshot image 250b, which includes the first program 230a and the second program 240a in the main memory unit 150, into the non-volatile storage unit 140 (S202). Here, the snapshot unit 163a compresses the area including the execution area 151 and the unexecuted area 152 of the main memory unit 150 to generate the snapshot image 250b. The snapshot image 250b thus generated is stored in the non-volatile storage unit 140 as the snapshot image 250b for normal operation. Note that the generation and storage of the snapshot image 250b may be arbitrarily performed in the same or similar procedure as described above, such as during writing at the factory or during major program updates. For example, developers may generate the snapshot image 250b using a development terminal or the like without using the embedded system 100a, and then write the generated snapshot image 250b to the non-volatile storage unit 140 in the embedded system 100a, i.e., store it. In other words, the computer, such as a development terminal, generates a snapshot image 250b from the state of the main memory where at least the first program 230a, which is currently running, and the second program 240a, which is not yet running, are stored. At this time, the main memory from which the snapshot image 250b is generated may be the memory built into the computer, such as a development terminal, or it may be the main memory 150 built into the embedded system 100a. The computer, such as a development terminal, may then store the generated snapshot image 250b in the non-volatile storage unit 140 of the embedded system 100a.

[0064] Next, we will describe the startup process during normal operation of the embedded system 100a storing the snapshot image 250b. The embedded system 100a performs a startup process as shown in Figures 4 and 5 above. In step S115, the snapshot image 250b transferred from the non-volatile storage unit 140 to the main memory unit 150 includes the second program 240a. Therefore, in step S117, the first startup processing unit 161 can perform tamper verification on the snapshot image 250b, which includes the first program 230a and the second program 240a. In other words, when the embedded system 100a starts up, the first startup processing unit 161 performs tamper verification on the first program 230a and the second program 240a included in the snapshot image 250b all at once. Therefore, there is no need to perform tamper verification on the second program 240a separately, and tamper verification can be made more efficient.

[0065] Then, if the tampering verification confirms that it is normal, in step S120, the second startup processing unit 162 executes the first program 230a stored in the execution area 151, which is not the unexecuted area 152, among the programs restored from the snapshot image 250b. In other words, the second startup processing unit 162 executes the first program 230a restored from the snapshot image 250b onto the main memory 150 only if the tampering verification of the snapshot image 250b confirms that it is normal. Therefore, at startup, the second program 240a is not executed, and the system can return to the state it was in when the snapshot image was taken.

[0066] <Other embodiments> The embedded systems described in each of the embodiments above are also applicable to general-purpose information processing devices.

[0067] Although the present invention has been described above in accordance with the above embodiments, the present invention is not limited to the configuration of the above embodiments, and of course includes various modifications, alterations, and combinations that can be made by a person skilled in the art within the scope of the claims of the present patent application.

[0068] Although the above embodiments were described in terms of hardware configuration, the invention is not limited thereto. This disclosure can also be implemented by having the CPU execute a computer program to perform any desired processing.

[0069] In the examples described above, the program includes a set of instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more of the functions described in the embodiments. The program may be stored in a non-temporary computer-readable medium or a physical storage medium. Examples, but not limited to, include RAM, ROM, flash memory, solid-state drive (SSD) or other memory technologies, CD-ROM, digital versatile disc (DVD), Blu-ray® disc or other optical disc storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices. The program may be transmitted over a temporary computer-readable medium or a communication medium. Examples, but not limited to, include, a temporary computer-readable medium or a communication medium that includes an electrical, optical, acoustic or other form of propagating signal. [Explanation of Symbols]

[0070] 100 Embedded Systems 110 processors 120 BootROM 130 1timeROM 131 Public Key 140 Non-volatile memory unit 150 Main memory 210 First startup program 220 Second startup program 230 First Program 231 OS 232 Application Programs 233 Application Programs 240 Second Program 241 Application Programs 250 snapshot images 160 Initial Processing Unit 161 First startup processing unit 162 Second startup processing unit 163 Snapshot section 170 Basic function section 171 applications addr1 address addr2 address size Data size 250a Snapshot Image 230a Program 1 231a OS 232a Application Program 233a Application Program 100a Embedded System 151 Execution Area 152 Unexecuted area 163a Snapshot section 240a Second Program 241a Application Program 250b Snapshot Image

Claims

1. Main memory section, A non-volatile storage unit storing a snapshot image based on the state of the main memory unit while at least the first program is running, a first startup program, and a second startup program. A processor provided in an embedded system having the following At startup, the first startup program performs a tamper-proof check on the snapshot image before restoration, which has been transferred from the non-volatile storage unit to the main memory unit by the second startup program. If the tampering verification by the first startup program confirms that the system is functioning correctly, the second startup program restores the snapshot image transferred to the main memory as the first program on the main memory, and then executes the restored first program. How to start an embedded system.

2. The aforementioned processor, The snapshot image is transferred from the non-volatile storage unit to the main memory unit in a compressed data format of a predetermined type. The tampering verification is performed on the compressed data after the transfer. If the tampering verification confirms that the system is functioning correctly, the compressed data is decompressed onto the main memory to restore the first program, and the system is then put into an execution state. A method for starting an embedded system according to claim 1.

3. Main memory section, A non-volatile storage unit storing a snapshot image based on the state of the main memory while at least a part of the first program is being executed, and the first startup program, In an embedded system having At startup, the process involves causing the first startup program to perform tampering verification on the snapshot image before restoration, which has been transferred from the non-volatile storage unit to the main memory unit. If the tampering verification by the first startup program confirms that the system is functioning correctly, the process involves restoring the snapshot image transferred to the main memory as the first program on the main memory, and then executing the restored first program. A startup program for embedded systems that initiates execution.

4. Main memory section, A non-volatile storage unit storing a snapshot image based on the state of the main memory while at least a part of the first program is being executed, a first startup program, and a second startup program. It has, At startup, the first startup program performs a tamper-proof check on the snapshot image before restoration, which has been transferred from the non-volatile storage unit to the main memory unit by the second startup program. If the tampering verification by the first startup program confirms that the system is functioning correctly, the second startup program restores the snapshot image transferred to the main memory as the first program on the main memory, and then executes the restored first program. Embedded systems.

Images