Embedded system startup method, startup program, and embedded system

Abstract

To provide a method for starting a built-in system, a starting program, and a built-in system, which can improve the efficiency of alteration verification processing while ensuring the integrity of a program in the built-in system.SOLUTION: A built-in system includes: a main storage section 150; and a nonvolatile storage section 140 that stores a snapshot image 250b generated from a state of the main storage section 150 that stores a first program 230a being executed and an unexecuted second program 240a. A starting method includes: performing alteration verification to the first program 230a and the second program 240a included in the snapshot image 250b when starting; and executing the first program 230a restored on the main storage section 150 from the snapshot image 250b when confirmed to be normal in the alteration verification.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] The present disclosure relates to a boot method and a boot program for an embedded system, and an embedded system. [Background technology]

[0002] Electronic devices incorporating electronic boards equipped with processors, memory, flash memory, etc. are also called embedded systems. In embedded systems, in order to quickly start programs such as an operating system (OS), a random access memory (RAM) image containing the program's execution state is stored in flash memory or the like while the program is running, and the RAM image is loaded from the flash memory or the like into RAM the next time the system is started. Patent Document 1 discloses a technique in which a portion of the RAM image is pre-loaded into RAM at startup, and pages in which a page fault occurs during program execution are sequentially loaded into RAM. The RAM image is also called a snapshot image. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2011-145933 Summary of the Invention [Problem to be solved by the invention]

[0004] Generally, a snapshot image is a data stored in a non-volatile memory unit that represents the state of a main memory unit during program execution. Therefore, programs that are not yet executed when the snapshot image is generated are not included in the snapshot image and are not subject to tampering verification when the embedded system is started. Therefore, when an unexecuted program is executed, a separate program tampering verification is required, which takes time and makes tampering verification inefficient. Note that the technology disclosed in the above-mentioned Patent Document 1 does not handle tampering checks of snapshot images.

[0005] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide an embedded system startup method and startup program, as well as an embedded system, that improve the efficiency of tamper verification processing while ensuring the integrity of programs within the embedded system. [Means for solving the problem]

[0006] A first aspect of the present disclosure provides a method for booting an embedded system, in which a processor provided in the embedded system has a main memory unit and a non-volatile memory unit storing a snapshot image generated from the state of the main memory unit in which a first program currently being executed and a second program not yet executed are stored, performs tamper verification on the first program and the second program contained in the snapshot image at boot time, and if the tamper verification confirms normality, executes the first program restored from the snapshot image on the main memory unit.

[0007] A second aspect of the present disclosure provides a startup program for an embedded system that includes a main memory unit and a non-volatile memory unit storing a snapshot image generated from the state of the main memory unit in which a first program currently being executed and a second program not yet executed are stored, the startup program causing the system to execute, at startup, a process of verifying whether the first program and the second program included in the snapshot image have been tampered with, and, if the tampering verification confirms normality, a process of executing the first program restored from the snapshot image onto the main memory unit.

[0008] A third aspect of the present disclosure provides an embedded system having a main memory unit and a non-volatile memory unit storing a snapshot image generated from the state of the main memory unit in which a first program currently being executed and a second program not yet executed are stored, and at startup, performs tamper verification on the first program and the second program included in the snapshot image, and if the tamper verification confirms normality, executes the first program restored from the snapshot image on the main memory unit. [Effects of the Invention]

[0009] The present disclosure makes it possible to provide a startup method and startup program for an embedded system, and an embedded system, that ensure the integrity of programs in the embedded system while improving the efficiency of tamper verification processing. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a block diagram showing a configuration of an embedded system according to a first embodiment of the present invention. [Figure 2] FIG. 4 is a diagram showing an example of data stored in a nonvolatile storage unit according to the first embodiment. [Figure 3] 1 is a block diagram showing a functional configuration of an embedded system according to a first embodiment of the present invention. [Figure 4]10 is a flowchart showing the flow of a startup process of the embedded system according to the first embodiment. [Figure 5] FIG. 10 is a sequence diagram showing the flow of a snapshot image startup process according to the first embodiment. [Figure 6] FIG. 2 is a diagram for explaining the concept of snapshot image startup processing according to the first embodiment. [Figure 7] FIG. 10 is a sequence diagram showing the flow of a snapshot image startup process according to another example of the first embodiment. [Figure 8] FIG. 10 is a diagram for explaining the concept of a snapshot image startup process according to another example of the first embodiment. [Figure 9] FIG. 10 is a block diagram showing the functional configuration of an embedded system according to a second embodiment. [Figure 10] 10 is a flowchart showing the flow of a snapshot image storage process according to the second embodiment. [Figure 11] FIG. 10 is a diagram for explaining the concept of snapshot image storage processing according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, specific embodiments of the present 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 for clarity of explanation, duplicated explanations will be omitted as necessary.

