JP2011150656A - Program inspection system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To perform program inspection in parallel with program execution without causing access conflict to a storage. <P>SOLUTION: In a multi-core system for executing an execution domain (10) and an inspection domain (20) in parallel, access from the execution domain (10) to a storage (30) is prohibited, and an access request to the storage (30) is performed through the inspection domain (20). The inspection domain (20) receiving a program acquisition request from the execution domain (10) transfers a program read out from the storage (30) to the execution domain (10) and prepares a copy of the program. The inspection domain (20) inspects the copied program as a target. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a program inspection technique for verifying the validity of a program, and more particularly to a program inspection technique in a multi-core system sharing a storage device.

  Patent Document 1 proposes a method for inspecting a program at runtime. When using such a runtime program inspection on a multi-core processor system, a method of introducing an operation environment (inspection domain) that can be executed in parallel with the operation environment (execution domain) of an existing function can be considered. By executing program execution and program inspection in parallel in this way, it is expected that the inspection will not affect the program execution. However, in reality, program execution is caused by access contention with respect to the storage device (storage) that stores the program. It will adversely affect the throughput.

  In order to avoid a decrease in throughput due to contention for access to the storage, the present inventor has proposed a method of interrupting the inspection by the inspection domain by interrupting the inspection domain when the execution domain accesses the storage ( Patent Document 2).

JP 2004-171564 A JP 2009-282755 A

  However, in the method of Patent Document 2, there is a possibility that a program in the execution domain that has been tampered with periodically interrupts the inspection domain, thereby invalidating the program inspection and avoiding detection of tampering.

  The present invention solves the problem of throughput reduction due to access contention for storage by a method different from the method of Patent Document 2. In other words, an object of the present invention is to perform program inspection in parallel with program execution without causing access contention to a storage device in which the inspection target program is stored.

  In order to solve the above problems, a program inspection system according to the present invention includes a storage unit for storing a program, a program execution unit for executing the program, and an inspection unit for inspecting the program. This program inspection system operates on a multi-core system, and can perform a program inspection process and a program execution process in parallel.

  In this specification, a multi-core system means a computer system having a plurality of processor cores. Therefore, a system including a plurality of processor cores in one processor package, a system including a plurality of processors each having one processor core, and a combination thereof correspond to the multi-core system in this specification.

The program execution means in the present invention requests the inspection means to obtain the program without directly accessing the storage means when reading the program from the storage means.

  The inspection unit according to the present invention acquires a program from the storage unit in response to a program acquisition request from the program execution unit, transmits the program to the program execution unit, and creates a copy of the acquired program and targets the copied program Run the inspection.

  In this way, the program execution means does not access the storage means, and the program is acquired from the storage means via the program inspection means, so that the access to the storage device is unified, and access conflict between the two Is resolved.

  In the present invention, the inspection means stores a digest value of a normal program in advance, and the program is normal depending on whether or not the digest value calculated from the copied program matches the stored digest value. It can be determined whether or not there is.

  As such a digest value, for example, a hash value such as SHA-1 is preferably used. Also, a checksum such as MD5 or CRC may be used as the digest value. In other words, any digest value can be used as long as it is expected to take a different value if the program data is different.

  The present invention can also be understood as a program inspection method including at least a part of the above processing or a program for realizing these methods. Each of the above means and processes can be combined with each other as much as possible to constitute the present invention.

  According to the present invention, program inspection can be performed in parallel with program execution without causing access contention to the storage device storing the inspection target program.

The figure which shows the structure of the program inspection system which concerns on this embodiment. The figure which shows the structure at the time of implement | achieving the program test | inspection system which concerns on this embodiment using TrustZone (trademark). The figure which shows the structure at the time of implement | achieving the program inspection system which concerns on this embodiment using Xen. The flowchart which shows the flow of the whole process of the program inspection system which concerns on this embodiment. The flowchart which shows the flow of the inspection process in an inspection domain in the program inspection system which concerns on this embodiment. The figure explaining the correspondence of the program and block in a storage. The figure explaining the digest value of the normal block memorize | stored in a block normal state memory | storage part.

  Exemplary embodiments of the present invention will be described in detail below with reference to the drawings.