[0012] <Embodiment 1> FIG. 1 is a block diagram showing the configuration of an embedded system 100 according to the first embodiment. 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 or the like that is mounted on, for example, a home appliance, industrial equipment, a mobile object, etc. Examples of the electronic device include, but are not limited to, a car navigation device, a television receiver, a hard disk recorder, etc. The embedded system 100 includes at least a processor 110, a Boot ROM (Read Only Memory) 120, a 1-time ROM 130, a non-volatile storage unit 140, and a main storage unit 150.

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

[0014] BootROM 120 is a storage device that stores an initial processing program, such as a system BIOS (Basic Input / Output System), that is read by processor 110 when embedded system 100 is powered on. The initial processing program is a computer program that verifies a first boot program (described below) and, if the verification confirms that the program is normal, loads and starts the first boot program. BootROM 120 may be configured by dividing it into areas on nonvolatile storage unit 140 (described below).

[0015] The one-time ROM 130 is, for example, a one-time writable ROM, but is not limited to this. The one-time ROM 130 stores encryption key information such as a public key 131 and device-specific ID information. The public key 131 is a public key used by the above-mentioned initial processing program during verification. The BootROM 120 and the one-time ROM 130 are preferably configured as secure areas, and may be configured on-chip together with the processor 110.

[0016] The nonvolatile storage unit 140 is a nonvolatile storage device that stores various programs and data executed by the embedded system 100. The nonvolatile storage unit 140 may be a semiconductor memory such as a flash memory, or a hard disk. Examples of flash memory that can be used for the nonvolatile storage unit 140 include, but are not limited to, an eMMC (embedded Multi Media Card) and a flash ROM. The nonvolatile storage unit 140 is also called an external storage device or an auxiliary storage device.

[0017] 2 is a diagram showing an example of data stored in the nonvolatile storage unit 140 according to the first embodiment. The nonvolatile storage unit 140 stores a first boot program 210, a second boot 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 launches the second boot program if the verification confirms that the second boot program 220 is normal. The first boot program 210 is a program that implements so-called boot loader processing. The first boot program 210 may be encrypted and signed using a private key (not shown). Here, the private key is a key that is 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 is implemented with processing that verifies whether the second boot program 220 and the snapshot image 250 have been tampered with. The first boot program 210 is also implemented with processing that instructs the second boot program 220 to transfer the snapshot image 250 to the main memory unit 150. The first startup program 210 also includes a process for issuing an instruction to restore the snapshot image 250 when the tampering verification confirms that the image is normal and has not been tampered with.

[0019] The second boot program 220 is a computer program that implements more complex processing than the first boot program 210 described above. Specifically, the second boot program 220 implements processing for transferring the snapshot image 250 from the nonvolatile storage unit 140 to the main memory unit 150 in response to a transfer instruction from the first boot program 210. In particular, the second boot program 220 transfers the snapshot image 250 from the nonvolatile storage unit 140 to the main memory unit 150 in the form of compressed data in a predetermined format. That is, the second boot program 220 copies the snapshot image 250 from the nonvolatile storage unit 140 to the main memory unit 150. Any of various well-known formats may be used as a data compression method, and this is not a limitation. The second boot program 220 also implements processing for restoring the snapshot image 250 in response to a restoration instruction from the first boot program 210. More specifically, the second boot program 220 restores the first program by expanding the compressed data in the main memory 150. Here, the process of restoring the snapshot image 250 refers to, for example, restoring the settings of the hardware registers and memory of the processor 110 to the same state as when the snapshot image 250 was created, i.e., to a state where the snapshot image 250 can be executed again. The process of restoring the snapshot image 250 may also involve timely expanding the processes required for operation. In this way, by creating the snapshot image 250 in a format that allows the expansion and restoration of the compressed data to be performed together, the process from startup to restoration of the snapshot can be completed efficiently. The second boot program 220 then transitions to a state where the restored first program can be 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, etc. The OS 231 is basic software and includes a kernel. The application programs 232 and 233, etc. are application software that realize functions provided to the user in the electronic device.

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

[0022] The snapshot image 250 is data output from the main memory unit 150, representing the state of the main memory unit 150 while the first program 230 is running. The snapshot image 250 includes the state in which the OS 231, application programs 232 and 233, etc. are loaded into the main memory unit 150. The snapshot image 250 also includes register contents, a program counter, a stack pointer, and the like, during 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. For example, if the embedded system 100 does not require updating the snapshot image 250 and always boots with the same snapshot image 250, the configuration of the first program and the second program indicated by the dashed lines in FIG. 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 storing information when the processor 110 is operating. The main memory unit 150 is also called a volatile memory unit, a primary memory unit, or simply "memory." The main memory unit 150 is, for example, a high-speed volatile storage device such as a RAM. Specifically, the main memory unit 150 may be a dynamic RAM (DRAM), a static RAM (SRAM), or the like. For example, the main memory unit 150 stores the above-mentioned initial processing program, the first boot program 210, the second boot program 220, the first program 230, the second program 240, and the snapshot image 250.

[0024] The embedded system 100 also includes a general microcomputer configuration, not shown.

[0025] Fig. 3 is a block diagram showing the functional configuration of the embedded system 100 according to the first embodiment. Fig. 3 shows functional blocks when the processor 110 of the embedded system 100 loads various programs into the main storage unit 150 and executes the various programs. Specifically, the processor 110 functions as an initial processing unit 160 by loading an initial processing program from the Boot ROM 120 into the main storage unit 150 and executing the program. The initial processing unit 160 is a functional block that realizes the initial processing implemented in the above-mentioned initial processing program when the embedded system 100 is started up.

[0026] The processor 110 also functions as a first boot processing unit 161 by loading a first boot program 210 from the nonvolatile storage unit 140 into the main storage unit 150 and executing the program. The first boot processing unit 161 is a functional block implemented in the first boot program 210 and that realizes the first boot processing of the embedded system 100.

[0027] The processor 110 also functions as a second boot processing unit 162 by loading the second boot program 220 from the nonvolatile storage unit 140 into the main storage unit 150 and executing it. The second boot processing unit 162 is a functional block implemented in the second boot program 220 that realizes the second boot processing of the embedded system 100.

[0028] The processor 110 also functions as a functional block that realizes the main processing of the embedded system 100, such as a snapshot unit 163, a basic function unit 170, and an application 171, by loading a first program 230 from the nonvolatile storage unit 140 into the main memory unit 150 and executing the program. The snapshot unit 163 generates a snapshot image 250 from the state of the main memory unit 150 during program execution at a predetermined timing, for example, periodically or at a timing specified externally, and stores the snapshot image 250 in the nonvolatile storage unit 140. The basic function unit 170 is a functional block that realizes processing implemented in the OS 231. The snapshot unit 163 may also be realized by processing implemented in the OS 231. The application 171 is a functional block that realizes processing implemented in application programs 232, 233, etc. The processor 110 may realize processing of a predetermined application by loading a second program 240 from the nonvolatile storage unit 140 into the main memory unit 150 and executing the program.

[0029] 4 is a flowchart showing the flow of the startup process of the embedded system according to the present embodiment 1. It is assumed that the embedded system 100 has already stored in the non-volatile storage unit 140 the states of the main storage unit 150 of various programs that were running at the time of the previous startup as snapshot images 250.