<Constitution>
FIG. 1 shows a configuration diagram of a program inspection system according to the present embodiment. The present embodiment is a multi-core system having a multi-core CPU and shares storage. Then, in addition to the execution domain in which the existing functions operate, a test domain that operates in parallel and monitors the execution domain is introduced. A domain represents a virtual area / environment in which a program is executed. Each domain is independent of each other and, as a general rule, cannot access other domains. However, by providing a mechanism for controlling access between domains, it is possible to provide a domain in which access to other domains is permitted. Here, since it is desired that the inspection domain 20 is not subjected to attacks such as tampering, the inspection domain 20 is constructed as a secure domain so as not to receive physical attacks or attacks from other domains.

  The present embodiment includes at least two domains: an execution domain that is an environment for executing a program, and an inspection domain that performs storage access and program inspection. The execution domain corresponds to the program execution means in the present invention, and the inspection domain corresponds to the program inspection means in the present invention.

  In this embodiment, direct access from the execution domain 10 to the storage 30 is prohibited. Therefore, when accessing the storage 30 from the execution domain 10, the device driver 12 transfers an access request to the storage 30 to the inspection domain 20 and accesses the storage via the inspection domain 20.

  Note that such a multi-core system composed of a plurality of domains can be realized by, for example, ARM's TrustZone (registered trademark) technology. FIG. 2 shows a configuration diagram when the configuration of FIG. 1 is realized using the TrustZone technology. In this case, a secure domain and a normal domain are constructed using hardware (such as a CPU) compatible with the TrustZone technology. The TrustZone technology has a function of controlling access to peripheral devices and can make access to storage other than the secure domain impossible. Therefore, the TrustZone technology is a suitable environment for this embodiment. In this case, communication between the normal domain (execution domain) and the secure domain (inspection domain) is performed through TrustZone monitor software that monitors communication between domains.

  Moreover, this embodiment can also be constructed using Xen, which is a virtualization technology. FIG. 3 shows a configuration diagram when the configuration of FIG. 1 is realized using Xen. In Xen, a Xen VMM (virtual machine monitor) that provides a virtual machine is executed on a multi-core system, and a plurality of OSs are executed thereon. The execution unit of the virtual machine is called a domain, and there is a domain 0 that is a privileged domain and another domain (domain U). Domain 0 manages access to real hardware and other domains. Access to the peripheral device from the domain U is made to the VMM which is a virtual machine, and the request is redirected to the domain 0. Then, the domain 0 accesses the actual peripheral device and returns the access result to the domain U. Since Xen provides such an access method for peripheral devices, it can be used to construct this embodiment.

<Overall processing>
The role of each functional unit in FIG. 1 will be described along with the flow of processing. FIG. 4 is a flowchart showing the flow of overall processing in the multi-core system. Since the inspection domain 20 inspects the program in response to the program load request from the execution domain 10, it waits for the program load request from the execution domain (step S10). When the kernel 11 executes the program in the execution domain 10, the device driver 12 is requested to acquire the program in the storage 30 (step S11). In response to the program load request from the kernel 11, the device driver 12 requests the test domain 20 to load the program (step S12). Since the program is stored across the block as shown in FIG. 6A in the storage 30, the program-block conversion unit 12a storing the correspondence between the program and the block as shown in FIG. The block corresponding to the programmed program is determined. Then, the block load transfer unit 12b requests the inspection domain 20 via the execution domain communication unit 21 to load this block.

  Since the process in the inspection domain 20 will be described in detail later, it will be briefly described here. When the inspection domain 20 receives a request for a program (block load request) (step S13), the storage driver 22 requests the storage 30 to load the block, and generates a copy of the acquired block. (Step S14). In the execution domain 10, when the requested program is received, the kernel 11 executes this program (S15). On the other hand, in the inspection domain 20, the copied program is inspected (step S16). If there is an abnormality in the program, the execution domain 10 is notified and the execution of the program in the execution domain 10 is stopped.