[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 a startup process. The processor 110 of the embedded system 100 reads the above-mentioned initial processing program 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 boot program 210 (S103). Specifically, the initial processing unit 160 loads the first boot program 210 from the nonvolatile storage unit 140 to the main memory unit 150. Then, the initial processing unit 160 verifies the asymmetric key encryption and signature of the first boot program 210 on the main memory unit 150 using the public key 131 in the 1-time ROM 130. The verification process by the initial processing unit 160 can use known technology, or may be other verification processes.

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

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

[0034] Next, the first boot processing unit 161 verifies the second boot program 220 (S106). Specifically, the first boot processing unit 161 loads the second boot program 220 from the nonvolatile storage unit 140 into the main memory unit 150. Then, the first boot processing unit 161 calculates a hash value from the second boot program 220 on the main memory unit 150, and performs verification by comparing the calculated hash value with a hash value (not shown) for verification that is stored in advance.

[0035] Then, the first boot processing unit 161 determines whether the second boot program 220 has been successfully verified (S107). For example, if the matched hash values ​​are different, it is determined that the verification has failed. If the verification has failed (NO in S107), the embedded system 100 terminates without booting. At this time, the embedded system 100 may be rebooted by a watchdog. Alternatively, the embedded system 100 may output a message indicating that the verification has failed.

[0036] On the other hand, if the compared hash values ​​match, the verification is successful (YES in S107), and the first boot processing unit 161 performs snapshot image boot processing (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] Fig. 5 is a sequence diagram showing the flow of snapshot image startup processing according to embodiment 1. Fig. 6 is a diagram for explaining the concept of snapshot image startup processing according to embodiment 1. In the following explanation, Fig. 5 and Fig. 6 will be referred to as appropriate.

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

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

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

[0041] After step S115, the second startup processing unit 162 obtains the data size size from the address addr2 corresponding 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 to this, the first startup processing unit 161 performs tampering verification on the snapshot image 250a that is the transfer destination and before expansion (S117). That is, 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 end 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 address 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 hash value (not shown) for verification stored in advance. That is, the first startup processing unit 161 determines whether or not the verification is successful. If the compared hash values ​​match, it determines that the tampering verification is successful, that is, that the tampering verification has confirmed normality. Note that if the tampering verification fails, the embedded system 100 terminates without starting up (not shown). At this time, the embedded system 100 may output a message indicating that the verification has failed.

[0044] If the tampering verification confirms normality, the first boot processing unit 161 instructs the second boot processing unit 162 to restore the snapshot image 250a (S118). In response, the second boot 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 FIG. 6, the first program 230a including the OS 231a, application programs 232a and 233a, etc., is ultimately transferred to the main memory unit 150. The second boot processing unit 162 also sets the OS 231a, application programs 232a and 233a, etc., register contents at runtime, program counter, stack pointer, etc., included in the snapshot image 250a. Note that the second boot processing unit 162 may release the snapshot image 250a from the main memory unit 150 after restoration.

[0045] Thereafter, 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 acquired. In other words, the embedded system 100 starts up. This startup process uses the snapshot image 250a, so startup can be performed more quickly than when the first program 230 in the nonvolatile 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 the first embodiment is a process that supports and extends the so-called secure boot. To meet the security requirements that have become increasingly important in recent years, the system verifies the integrity of the target program before executing the main program of the embedded system, thereby achieving fast startup. In particular, in the first embodiment, the snapshot image 250 is transferred from the nonvolatile storage unit 140 to the main memory unit 150 to verify tampering. After the tampering verification, the snapshot image 250a on the main memory unit 150 is subsequently extracted and restored, and program execution is resumed. This minimizes the number of times the snapshot image is transferred from the nonvolatile storage unit 140 to the main memory unit 150. This allows for both fast startup and ensuring the integrity of the embedded system.

[0047] Furthermore, because the second startup processing unit 162 performs tamper verification on the compressed snapshot image 250a, the data to be verified is smaller than the data after decompression, and the time required for tamper verification can be shortened. Also, when tamper verification is performed on compressed data before decompression, unexpected problems associated with the decompression process can be prevented, and processing can be executed in a safe state.

[0048] Note that steps S114 to S116 allow first startup processing unit 161 to accurately grasp the actual address range of main memory unit 150 in snapshot image 250a that it has not transferred itself, and therefore first startup processing unit 161 can perform tampering verification on appropriate targets.

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

[0050] Fig. 7 is a sequence diagram showing the flow of snapshot image storage processing according to another example of the present embodiment 1. Fig. 8 is a diagram for explaining the concept of snapshot image storage processing according to another example of the present embodiment 1. In the following explanation, Fig. 7 and Fig. 8 will be referred to as appropriate. Note that similar components are given the same or corresponding reference numerals, and duplicate content will be omitted as appropriate.

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

[0052] In response to the instruction in step S114b, the second startup processing unit 162 transfers the snapshot image 250 from the nonvolatile storage unit 140 to the main storage unit 150, while sequentially expanding the snapshot image 250a in the main storage unit 150 within the main storage unit 150 to restore the first program 230a (S121). For example, the second startup processing unit 162 sequentially stores the partial data of the snapshot image 250 transferred from the nonvolatile storage unit 140 as snapshot image 250a within the main storage unit 150, while sequentially expanding the partial data that has already been saved. Therefore, the second startup processing unit 162 starts expanding the partial data of the snapshot image that has already been saved within the main storage unit 150 at least before the transfer of the snapshot image is completed. In this way, at least a part of the snapshot image transfer process and the expansion process are performed in parallel. In other words, the second startup processing unit 162 starts to expand the compressed data on the main memory unit 150 from the time when the snapshot image 150 starts to be transferred from the non-volatile memory unit 140 to the main memory unit 150 in the form of compressed data in a predetermined format until the transfer is completed, thereby restoring the first program 230a.

[0053] Next, the second startup processing unit 162 performs tampering verification on the snapshot image 250a transferred to the main memory unit 150 (S122). That is, the second startup processing unit 162 performs tampering verification on the transferred compressed data. At this time, the second startup processing unit 162 may be concurrently expanding the snapshot image 250a, that is, restoring the first program 230a. Therefore, there may be a time period during which the tampering verification process on the transferred but unexpanded snapshot image 250a and the expansion 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 normality, the second startup processing unit 162 executes the already restored first program 230a (S120). This causes the embedded system 100 to resume program execution in the state it was in when the snapshot image 250 was acquired. In other words, the embedded system 100 starts up.

[0055] If the tampering verification in step S122 does not confirm normality, or if an area error occurs in the extraction process in step S121, the second startup processing unit 162 ends the process without starting up (not shown). The second startup processing unit 162 may return the process to the first startup processing unit 161 and end the startup process.

[0056] As described above, second startup processing unit 162 performs part of the snapshot image transfer process and expansion process in parallel in step S121, and expands the image in advance to snapshot image 250a in memory in main storage unit 150, but the program integrity can be ensured because execution is performed after tampering verification in step S121. In this embodiment, performing the transfer and expansion processes in parallel makes it possible to efficiently handle memory resources, including the cache of processor 110, thereby achieving high-speed startup with even shorter processing times.

[0057] <Embodiment 2> The second embodiment is a modification of the first embodiment described above. In the first embodiment described above, the target of tamper verification was a snapshot image of the first program 230 that was currently being executed. Therefore, the second program 240 that was not yet executed, i.e., not loaded into the main memory unit 150, when the snapshot image was acquired was not included in the snapshot image and was not the target of tamper verification. Therefore, tamper verification had to be performed separately for the second program 240. In contrast, in the second embodiment, the unexecuted second program 240 is included in the snapshot image, so that tamper checks are performed on the first program 230 and the second program 240 together during startup. This improves the efficiency of the tamper verification process. Note that it is assumed that the size of the second program 240 is smaller than the free space in the main memory unit 150 when the first program 230 is executed.

[0058] FIG. 9 is a block diagram showing the functional configuration of an embedded system 100a according to the second embodiment. The physical configuration of the embedded system 100a according to the second embodiment is the same as that shown in FIG. 1, and therefore overlapping details will be omitted where appropriate. The embedded system 100a is different from that shown in FIG. 3 in that the snapshot unit 163 is replaced with a snapshot unit 163a. ​​The main memory unit 150 includes an execution area and an unexecuted area. The execution area is an area in which the processor 110 stores a first program that is currently being executed. The unexecuted area is an area in which the processor 110 stores a second program that has not yet been executed.

[0059] An example of the procedure for generating and storing a snapshot image in this embodiment will be described. When generating a snapshot image, the snapshot unit 163a according to this embodiment transfers a pre-specified second program from the non-volatile storage unit 140 to an unexecuted area in the main storage unit 150. That is, the snapshot unit 163a transfers the second program from the non-volatile storage unit 140 to an unexecuted area in the main storage unit 150 while the embedded system 100a is running. Then, the snapshot unit 163a generates a snapshot image based on the states of the execution area and the unexecuted area in the main storage unit 150, and stores the image in the non-volatile storage unit 140. That is, the snapshot image includes the first program being executed and the second program not being executed.

[0060] Fig. 10 is a flowchart showing the flow of snapshot image storage processing according to embodiment 2. Fig. 11 is a diagram for explaining the concept of snapshot image storage processing according to embodiment 2. In the following explanation, Fig. 10 and Fig. 11 will be referred to as appropriate.

[0061] For example, during development of the embedded system 100, a developer or the like may investigate programs installed in the embedded system 100a that have not been executed while the first program 230a is being executed. For example, the developer or the like may use a development terminal or the like to select the second program 240 that has not been loaded into the execution area of ​​the main memory unit 150 as an unexecuted program while the first program 230a is being executed.

[0062] The snapshot unit 163a transfers the second program 240 from the nonvolatile storage unit 140 to the unexecuted area of ​​the main storage unit 150 (S201). For example, as shown in FIG. 10, the second program 240a including the application program 241a is transferred to the unexecuted area 152 of the main storage unit 150.

[0063] The snapshot unit 163a then stores the snapshot image 250b, which includes the first program 230a and the second program 240a in the main memory unit 150, in the non-volatile memory unit 140 (S202). Here, the snapshot unit 163a compresses the area of ​​the main memory unit 150, including the execution area 151 and the unexecuted area 152, to generate the snapshot image 250b. The snapshot image 250b generated in this manner is stored in the non-volatile memory unit 140 as the snapshot image 250b during normal operation. The generation and storage of the snapshot image 250b may be performed in a manner similar to or equivalent to the above-described procedure, such as during programming at a factory or during a major program update. For example, a developer may generate the snapshot image 250b using a development terminal or the like, without using the embedded system 100a, and then write, i.e., store, the generated snapshot image 250b in the non-volatile memory unit 140 of the embedded system 100a. That is, a computer such as a development terminal generates a snapshot image 250b from the state of a main memory unit that stores at least the first program 230a that is currently being executed and the second program 240a that is not yet executed. In this case, the main memory unit for generating the snapshot image 250b may be a memory or the like built into a computer such as a development terminal, or the main memory unit 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 memory unit 140 of the embedded system 100a.

[0064] Next, the startup process during normal operation of the embedded system 100a storing the snapshot image 250b will be described. The embedded system 100a performs the startup process as shown in FIGS. 4 and 5. Then, in step S115, the snapshot image 250b transferred from the nonvolatile storage unit 140 to the main storage unit 150 includes the second program 240a. Therefore, in step S117, the first startup processing unit 161 can perform tampering verification on the snapshot image 250b including 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 simultaneously performs tampering verification on the first program 230a and the second program 240a included in the snapshot image 250b. Therefore, there is no need to separately perform tampering verification on the second program 240a, thereby improving the efficiency of tampering verification.

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

[0066] <Other embodiments> The embedded systems according to the above-described embodiments can also be applied to general-purpose information processing devices.

[0067] The present invention has been described above in accordance with the above-mentioned embodiment, but the present invention is not limited to the configuration of the above-mentioned embodiment, and naturally includes various modifications, alterations, and combinations that a person skilled in the art can make within the scope of the invention as defined in the claims of this application.

[0068] Although the above-described embodiment has been described as a hardware configuration, the present disclosure is not limited to this. Any processing in the present disclosure can also be realized by causing a CPU to execute a computer program.

[0069] In the above examples, the program includes instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The program may be stored on a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable medium or tangible storage medium includes RAM, ROM, flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disc (DVD), Blu-ray® disc or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The program may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable medium or communication medium includes electrical, optical, acoustic, or other forms of propagated signals. [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 Program 240 Second Program 241 Application Programs 250 snapshot images 160 Initial processing section 161 First startup processing unit 162 Second startup processing section 163 Snapshot Section 170 Basic function section 171 Applications addr1 address addr2 address size Data size 250a snapshot image 230a First Program 231a OS 232a Application Program 233a Application Program 100a Embedded Systems 151 Execution Area 152 Unimplemented Area 163a Snapshot section 240a Second Program 241a Application Program 250b snapshot image

Claims

1. a main memory unit; a non-volatile storage unit storing a snapshot image generated from the state of the main storage unit in which a first program being executed and a second program not being executed are stored; A processor provided in an embedded system having At the time of startup, performing tampering verification on the first program and the second program included in the snapshot image; If the tampering verification confirms normality, the first program restored on the main storage unit from the snapshot image is executed. How to boot an embedded system.

2. An embedded system including a main memory unit and a non-volatile memory unit storing a snapshot image generated from a state of the main memory unit in which a first program currently being executed and a second program not yet executed are stored, a process of verifying tampering of the first program and the second program included in the snapshot image at the time of startup; a process of executing the first program restored on the main storage unit from the snapshot image when the tampering verification confirms normality; A startup program for embedded systems that runs

3. a main memory unit; a non-volatile storage unit storing a snapshot image generated from the state of the main storage unit in which a first program being executed and a second program not being executed are stored; and At the time of startup, performing tampering verification on the first program and the second program included in the snapshot image; executing the first program restored on the main storage unit from the snapshot image when the tampering verification confirms normality; Embedded systems.

Images