<Inspection process in inspection domain>
Hereinafter, detailed processing in the inspection domain 20 will be described with reference to the flowchart of FIG. When the execution domain communication unit 21 receives a block load request from the device driver 12 of the execution domain 10 (step S20), the storage driver 22 loads the designated block from the storage 30 (step S21). The storage driver 22 passes the loaded block to the block copy generation unit 23 (step S22), and the block copy generation unit 23 generates a copy of the loaded block on the RAM in the inspection domain 20 and stores it internally (step S22). S23). The execution domain communication unit 21 passes the loaded copy source block to the device driver 12 of the execution domain 10 (step S24). As described above, this starts program execution in the execution domain 10. In the inspection domain 20, the block inspection unit 24 performs inspection on the copied block (step S25). Specifically, the block inspection unit 24 calculates the digest value of the copied block. Since the digest value when each block is normal is stored in the block normal state storage unit 25 as shown in FIG. 7, the block inspection unit 24 stores the calculated digest value in the block normal state storage unit 25. It is determined whether or not the block in the storage 30 is normal by comparing the digest values. If the loaded block is normal (S26-YES), the inspection process is terminated and the next block load request is awaited. On the other hand, when the digest value of the loaded block is abnormal, unlike the stored value (S26-NO), the block inspection unit 24 notifies the inspection domain message reception unit 13 to that effect. When the execution domain 10 receives this notification, the execution of the program is stopped.

<Operation and effect of this embodiment>
In this embodiment, since the execution domain executes the program and the program is copied in the inspection domain, it is not necessary to access the storage again for the inspection from the inspection domain. That is, since access to the storage is performed only once, there is no access contention between the execution domain and the inspection domain, and the influence on the execution domain due to the inspection can be minimized. In this embodiment, an overhead is generated in which a copy of the program loaded in the inspection domain is generated on the RAM. However, since the operation time for the RAM is generally shorter than the operation time for the storage, the overhead due to copying is small.

  Further, by using a virtualization technology such as TrustZone or Xen, an access request from the execution domain to the storage can be redirected to the inspection domain by controlling the lower layer without changing the kernel or device driver of the execution domain. That is, the program can be inspected by adding only the inspection domain without changing the program on the execution environment side.

DESCRIPTION OF SYMBOLS 10 Execution domain 11 Kernel 12 Device driver 13 Inspection domain message receiving unit 20 Inspection domain 21 Execution domain communication unit 22 Storage driver 23 Block copy generation unit 24 Block inspection unit 25 Block normal state storage unit 30 Storage

Claims (4)

Storage means for storing the program;
Program execution means for executing the program;
Inspection means for inspecting the program;
A program inspection system that executes the inspection and execution of the program in parallel by a multi-core system,
The program execution means, when reading the program from the storage means, requests acquisition of the program from the inspection means without directly accessing the storage means,
The inspection unit acquires a program from the storage unit in response to a program acquisition request from the program execution unit, transmits the program to the program execution unit, and creates a copy of the program and targets the copied program A program inspection system characterized in that the inspection is executed. The inspection means stores a digest value of a normal program in advance, and whether or not the program is normal depends on whether or not the digest value calculated from the copied program matches the stored digest value. The program inspection system according to claim 1, wherein: Storage means for storing the program;
Program execution means for executing the program;
Inspection means for inspecting the program;
A program inspection method in a program inspection system that executes the inspection and execution of the program in parallel by a multi-core system,
The program execution means, a program acquisition request step for requesting the inspection means to acquire a program;
The inspection unit acquiring a program from the storage unit in response to a program acquisition request from the program execution unit, a step of transmitting the acquired program to the program execution unit, and a copy of the acquired program And an inspection process for performing an inspection on a copied program
A program inspection method including: In the inspection means, a digest value of a normal program is stored in advance,
4. In the step of checking, it is determined whether or not the program is normal depending on whether or not a digest value calculated from the copied program matches a stored digest value. The program inspection method described in 1.

Images