Source: https://patents.google.com/patent/JP5377748B2/en
Timestamp: 2020-01-26 15:51:00
Document Index: 647269416

Matched Legal Cases: ['art1', 'art2', 'art1', 'art1', 'art1', 'art1', 'art1']

JP5377748B2 - program - Google Patents
JP5377748B2
JP5377748B2 JP2012500425A JP2012500425A JP5377748B2 JP 5377748 B2 JP5377748 B2 JP 5377748B2 JP 2012500425 A JP2012500425 A JP 2012500425A JP 2012500425 A JP2012500425 A JP 2012500425A JP 5377748 B2 JP5377748 B2 JP 5377748B2
JP2012500425A
JPWO2011101972A1 (en
良太郎 林
友秀 城勘
2010-02-18 Application filed by 株式会社東芝 filed Critical 株式会社東芝
2010-02-18 Priority to PCT/JP2010/052465 priority Critical patent/WO2011101972A1/en
2013-06-17 Publication of JPWO2011101972A1 publication Critical patent/JPWO2011101972A1/en
2013-12-25 Publication of JP5377748B2 publication Critical patent/JP5377748B2/en
According to an embodiment, a computer program product includes a computer-readable medium including program, when executed by a computer, to have a plurality of modules run by the computer. The computer includes a memory having a shared area, which is an area accessible to only those modules which run cooperatively and storing therein execution module identifiers. Each of the modules includes a first operation configured to store, just prior to a switchover of operations to an other module that runs cooperatively, an identifier of the other module as the execution module identifier in the shared area; and a second operation configured to execute, when the execution module identifier stored in the shared area matches with an identifier of own module immediately after a switchover of operations from the other module, a function inside the own module.
The present invention relates to a technique for preventing a change in execution order when a plurality of modules perform a cooperative operation.
In the open system, computer hardware and operating system (OS) source code are disclosed, so that the user can modify the operating program to obtain a desired program. Therefore, in an open system, it is assumed that an OS program is altered to attack an application program. It is difficult to prevent such attacks by a third party only by performing processing for preventing an attack on the application program on the OS.
On the other hand, hardware is difficult to be modified by the user. There has already been proposed a secure processor configured to prevent an attack on a program due to modification of the OS (Patent Document 1, Non-Patent Document 1). Such a secure processor encrypts a program and information used in the program in a multitasking environment, thereby preventing leakage of the program and information to a third party and modification of the program, and is generated from the program. Can be executed in the correct order.
In addition, there are many applications configured such that a plurality of modules operate in cooperation. In a secure processor, each module may only trust a part of another module. For example, each module is encrypted and protected with a separate key, operates in a separate context, and each context is isolated from the OS and other modules. Data exchanged between modules is not passed to potentially hostile OSs or non-linked modules. In this model, the context is isolated from other modules to protect private data in the module, while a shared area is used for data exchange for the cooperative operation between the modules.
One of application forms with such a module configuration is a method using a shared library. In the case of realizing by multi-process, each process operates independently of each other, so a description for synchronizing the operation between the processes is required. On the other hand, shared libraries need only be described according to the normal calling convention, as in the case of creating a single application. In addition, since the operation becomes sequential, there is an advantage that it can be easily described.
When using a shared library in a secure processor, it is necessary to verify whether the module to be linked is appropriate. In Patent Document 2, a program that calls a shared library performs authentication key exchange at the time of initialization of the shared library to verify the validity of the shared library. When a shared library is called, a specific entry point in the shared library is always executed. Further, in Patent Document 3, whether or not a module that is a call source and a module that is a call destination are valid is verified using a key for decrypting the module.
Japanese Patent No. 4226816 Japanese Patent No. 4115759 JP 2005-196257 A
Lee et al., "Architecture Support for Copy and Tamper Resistant Software", Computer Architecture News, 28 (5), p. 168
By the way, each module has a context separately, and the execution control is managed by the OS. Therefore, the operation of the module can be started by the execution control of the OS. At this time, even if the module is in a call waiting state from another module, the module starts its operation. As described above, even a module in a call waiting state starts operation by execution control of the OS.
In Patent Documents 2 and 3 described above, the correctness of the called module can be verified, but it is not possible to determine whether or not the called module is to operate. Therefore, when a plurality of modules operate in cooperation, it is possible to change the execution order, and there is a problem that it is not possible to guarantee that the modules operate sequentially in a predetermined order such as a shared library.
The present invention has been made in view of the above, and an object of the present invention is to provide a program that more reliably prevents a change in execution order by a third party.
In order to solve the above-described problems and achieve the object, the present invention is a program including a plurality of modules to be executed by a computer, and the computer is an area that can be accessed only by modules operating in conjunction with each other. Among the modules operating in conjunction with each other, a memory including a shared area for storing an execution module identifier indicating the identifier of the module operating on the OS is provided. Immediately before switching, the first processing step of storing the identifier of another module as an execution module identifier in the shared area, and the execution stored in the shared area immediately after the operation switching from the other module is performed A second function for executing the function in the own module when the module identifier and the identifier of the own module match. And having a physical step.
According to the present invention, there is an effect that a change in the execution order by a third party can be prevented efficiently and reliably.
1 is a diagram of a system configuration applicable to the first embodiment. FIG. The figure of a data structure of an example of a key table. The figure where a plurality of modules operate on a secure processor. The functional block diagram of the module structure by 1st Embodiment. The memory map figure of the memory where the secure shared area was constructed | assembled. The figure of the whole flow of the process which switches between modules. The figure of the initialization process which an application module performs. The figure of the initialization process which a library module performs. The flowchart which shows the process before switching. The flowchart which shows the process after switching. The figure of the change of the state of a secure share area | region and a switching log | history area | region. The figure of the example of the regular execution order which a some module cooperates. The figure of the 1st example of an execution order attack. The figure of the 2nd example of an execution order attack. The figure of the 3rd example of an execution order attack. The figure of the example which applied 1st Embodiment to the 1st example of an execution order attack. The figure of the example which applied 1st Embodiment to the 2nd example of an execution order attack. The figure of the example which applied 1st Embodiment to the 3rd example of an execution order attack. The figure of the structure of the system applicable to the 2nd Embodiment of invention. The figure of a data structure of a module switching management table. The functional block diagram of the module structure by 2nd Embodiment. The flowchart which shows the process of a module switching management part. The flowchart which shows the initialization process which an application module performs. The flowchart which shows the initialization process which a library module performs. The flowchart which shows the process before switching. The flowchart of an example which shows the process after switching. The figure of the change of the state of a secure share area | region and a switching log | history area | region. The figure of the example of a structure using a virtual machine monitor. Diagram of operation by language exception handling mechanism. The figure of the structure of the system applicable to the 3rd Embodiment of invention. The functional block diagram of the module structure by 3rd Embodiment. The figure of the processing with respect to the language exception by a 3rd embodiment. 10 is a flowchart showing exception notification processing according to the third embodiment. The flowchart which shows the exception reception process by 3rd Embodiment. The figure of the change of the state of a secure share area | region and a switching log | history area | region. The figure of an operation | movement of an example by function setjmp / longjmp. The functional block diagram of the module structure by 4th Embodiment. The figure of a data structure of a context management table. The figure of the change of the state of a secure share area | region and a switching log | history area | region. The flowchart which shows the context registration process by 4th Embodiment. The flowchart of an example which shows the process after switching. The flowchart which shows a context setting process. The flowchart which shows a context change notification process. The flowchart which shows a context change reception process. The functional block diagram of the module structure by 5th Embodiment. The figure of a data structure of an example of a context management table. The figure of the change of the state of a secure share area | region and a switching log | history area | region. The flowchart which shows a context setting process.
Hereinafter, a first embodiment of the present invention will be described with reference to the drawings. First, an example system to which the first embodiment of the present invention can be applied will be described. FIG. 1 schematically shows a configuration of an example of a system applicable to the first embodiment of the present invention. FIG. 1 shows a schematic hardware configuration and a system view at the same time.
The target system includes a secure processor 200 and a memory 280 in terms of hardware, and each unit is connected by a bus 281. The secure processor 200 includes a core 210 and an encryption / decryption management unit 220. The core 210 is a part that forms the core of the secure processor 200 and manages execution of various programs, and includes a current task identifier register 212. The current task identifier register 212 stores a task identifier (referred to as a current task identifier) of a module currently being executed by the core 210. The encryption / decryption management unit 220 includes a key table 222, a selector 224, and an encryption / decryption device 226. The encryption / decryption management unit 220 operates in synchronization with access to the outside of the secure processor 200. The selector 224 controls the supply of each value stored in the key table 222 to the encryption / decryption device 226 under the control of the core 210.
In the target system, a single OS (Operating System) 180 operates on the core 210 of the secure processor 200, and one or more modules operate on the OS 180. In the example of FIG. 1, a plurality of modules (# 1) 110, module (# 2) 120, module (# 3) 130, and module (# 4) 140 are operating. Each module operating on the OS 180 has a program that is derived from the module. Each module has a task identifier which is a value for uniquely identifying each module in the core 210 in the secure processor 200.
In the example of FIG. 1, it is indicated that the module (# 1) 110 has a task identifier “# 1” and is generated from the program A (Prg A). The module (# 2) 120 has a task identifier “# 2” and is generated from the program B (Prg B). The module (# 3) 130 has a task identifier “# 3” and is generated from the program C (Prg C). The module (# 4) 140 has a task identifier “# 4” and is generated from the program B. Like the module (# 2) 120 and the module (# 4) 140, a plurality of modules can be generated from one program, and a plurality of modules having the same origin may have different task identifiers.
FIG. 2 shows an exemplary data structure of the key table 222. The key table 222 has n entries with index (ID) from “# 1” to “#n”, with the task identifier as an index. Each entry has a key value field, a head address field, and a tail address field. The key value field stores a key used when the encryption / decryption device 226 performs encryption or decryption. The start address field and the end address field respectively store the start address and end address on the memory 280 of data to be encrypted or decrypted with the key stored in the key value field.
Access to the key table 222 of each module (# 1) 110 to module (# 4) 140 is limited to entries corresponding to task identifiers of modules to be accessed, and entries corresponding to other task identifiers. Is controlled so that it cannot be accessed. For example, the module (# 1) 110 is controlled so that it can access only the ID “# 1” of the key table and cannot access other IDs “# 2” to “#n”.
Consider a case in which the start address P, the end address Q, and the key value K are written to the key table 222 when a certain module (#m) is executed on the core 210. In this case, the secure processor 200 refers to the current task identifier register 212 in the core 210 and identifies the task identifier of the module (#m) being executed on the core 210. Then, the key value K, the head address P, and the tail address Q are written for the entry #m in the key table 222 corresponding to the specified task identifier.
Next, a method for the module (#m) to access data on the memory 280 will be described. In the following, for the ID “#m” of the entries in the key table 222, the start address P, the end address Q, and the key K are already registered, and the module (#m) is at the address X on the memory 280. An example of accessing data will be described.
Module (#m) is when data is read from the address X in the memory 280, the security processor 200 obtains data D 1 corresponding from the memory 280 at the address X. Next, the encryption / decryption management unit 220 acquires, from the key table 222, a key value corresponding to the task identifier (#m) extracted from the current task identifier register 212. If the read destination address X is between the start address P and the end address Q written in the key table 222, the encryption / decryption management unit 220 stores the value obtained by decrypting the data D 1 by the encryption / decryption device 226 return. On the other hand, if the read destination address X is not between the start address P and the end address Q written in the key table 222, the data D 1 is returned to the core 210.
Similarly, when the module (#m) writes the data D 2 to the memory 280, the secure processor 200 encrypts the data D 2 with the key value K if the write destination address Y is between address P and address Q. The written data is written on the memory 280. On the other hand, if the write destination address Y is not between address P and address Q, data D 2 is written on the memory 280.
Here, a module configuration in a case where a plurality of modules operate in cooperation on the secure processor 200 will be schematically described. The plurality of modules operating on the secure processor 200 are configured to trust only a part of the other modules. Each module is encrypted and protected with a separate key and operates in a separate context. The context of each module is isolated from the OS and other modules, and data exchanged between modules is not passed to potentially hostile OSs or modules that do not cooperate.
FIG. 3 conceptually shows an exemplary module configuration when a plurality of modules operate on the secure processor 200. In the example of FIG. 3, module (# 1) 110 and module (# 2) 120 hold contexts such as separate stack (# 1) 119 and stack (# 2) 129, respectively. Is not visible directly from the module.
In order to exchange data between the module (# 1) 110 and the module (# 2) 120, a shared area 190 is provided. That is, when a plurality of modules operate on the secure processor 200, the context is isolated from other modules to protect the private data in the module, and the data exchange for the cooperative operation between the modules is shared. Area 190 is used.
FIG. 4 is a functional block diagram showing an example of a module configuration according to the first embodiment of the present invention. The cure processor 200 described with reference to FIG. 1 is commonly applied to the configuration of FIG. In FIG. 4, the secure processor 200 is omitted.
In FIG. 4, the module (# 1) 110 and the module (# 2) 120 each include the module switching mechanism according to the first embodiment. Here, it is assumed that the module (# 1) 110 is an application module and the module (# 2) 120 is a library module. Module (# 1) 110 and module (# 2) 120 operate in cooperation. The application module refers to a module that executes the program body after the initialization process, and the library module refers to a module that waits for a call from another module after the initialization process.
The module (# 1) 110 includes an initialization processing unit 111, a program (# 1) main body 112, a pre-switching processing unit 104A, a post-switching processing unit 106A, and a switching history area 118. Similarly, the module (# 2) 120 includes an initialization processing unit 121, a program (# 2) main body 122, and a switching history area 128, and a pre-switching processing unit 104A and post-switching processing of the module (# 1) 110, respectively. A pre-switching processing unit 104B and a post-switching processing unit 106B that perform processing common to the unit 106A. Further, the secure shared area 181 is shared on the memory 280 between the module (# 1) 110 and the module (# 2) 120 that cooperate with each other. The secure shared area 181 is a part of the shared area 190 shared by the module (# 1) 110 and the module (# 2) 120.
The initialization processing units 111 and 121 perform processing for constructing the secure shared area 181 used by the pre-switching processing units 104A and 104B and the post-switching processing units 106A and 106B. The pre-switching processing units 104A and 104B perform processing immediately before the module switches to another module.
The post-switching processing units 106A and 106B perform processing immediately after the module is switched from another module. The switching history area 118 is an area for storing information necessary for the switching pre-processing 104A and post-switching processing 106A to return by switching. Similarly, the switching history area 128 is an area for storing information that the pre-switching process 104B and the post-switching process 106B need for return by switching.
The secure sharing area 181 is an area for storing information that should be shared only between the module (# 1) 110 and the module (# 2) 120 that cooperate with each other. The secure shared area 181 is configured such that normal reading / writing from other than the cooperating modules is not possible.
FIG. 5 shows a memory map of an example of the memory 280 in which the secure shared area 181 is constructed, which is used in the module switching mechanism according to the first embodiment. The secure sharing area 181 is constructed and shared on the memory 280 for each module to be linked.
In the example of FIG. 5, the module (# 1) 110 and the module (# 2) 120 that cooperate with each other share the secure shared area 181-1 (Sh_mem1), and the module (# 3) 130 and the module (# 4) 140 that cooperate with each other. Share the secure sharing area 181-2 (Sh_mem2). The secure shared area 181-1 has a range from the start address Sh_start1 to the end address Sh_end1 on the memory 280. The secure shared area 181-2 is in the range from the start address Sh_start2 to the end address Sh_end2 on the memory 280.
Each of the secure shared areas 181-1, 181-2, ... includes an execution module identifier field 182, a switching flag field 183, a switching parameter field 184, and a switching source module identifier field 185. A switching flag and a switching parameter are stored. The execution module identifier is a module identifier of a module operating on the OS. The switching source module identifier is a module identifier of a module operating on the OS before switching when the module operating on the OS is switched to the module indicated by the execution module identifier. Note that the module identifier is a value for uniquely identifying each other among the linked modules.
A task identifier used in the secure processor 200 can be used as the module identifier. However, the present invention is not limited to this, and it is also possible to use a value determined so as to be able to identify each other between the linked modules as the module identifier. The switching flag indicates a value indicating whether the module switching is caused by calling the module or returning to the module. The switching parameter indicates a function name and an argument of a call destination in the case of calling a module, and an execution result in the case of returning to the module.
Next, the operation of an example of each module using the module switching function according to the first embodiment will be described. Here, a task identifier is used as the module identifier. The module (# 1) 110 is an application module generated from the program A with the module identifier “# 1”, and the module (# 2) 120 has the module identifier “# 2” from the program B. Assume that this is a generated library module.
In the following, the module (# 1) 110 and the module (# 2) 120 operate in cooperation to call the module (# 2) 120 from the module (# 1) 110, and then the module (# 2) 120 # 1) An example of returning to 110 will be described.
FIG. 6 shows the overall flow of processing for switching between the module (# 1) 110 and the module (# 2) 120. When the OS 180 starts executing the module (# 1) 110 and the module (# 2) 120, the initialization processing unit 111 performs initialization processing in the module (# 1) 110 that is an application module (step S10). In the module (# 2) 120 which is a library module, the initialization processing unit 121 performs initialization processing (step S20).
When the initialization process is completed, the module (# 2) 120 enters a sleep state waiting for a call. In the module (# 1) 110, the program (# 1) main body 112 is executed (step S11).
When calling the module (# 2) 120 in the program (# 1) main body 112 of the module (# 1) 110, the pre-switching processing of the module (# 1) 110 is executed by the pre-switching processing unit 104A (step S12). ), The module (# 1) 110 requests the OS 180 to switch. In response to this switching request, the OS 180 calls the module (# 2) 120 in the sleep state to resume execution, and returns the module (# 2) 120 from the sleep state. On the other hand, the module (# 1) 110 enters a sleep state waiting for a call.
When the module (# 2) 120 is restored by resuming execution from the OS 180, the post-switching processing unit 106B executes post-switching processing of the module (# 2) 120 (step S21). In the module (# 2) 120, the call destination, that is, the program (# 2) main body 122 is executed in the next step S22.
When calling the module (# 1) 110 in the program (# 2) main body 122 of the module (# 2) 120, the pre-switching processing unit 104B executes pre-switching processing of the module (# 2) 120 (step S23). ), The module (# 2) 120 requests the OS 180 to switch. In response to this switching request, the OS 180 calls the module (# 1) 110 in the sleep state to resume execution, and returns the module (# 1) 110 from the sleep state.
When the module (# 1) 110 is restored by a call from the OS 180, the switching processing unit 106A executes post-switching processing of the module (# 1) 110 (step S13). Then, in the module (# 1) 110, the execution of the program (# 1) main body 112 is resumed (step S14).
Thus, in the first embodiment, for example, the module (# 1) 110 starts executing the program (# 1) main body 112 after the initialization processing by the initialization processing unit 111. Further, when the module (# 1) 110 calls another module, the pre-switching processing unit 104A executes pre-switching processing. When called from another module, the post-switching processing unit 106A executes post-switching processing, and then the program (# 1) main body 112 is executed.
Hereinafter, each process in FIG. 6 will be described in detail.
First, module initialization processing will be described. Each module (# 1) 110 and module (# 2) 120, when the execution is started by the OS 180, execute an initialization process in order to perform cooperation between modules. FIG. 7 is a flowchart of an example of an initialization process performed by the application module. FIG. 8 is a flowchart of an example of initialization processing performed by the library module. The processing of the application module shown in FIG. 7 and the processing of the library module shown in FIG. 8 are executed in cooperation with each other. Hereinafter, the description will be made with reference to the flowchart of FIG. 8 as necessary, with a focus on the flowchart of FIG.
When the execution is started by the OS 180, AKE (Authentication and Key Exchange) is performed between the module (# 1) and the module (# 2) to be linked in Step S111-1 in FIG. 7 and Step S121-1 in FIG. ). By performing the AKE, the module (# 1) 110 and the module (# 2) 120 verify each other's validity and share the temporary key Key_AB. In this way, by executing AKE, each module to be linked shares a key that only the appropriate program to be linked knows and cannot be known by other modules.
In the next step S111-2, the module (# 1) 110 secures an area for the secure shared area 181 on the memory 280 and generates a module shared key Key_shared. The module shared key is a key shared between the cooperating modules, and is used for encrypting the secure shared area 181. The module shared key may be a value that cannot be known by a module that is not a cooperation target, and the value may be determined by an application module (module (# 1) 110 in this example) or generated from a random number. May be.
In step S111-3 and step S121-2 of FIG. 8, the module (# 1) 110 and the module (# 2) 120 are areas secured on the memory 280 by the module (# 1) 110 in step S111-2. Is exchanged for secure shared area information for making secure shared area 181-1. More specifically, first, the module (# 1) 110 encrypts the secure shared area information and the module identifier of the module (# 1) with the temporary key Key_AB, and the module (# 2) 120 via the memory 280. Send to.
Here, the secure shared area information includes the start address, end address, and module shared key of the area secured on the memory 280 by the module (# 1) 110 in step S111-2. In this example, the module (# 1) 110 uses, as the secure shared area information, the start address Sh_start1 and the end address Sh_end1 of the area on the memory 280 secured in step S111-2, and the module shared key Key_shared. ) Send to 120. At the same time, the module (# 1) 110 sends the module identifier (the task identifier “# 1” in this example) of the module (# 1) 110 to the module (# 2) 120.
The module (# 2) 120 decrypts the data sent from the module (# 1) 110 with the temporary key Key_AB, and creates secure shared area information (start address Sh_start1, end address Sh_end1, and module shared key Key_shared) # 1) The module identifier 110 is acquired.
On the other hand, the module (# 2) 120 sets the module identifier of the module (# 2) 120 to “# 2” from the task identifier of the module (# 2) 120, and encrypts this module identifier with the temporary key Key_AB. Then, this data in which the module identifier is encrypted is sent to the module (# 1) 110 via the memory 280. The module (# 1) 110 decrypts the data sent from the module (# 2) 120 with the temporary key Key_AB, so that the module identifier of the module (# 2) 120 (in this case, “# 2” of the task identifier). ) Can be obtained.
Through the processing in step S111-3 in FIG. 7 and step S121-2 in FIG. 8, a specific memory area and a key for encrypting the specific area are shared between the linked modules, and linked to each module. It is possible to determine a module identifier that is a value for uniquely identifying each module among modules to be performed.
In the next step S111-4, the module (# 1) 110 performs encryption setting for the secure shared area 181-1 using the secure shared area information. In parallel with this, the module (# 2) 120 performs encryption setting for the secure shared area 181-1 using the secure shared area information in step S121-3 of FIG. Specifically, the module (# 1) 110 and the module (# 2) 120, with respect to the secure processor 200, start address Sh_start1, end address Sh_end1, and key value Key_shared of the secure shared area 181 included in the secure shared area information. To set encryption.
When each of the modules (# 1) 110 and the module (# 2) 120 performs encryption setting on the secure processor 200, the secure processor 200 refers to the key table 222 and performs an entry corresponding to the current task identifier. Write the start address, end address, and key value.
Specifically, according to the encryption setting of the module (# 1) 110, the secure processor 200 sets the start address Sh_start1 and the end address for the index “# 1” corresponding to the module (# 1) 110 in the key table 222. Write Sh_end1 and key value Key_shared. Similarly, according to the encryption setting of the module (# 2) 120, the secure processor 200 performs the start address Sh_start1, the end address Sh_end1, and the index “# 2” corresponding to the module (# 2) 120 in the key table 200. Write the key value Key_shared.
With these settings, when the module (# 1) 110 or the module (# 2) 120 writes a value in the area Sh_mem1 on the memory 280, the secure processor 200 stores the value encrypted with the key Key_shared in the memory area 181. write. When the module (# 1) or the module (# 2) reads a value from the area Sh_mem1 on the memory 280, the secure processor 200 stores a value obtained by decrypting the data read from the area Sh_mem1 with the key Key_shared into the core 210. give.
The module (# 2) 120 writes the secure shared area information in the key table 222 in step S121-3, and then waits for a call from the module (# 1) 110, immediately before the process on the called side described later. The process is stopped and a sleep state is entered (step S121-4 in FIG. 8).
On the other hand, the module (# 1) 110 writes the secure shared area information to the key table 222 in step S111-4, and then in step S111-5, its module identifier (in this case, the task identifier “# 1”). ) Is written as an execution module identifier in the execution module identifier field 182 of the secure shared area 181-1. Then, in the next step S111-6, execution of the program (# 1) main body 112 in the module (# 1) 110 is started.
As described above, in the first embodiment, the module (# 1) 110 and the module (# 2) 120 perform encryption setting for the same area on the memory 280 using the same key. As a result, the module (# 1) 110 and the module (# 2) 120 can read the plaintext value from the area, and cooperate with the OS 180, the module (# 1) 110, and the module (# 2) 120. Only the encrypted value can be read from the corresponding area from other modules. That is, the linked modules (in this case, the module (# 1) 110 and the module (# 2) 120) can access the plaintext value only to the linked module in the area Sh_mem1 on the memory 280. A secure shared area can be provided.
Next, processing when calling another module from the module will be described with reference to FIGS. As described with reference to FIG. 6, when calling another module (calling module) from a module (calling module), pre-switching processing is executed on the calling module by the switching preprocessing unit 104A or 104B. Thereafter, post-switching processing is performed on the callee module by the post-switching processing unit 106A or 106B.
In the following, a case where the function sub (5) in the program (# 2) main body 122 in the module (# 2) 120 is called from the module (# 1) 110 will be described as an example. In the function sub (5), “sub” is a function name, and a numerical value “5” in parentheses is an argument to be passed to the function sub ().
FIG. 9 is a flowchart illustrating an example of the pre-switching process. FIG. 10 is an example flowchart illustrating post-switching processing. The processing contents of the pre-switching process and the post-switching process are different between a call process for calling a call destination module from the call source module and a return process for calling the call source module from the call destination module and returning the call source module.
FIG. 11 schematically shows changes in the states of the secure shared area 181 and the switching history areas 118 and 128 accompanying the calling process and the return process described later. In FIG. 11, “ID”, “flag”, and “parameter” in the secure shared area 181 indicate an execution module identifier, a switching flag, and a switching parameter, respectively. Immediately after the initialization process described above, the secure shared area 181 stores only the execution module identifier “# 1” written in step S111-5 in FIG. Also, nothing is stored in the switching history areas 118 and 128.
First, the calling process will be described. In the module (# 1) 110, the switching pre-processing unit 104A determines the type of module switching immediately before calling the module (# 2) 120 (step S104-1). Here, it is determined that the switching factor is the call, and the process proceeds to step S104-2. In step S104-2, the caller address Addr1 is stored in the switching history area 118 of the module (# 1) 110 in order to return to the correct caller address when returning from the callee.
In the next step S104-3, the switching pre-processing unit 104A writes a switching flag “call” indicating that the switching factor is “calling” in the switching flag field 183 of the secure shared area 181.
In the next step S104-4, the switching pre-processing unit 104A writes the function name “sub” of the call destination and its argument “5” as call information necessary for module switching in the switch parameter field 184. Further, in the next step S104-5, the switching pre-processing unit 104A writes its own module identifier “# 1” in the switching source module identifier field 185.
The process proceeds to step S104-9 which is common to the call process and the return process, and the pre-switching processing unit 104A makes a call destination module (module (in this example, module (in this example)) to the execution module identifier field 182. # 2) Write the module identifier “# 2” of 120). And a process transfers to step S104-10 and will be in a sleep state. This is for returning from the call destination or for preparing for a call from another module or the like, and the module (# 1) 110 puts itself into the sleep state and stops the process immediately before the post-switching process.
By writing the execution module identifier in the execution module identifier field 182, it can be considered that the right to execute the module has been transferred to the module indicated by the execution module identifier. For this reason, it is preferable to shorten the period from the execution module identifier writing in step S104-9 to the module processing stop in step S104-10 as much as possible, and the processing related to the information protection assets of the module in that period. It is desirable to avoid doing this.
When the module (# 1) 110 enters the sleep state in step S104-10, the execution right is switched to the OS 180. Thereafter, the execution right is transferred to the module (# 2) 120 under the control of the scheduler of the OS 180, and the module (# 2) 120 resumes execution.
When the module execution right is switched, post-switching processing is executed according to the procedure shown in FIG. When the module to be executed is switched from the module (# 1) 110 to the module (# 2) 120, the post-switching processing unit 106B of the module (# 2) 120 obtains an execution module identifier from the secure shared area 181 (step S106- 1). Then, it is determined whether or not the acquired execution module identifier value matches the module identifier value of the module (# 2) 120 (step S106-2).
If it is determined in step S106-2 that the value of the execution module identifier does not match the value of the module identifier of module (# 2) 120, the process proceeds to step S106-9 to enter the sleep state. The state of the module (# 2) 120 returns to the state immediately before the calling process. On the other hand, if it is determined in step S106-2 that the value of the execution module identifier matches the value of the module identifier of module (# 2) 120, the process proceeds to step S106-3.
In this example, since the module identifier “# 2” is written in the execution module identifier field 182 of the secure shared area 181, it is determined that the value matches the module identifier of the module (# 2) 120. Therefore, since the post-switching processing unit 106B knows that the module (# 2) 120 should be executed, the processing is shifted to step S106-3 and the post-switching processing is continued.
In step S106-3, the post-switching processing unit 106B obtains a switch flag from the switch flag field 183 of the secure shared area 181. In the next step S106-4, it is determined whether the acquired value of the switching flag indicates “calling” or “returning”. If it is determined that the value of the switching flag indicates “calling”, the process proceeds to step S106-5. On the other hand, if it is determined that the value of the switching flag indicates “return”, the process proceeds to step S106-7.
In this example, since the switching flag “call” indicating “calling” is written in the switching flag field 183 in step S104-3 of FIG. 9 as described above, it is determined that the value of the switching flag indicates “calling”. It turns out that a function call is requested. Therefore, the process proceeds to step S106-5.
In step S106-5, the post-switching processing unit 106B extracts the switching source module identifier from the switching source module identifier field 185 of the secure shared area 181 and stores it in the switching history area 128 of the module (# 2) 120. Thus, by storing in advance the module identifier indicating the switching source module, the module (# 2) 120 can return to the calling source module after executing the function.
In this example, as described above, since the module identifier “# 1” is written in the switching source module identifier field 185 in step S104-5 of FIG. 9, this module identifier “# 1” is extracted as the switching source module identifier. And stored in the switching history area 185.
In the next step S106-6, the post-switching processing unit 106B obtains the function name “sub” written as call information and the argument “5” from the switching parameter field 184 of the secure shared area 181. Then, in accordance with the function name “sub” and the argument “5”, the execution of the function sub (5) in the program (# 2) main body 122 is started.
As illustrated in FIG. 11, at the time when the calling process is finished, the secure shared area 181 is pre-switching processing, that is, the execution written in steps S104-3, S104-4, and S104-9 in FIG. The module identifier “# 2”, the switching flag “call”, and the switching parameters “sub” and “5” are stored. The switching history area 118 of the module (# 1) 110 stores the caller address Addr1 written in step S104-2. The switching history area 128 of the module (# 2) 120 stores the module identifier “# 1” written in the post-switching process, that is, step S106-5 in FIG.
Next, the return process will be described. In this example, execution is a process when returning from the callee module (# 2) 120 to the caller module (# 1) 110 that called the module (# 2) 120.
Immediately before returning from the module (# 2) 120 to the calling module, the switching pre-processing unit 104B of the module (# 2) 120 determines the type of module switching in step S104-1. Here, it is determined that the cause of switching is due to the return, and the process proceeds to step S104-6.
In step S104-6, the pre-switching processing unit 104B obtains the module identifier “# 1” of the switching source module stored in the switching history area 128 when called (step S106-5 in FIG. 9). obtain. In the next step S104-7, the switching pre-processing unit 104B writes a switching flag “ret” indicating that the switching factor is “return” in the switching flag field 183 of the secure shared area 181. Further, in the next step S104-8, the pre-switching processing unit 104B uses the result of the execution of the pre-switching processing unit 104B as call return information necessary for the return processing for the switching parameter field 184 of the secure shared area 181. Write an execution result Result_1.
The process proceeds to step S104-9, and the pre-switching processing unit 104B determines the module identifier of the calling source module (module (# 1) 110 in this example) with respect to the execution module identifier field 182 in the secure shared area 181. Write “# 1”. Then, the process proceeds to step S104-10 to enter a sleep state, and the process is stopped immediately before the post-switching process.
When the module (# 2) 120 enters the sleep state in step S104-10, the execution right is switched to the OS 180. Thereafter, the execution right is transferred to the module (# 1) 110 by the scheduler of the OS 180, and the module (# 1) 110 resumes execution.
When the module execution right is switched, post-switching processing is executed according to the procedure shown in FIG. When the module to be executed is switched from the module (# 2) 120 to the module (# 1) 110, the post-switching processing unit 106A of the module (# 1) 110 receives the module identifier “from the execution module identifier field 182 of the secure shared area 181. "# 1" is extracted (step S106-1), and since the extracted value matches the module identifier of the module (# 1) 110, the post-switching process is continued (step S106-2).
In step S106-3, the post-switching processing unit 106A obtains a switch flag from the switch flag field 183 of the secure shared area 181. In this example, since the switching flag “ret” written in the switching flag field 183 in step S104-7 in FIG. 9 described above is obtained, it is determined that the value of the switching flag indicates “return” (step S106-4). ), It can be seen that function call return is required. Therefore, the process proceeds to step S106-7.
In step S106-7, the post-switching processing unit 106A obtains the caller address Addr1 stored in the above-described step S104-2 from the switching history area 118, and also stores the address stored in the switching history area 118. The address Addr1 is deleted. In the next step S106-8, the post-switching processing unit 106A obtains the call return information from the switching parameter field 184 of the secure shared area 181. The module (# 1) 110 returns to the caller address Addr1 and resumes execution using the execution result Result_1 included in the acquired call return information.
As illustrated in FIG. 11, at the time when the return process is completed, the secure shared area 181 is switched to the pre-switching process, that is, the switching written in steps S104-7, S104-8, and S104-9 in FIG. A flag “ret”, a switching parameter “Result_1”, and an execution module identifier “# 1” are stored. In the switching history area 118 of the module (# 1) 110, the caller address Addr1 is deleted in the post-switching process, that is, step S106-7 in FIG. 10, and nothing is stored. Similarly, in the switching history area 128 of the module (# 2) 120, the module identifier of the caller is deleted in the pre-switching process, that is, step S104-6, and nothing is saved.
In this way, an area accessible only between the linked modules is provided, and the module identifier of the callee module is written in the area immediately before execution of the caller module is switched to another module. Then, immediately after execution is switched from the caller module to the callee module, the callee module compares the module identifier value of the callee module written in the area with its own module identifier. The validity of the execution order can be guaranteed. A specific example showing that the validity of the execution order can be guaranteed will be described later.
The fact that the first embodiment can guarantee the validity of the module execution order will be described with reference to FIGS. Here, module # 1 which is an application module based on program X (Prg X), module # 2 based on program Y (Prg Y) which is a library module, and module # 3 based on program Z (Prg Z), respectively, are three modules. It shall be executed in cooperation. At this time, the module # 1 is configured to call the module # 2, and the module # 2 is configured to call the module # 3.
FIG. 12 shows an example of the normal execution order. When the execution of modules # 1 to # 3 is started, modules # 2 and # 3 are put into a sleep state, the module to be executed at timing A is switched, module # 1 is called from module # 1, and module # 1 Is put to sleep. The module to be executed at the timing B is switched, the module # 2 is called from the module # 2, and the module # 2 is put in the sleep state. Next, the module to be executed at the timing C is switched, the module # 2 is restored from the module # 3, and the module # 3 is set in the sleep state.
Hereinafter, an example of an execution order attack performed on the execution order shown in FIG. 12 will be described with reference to FIGS. These execution order attacks are usually performed by changing the execution order of modules by using or modifying the OS program.
FIG. 13 shows a first example of an execution order attack. In the first example, the execution of the module in the sleep state is started before the module is called from the module of the regular caller. FIG. 13 shows an attack in which the module # 2 to be called from the module # 1 at the timing A starts execution at the timing D before the timing A using the OS scheduler or the like. In this case, when the module # 1 calls the module # 2 at the timing A, the execution of the top portion of the module # 2 has already been completed. As an example, when the authentication process is included in the top part of module # 2, the remaining part of module # 2 can be executed without going through this authentication process. This first example is called a timing attack.
FIG. 14 shows a second example of the execution order attack. In the second example, the calling order of modules is changed with respect to the normal order. Normally, as shown in FIG. 12, module # 1 is called from module # 2, and module # 2 is called from module # 3. On the other hand, FIG. 14 shows an attack that uses the OS scheduler or the like to start execution of module # 3 instead of module # 2 at timing A called from module # 1. As an example, when module # 3 can be executed after being authenticated by the authentication process in module # 2, module # 3 is executed without going through the authentication process in module # 2. Become. This second example is called a call order attack.
FIG. 15 shows a third example of the execution order attack. In the third example, the OS starts execution in advance in module # 5 and module # 2, which are different from module # 1. Then, the module # 2 is called from the module # 5, and for example, only the head part is executed and returned to the module # 5 in the middle state. Module # 2 goes to sleep. At this time, the OS can store the intermediate state of module # 2 and then call module # 2 in the intermediate state from module # 1 at timing A. Even in this case, when the authentication process is included in the head part of module # 2, the remaining part of module # 2 can be executed without this authentication process. This third example is called an intermediate state module insertion attack.
With reference to FIGS. 16 to 18, it is verified whether or not the first to third examples of the execution order attack described above can be avoided with the configuration according to the first embodiment. 16 to 18, the in-shared area CurID indicates an execution module identifier stored in the secure shared area 181.
FIG. 16 is an example in which the first embodiment is applied to the first example shown in FIG. 13, that is, the timing attack. In this case, until the module # 2 is called from the module # 1 at the timing A, “# 1” indicating the module # 1 is stored in the secure shared area 181 as the execution module identifier. On the other hand, when execution of module # 2 is resumed from the sleep state, module # 2 executes the above-described post-switching process, and the execution module stored in its own module identifier and secure shared area 181 in step S106-2 in FIG. It is determined whether or not the identifier matches.
When the module # 2 is restarted at the timing D illustrated in FIG. 13, the value of the execution module identifier stored in the secure shared area 181 is “# 1”, and the module identifier of the module # 2 itself has the value “ # 2 "and they do not match. Therefore, the process proceeds to step S106-9, the module # 3 is set in the sleep state, and the timing attack is avoided.
FIG. 17 shows an example in which the first embodiment is applied to the second example shown in FIG. In this case, the module identifier value of module # 3 called from module # 1 is “# 3”. On the other hand, the value “# 2” is stored in the secure shared area 181 as an execution module identifier to be executed next in step S104-9 of FIG. Therefore, in step S106-2 of the post-switching process described above with reference to FIG. 10, it is determined that the own module identifier does not match the execution module identifier stored in the secure shared area 181. Accordingly, the process proceeds to step S106-9, the module # 2 is set in the sleep state, and the call order attack is avoided.
FIG. 18 shows an example in which the first embodiment is applied to the third example shown in FIG. 15, that is, the midway state module insertion attack. In this case, the module # 2 and the module # 5 are initialized in a system different from the execution of the module # 1, and share the module shared key Key_Shared_1. On the other hand, the module # 1 has the module shared key Key_Shared_2 by initialization. Therefore, the module shared key Key_Shared_1 shared between the module # 2 and the module # 5 is not shared with the module # 1. Therefore, when the module # 1 calls the module # 2, the module # 2 reads the information stored in the secure shared area 181 in a state that is not plain text.
As described above, since the module # 1 and the module # 2 cannot share the information written in the secure sharing area 181, they cannot cooperate with each other. That is, it is possible to avoid inserting a module in the middle state.
As described above, in the first embodiment, when a module is restarted, an execution module indicating the module to be executed and stored in the secure shared area 181 by the post-switching process. By determining whether or not the identifier matches, an execution order attack can be avoided.
The first embodiment can be variously modified in addition to the above without departing from the gist of the present invention. For example, in the above description, the memory 280 connected to the secure processor 200 via the bus 281 is used as the secure shared area 181, but this is only an example of an applicable storage device. For example, as the secure shared area 181, a cache memory built in the secure processor 200 may be used, or a non-volatile memory such as a flash memory may be used. Further, the secure shared area 181 is not limited to a semiconductor memory, and for example, a hard disk may be used.
Similarly, in the above description, the AKE and secure shared area information in the initialization process are exchanged using the memory 280. However, this is merely an example of an applicable storage device. That is, AKE, secure shared area information, etc. may be exchanged via a cache memory, flash memory, hard disk, or the like.
In the above description, the secure processor 200 includes only the core 210 and the encryption / decryption management unit 220. However, this is not limited to this example. For example, the secure processor 200 may include an internal memory, a DMA (Direct Memory Access) controller, and the like. Further, in the above description, the key table 222 in the encryption / decryption management unit 220 is dynamically set. However, this is not limited to this example, and the key table 222 is created in advance and embedded in a non-volatile storage area in the secure processor 200. It may be a key.
In the first embodiment described above, AKE is started from the application module side, but AKE may be started from the library module side.
In the first embodiment described above, the initialization process is executed at the start of execution of each module, but this is not limited to this example. That is, in the present invention, the initialization process is not limited to the start of program execution. For example, the initialization process may be executed immediately before the application module and the library module cooperate. Further, the initialization process may be executed at any time as long as it is immediately before the modules cooperate.
In the first embodiment described above, the number of library modules that cooperate with the application module is limited to 2 to 3, but this is not limited to this example. That is, the first embodiment can also be applied when four or more library modules cooperate with an application module.
That is, the embodiment of the subject 1 can be applied to a case where an application module cooperates with a plurality of library modules, a case where another library module is called from the library module, and a case where an application module is called from the library module. In any of these cases, four or more modules can share a secure shared area by sharing the same key in all modules and constructing a secure shared area using the key.
In the first embodiment described above, one secure shared area is provided for one application module. However, one application module may use a plurality of secure shared areas. For example, a module that cooperates with the application module shares the secure shared area Sh_mem3 and another module that cooperates shares the secure shared area Sh_mem4. Further, when modules # 1, # 2 and # 3 are linked, one secure shared area is provided between modules # 1 and # 2, between modules # 2 and # 3, and between modules # 1 and # 3. May be secured.
In the first embodiment described above, the encryption / decryption management unit 220 has been described as being configured as an independent unit, but this is not limited to this example. For example, it may be included in a unit that accesses outside the processor, such as a BIU (Bus Interface Unit) or a DMA controller.
In the first embodiment described above, the secure shared area 181 that can be accessed only between the cooperating modules is constructed using the data encryption mechanism of the secure processor 200, but this is not limited to this example. That is, not only the data encryption mechanism but also the secure shared area 181 may be constructed using other methods as long as it is possible to construct an area that can be accessed only between modules that cooperate with the support of the secure processor 200.
In the first embodiment described above, the switching of the module is performed by obtaining support of the OS 180, but this is not limited to this example. For example, the module is switched directly using a hardware mechanism. The present invention can also be applied to cases (see Patent Document 1).
In the first embodiment described above, the switching history areas 118 and 128 are managed as independent data areas, but this is not limited to this example. In other words, the switching history regions 118 and 128 are not necessarily configured independently, and may be configured to be included in a stack included in each module.
In the first embodiment described above, the task identifier is used as the module identifier. However, this is not limited to this example, and other values may be used as long as the module identifier is a unique value among the linked modules. Good. For example, each module may generate a module identifier by a random number. In addition, the secure processor 200 may have a plurality of processor cores, and a unique identifier may be assigned to each processor core. In this case, each module can use a value obtained by combining a core identifier for identifying a processor core and a task identifier as a module identifier. However, the present invention is not limited to this, and only one of the modules may use a task identifier as a module identifier, and the other module may use a value obtained from a random number as a module identifier, depending on an agreement between linked modules.
Next, a second embodiment of the present invention will be described. In the first embodiment described above, the secure shared area 181 that can be read and written only by the cooperating modules is configured using a part of the area on the memory 280. On the other hand, in the second embodiment, the secure shared area is provided as hardware on the secure processor.
FIG. 19 schematically shows a configuration of an example of a system according to the second embodiment. In FIG. 19, a schematic hardware configuration and a system view are shown at the same time. Note that, in FIG. 19, the same reference numerals are given to portions common to FIG. 1 described above, and detailed description thereof is omitted.
In FIG. 19, the secure processor 400 according to the second embodiment includes a core 410, a BIU 430, and a module switching management unit 420. The module switching management unit 420 includes a module switching management table 422 and a table access control unit 424.
The table access control unit 424 determines whether or not to permit access to the module switching management table 422 from the core 410, and if not permitted, issues an exception or the like. The BIU 430 is connected to an external bus 281 and is a bus interface unit for connecting to the bus 281 from the inside of the secure processor 400. The core 410 is connected to the bus 281 via the BIU 430 and can access the memory 280, for example.
The secure processor 400 according to the second embodiment does not include an encryption / decryption management unit having a key table and an encryption / decryption device, unlike the secure processor 200 according to the first embodiment described above.
FIG. 20 shows an exemplary data structure of the module switching management table 422. The module switching management table 422 has n entries in which the index (Idx) indicating the shared area number is from “# 1” to “#n”. Each entry has a module shared key field, an execution module identifier field, a switching source module identifier field, a switching flag field, a switching parameter field, and a valid bit. The valid bit is represented as “V” in FIG. Among these, the execution module identifier field, the switching source module identifier field, the switching flag field, and the switching parameter field are the same as the fields corresponding to the names in the secure shared area 181 described with reference to FIG.
The module shared key field stores a value that only a module that can access the field can know. The valid bit is a flag indicating whether the entry is valid or invalid.
FIG. 21 is a functional block diagram illustrating an example of a module configuration according to the second embodiment. Note that, in FIG. 21, the same reference numerals are given to portions common to FIG. 4 described above, and detailed description thereof is omitted.
In FIG. 21, a module (# 1) 310 that is an application module includes an initialization processing unit 311, a program (# 1) main body 112, a pre-switching processing unit 304A, a post-switching processing unit 306A, and a switching history area 118. The module (# 2) 320, which is a library module, includes an initialization processing unit 321, a program (# 2) main body 122, and a switching history area 128, and a pre-switching processing unit 304A and a module (# 1) 310, respectively. A pre-switching processing unit 304B and a post-switching processing unit 306B that perform processing common to the post-switching processing unit 306A are provided.
In the second embodiment, unlike the first embodiment described above, a secure shared area shared by the module (# 1) 310 and the module (# 2) 320 is provided on the memory 280. Absent.
Next, an exemplary operation of each module using the module switching function according to the second embodiment will be described. Here, a task identifier is used as the module identifier. The module (# 1) 310 is an application module generated from the program A with the module identifier “# 1”, and the module (# 2) 320 has the module identifier “# 2” from the program B. Assume that this is a generated library module.
Here, for example, in the module (# 1) 310, the processing by the initialization processing unit 311, the pre-switching processing unit 304A and the post-switching processing unit 306A is the same as the initialization processing unit 111 and the pre-switching processing according to the first embodiment described above. The processing by the unit 104A and the post-switching processing unit 106A is different in that the module switching management table is accessed using the shared area number and the module shared key shared in the initialization process. The same applies to the module (# 2) 320.
FIG. 22 is a flowchart illustrating an example of processing of the module switching management unit 424. When the module switching management unit 424 is accessed to the module switching management table 422, the module switching management unit 424 performs processing according to the flowchart of FIG.
When each module (# 1) 310 and module (# 2) 320 access a field on the module switching management table 422, the core 410 designates a shared area number and a module shared key to be accessed. For example, when access is made from the module (# 1) 310 to the module switching management table 422, first, from the core 410 to the table access control unit 424 in the module switching management unit 420, the shared area number of the access destination and A module shared key is specified.
In step S424-1, the table access control unit 424 refers to the module switching management table 422 and acquires the value of the valid bit corresponding to the designated shared area number. In the next step S424-2, the table access control unit 424 determines whether or not the acquired valid bit is “a value indicating invalidity” (step S424-2).
If it is determined that the acquired valid bit is “value indicating invalidity”, the process proceeds to step S424-3, and the table access control unit 424 determines whether the access request specified from the core 410 is a write request. Determine whether or not. As a result of the determination, if it is determined that the access request is a request other than a write request, the process proceeds to step S424-6, and the table access control unit 424 issues an exception.
On the other hand, if it is determined in step S424-3 that the access request is a write request, the process proceeds to step S424-4. In step S424-4, the table access control unit 424 rewrites the valid bit corresponding to the designated shared area number to “a value indicating validity”. In the next step S424-5, the designated writing is executed for the designated shared area number in the designated module switching management table 422.
When it is determined in step S424-2 described above that the valid bit is other than “value indicating invalidity”, the process proceeds to step S424-7. In step S424-7, the table access control unit 424 obtains a module shared key corresponding to the designated shared area number from the module switching management table 422.
In the next step S424-8, the table access control unit 424 determines whether the acquired module shared key value matches the module shared key given from each module (# 1) 310 or module (# 2) 320. Determine whether. If it is determined that they match, the process proceeds to step S424-9, and the table access control unit 424 executes the specified reading / writing on the module switching management table 422 (S424-9). On the other hand, if it is determined that they do not match, the process proceeds to step S424-6, and the table access control unit 424 issues an exception.
Next, module initialization processing according to the second embodiment will be described. When the execution is started by the OS 180, each module (# 1) 310 and the module (# 2) 320 execute an initialization process in order to perform cooperation between the modules. FIG. 23 is a flowchart illustrating an example of an initialization process performed by the module (# 1) 310 that is an application module. FIG. 24 is a flowchart illustrating an example of initialization processing performed by the module (# 2) 320 that is a library module. The process of the application module shown in FIG. 23 and the process of the library module shown in FIG. 24 are executed in cooperation with each other.
The following description will be made with reference to the flowchart of FIG. 24 as necessary, with a focus on the flowchart of FIG. In the flowcharts of FIGS. 23 and 24, the processes common to the flowcharts of FIGS. 7 and 8 described above are denoted by the same reference numerals, and detailed description thereof is omitted.
When execution is started by the OS 180, AKE is performed between the module (# 1) 310 and the module (# 2) 320 in step S111-1 in FIG. 23 and step S121-1 in FIG. To do. As a result, the module (# 1) 110 and the module (# 2) 120 verify the validity of each other's program and share the temporary key Key_AB.
In FIG. 23, in the next step S311-2, the initialization processing unit 311 of the module (# 1) 310 permits access to a specific entry (hereinafter referred to as a shared area) in the module switching management table 422. The module shared key Key_shared for generating the key is generated from a random number or the like.
In the next step S311-3, the initialization processing unit 311 receives the module shared key Key_shared and the module identifier (value is “# 1”) for the specific shared area number (eg, “# 1”). ”). Here, the shared area number refers to an index of an entry in the module switching management table 422 shared between modules. Thus, an empty area of the module switching management table 422 is secured, and a shared area shared with the module (# 2) 320 is secured on the module switching management table 422.
In step S311-3, since the module switching management table 422 is accessed, the module switching management unit 420 controls the access according to the flowchart of FIG. In this case, the valid bit for the designated shared area number is a “value indicating invalidity” and a write request. Therefore, the module switching management unit 420 writes the specified module shared key and module identifier in the module shared key field and the execution module identifier field in the module switching management table 422, respectively, and sets the validity bit to “value indicating validity”. Set to.
In the next step S 311-4, the module (# 1) 310 encrypts the secure shared area information and the module identifier with the temporary key Key_AB, and sends it to the module (# 2) 320 via the memory 280. Here, the secure shared area information indicates the shared area number of the shared area secured in step S311-3 and the module shared key Key_shared.
In this example, the module (# 1) 310 encrypts the shared area number “# 1” of the shared area secured in step S311-3 and the shared key Key_shared as secure shared area information, and the module (# 2) 320. Send to. At the same time, the module (# 1) 310 encrypts the task identifier “# 1” as a module identifier indicating itself and sends it to the module (# 2) 320.
In step S321-2 of FIG. 24, the module (# 2) 320 decrypts the data sent from the module (# 1) 310 with the temporary key Key_AB, and information on the secure shared area (shared area number “# 1” and Shared key Key_shared) and module identifier “# 1” are acquired. As a result, the module (# 1) 310 can share information on the module (# 2) 320 side.
Further, the module (# 2) 320 encrypts the task identifier “# 2” with the key Key_AB as a module identifier indicating itself, and sends it to the module (# 1) 310 via the memory 280. The module (# 1) 310 can obtain the module identifier “# 2” indicating the module (# 2) 320 by decrypting the data sent from the module (# 2) 320 with the temporary key Key_AB. Thereby, the module (# 2) 320 information can be shared on the module (# 1) 310 side.
In FIG. 24, in step S121-4, the module (# 2) 320 stops processing immediately before processing to be described later and enters a sleep state, and waits for a call from the module (# 1) 310. In FIG. 23, in step S111-6, the module (# 1) starts executing the program (# 1) main body 112.
Next, processing when calling another module from the module will be described with reference to FIGS. Similar to the first embodiment described above, when calling another module (calling module) from a module (calling module), the switching preprocessing unit 304A or 304B performs pre-switching processing on the calling module. After that, the post-switching processing unit 306A or 306B executes post-switching processing on the callee module.
In the following, a case where the function sub (5) in the program (# 2) main body 122 in the module (# 2) 320 is called from the module (# 1) 310 will be described as an example. In the function sub (5), “sub” is a function name, and a numerical value “5” in parentheses is an argument to be passed to the function sub ().
FIG. 25 is an example flowchart illustrating pre-switching processing according to the second embodiment. FIG. 26 is an example flowchart illustrating post-switching processing according to the second embodiment. The processing contents of the pre-switching process and the post-switching process are different between a call process for calling a call destination module from the call source module and a return process for calling the call source module from the call destination module and returning the call source module.
FIG. 27 schematically shows changes in the states of the module switching management table 422 and the switching history areas 118 and 128 accompanying the calling process and the return process described later. In FIG. 27, “Key”, “CMID”, “flag”, “parameter”, and “V” in the module switching management table 422 are a module shared key, an execution module identifier, a switching flag, a switching parameter, and a valid parameter, respectively. Indicates a flag. The module switching management table 422 indicates the state of the entry corresponding to the shared area number “# 1”.
Immediately before the initialization process described above, nothing is stored in the module shared key, execution module identifier, switch flag, and switch parameter fields of the module switch management table 422. The valid bit field stores a value “0” that is a “value indicating invalidity”. By performing the initialization process, the module shared key Key_shared and the execution module identifier “# 1” are stored in the module shared key field and the execution module identifier field of the module switching management table 422, respectively. Also, a value “1” that is “a value indicating validity” is stored in the valid bit field.
First, the calling process will be described. In the module (# 1) 310, the switching pre-processing unit 304A determines the type of module switching immediately before calling the module (# 2) 320 (step S304-1). Here, it is determined that the switching factor is the call, and the process proceeds to step S304-2. In step S304-2, in order to return to the correct caller address when returning from the callee, the caller address Addr1 is stored in the switching history area 118 of the module (# 1) 310.
In the next step S304-3, the switching pre-processing unit 304A performs a process of writing a switching flag “call” indicating that the switching factor is “calling” in the switching flag field of the module switching management table 422. . At this time, according to the flowchart of FIG. 22 described above, the module switching management unit 420 performs determination based on the valid bit and the module shared key, and controls writing to the module switching management table 422.
That is, first, the module (# 1) 310 specifies the shared area number “# 1”, the module shared key Key_shared, and the switching flag “call”. The secure processor 400 (module switching management unit 420) saves in the entry indicated by the shared area number “# 1” designated from the module (# 1) 310 from the module switching management table 422 according to the flowchart of FIG. The effective bits that have been set are acquired (step S424-1 in FIG. 22). The valid bit has been rewritten to “value indicating validity” in the initialization process described with reference to FIG. 23 (step S424-4). Accordingly, the module switching management unit 420 acquires the module shared key stored in the entry indicated by the shared area number “# 1” from the module switching management table 422 in step S424-7 in FIG.
The module switching management unit 420 determines whether or not the module shared key acquired from the module switching management table 422 matches the module shared key Key_shared given from the module (# 1) 310. In this example, since these module shared key and module shared key Key_shared match, the module switching management unit 420 performs the switching flag field of the entry corresponding to the shared area number “# 1” in the module switching management table 422. Write the switching flag “call”.
In the next step S304-4, the pre-switching processing unit 304A makes a call destination function name “sub” and its argument “5” as call information necessary for module switching for the switching parameter field of the module switching management table 422. "write. Also in this case, as described above, the module switching management unit 420 controls writing to the module switching management table 422 based on the determination result based on the valid bit and the module shared key.
The process proceeds to step S304-8 which is common to the calling process and the return process, and the pre-switching processing unit 304A writes its own module identifier “# 1” in the switching source module identifier field of the module switching management table 422. . Further, in the next step S304-9, the pre-switching processing unit 304A, for the execution module identifier field of the module switching management table 422, calls the module identifier “of the called module (module (# 2) 320 in this example)”. Write # 2.
Also in the processing of step S304-8 and step S304-9, as described above, the module switching management unit 420 controls writing to the module switching management table 422 based on the determination result based on the valid bit and the module shared key.
Then, the process proceeds to step S304-10, and the module (# 1) 310 enters a sleep state. This is to prepare for a return from the call destination or a call from another module or the like, and the module (# 1) 310 sets itself to a sleep state and stops the process immediately before the post-switching process.
When the module (# 1) 310 enters the sleep state in step S304-10, the execution right is switched to the OS 180. Thereafter, the execution right is transferred to the module (# 2) 320 under the control of the scheduler of the OS 180, and the module (# 2) 320 resumes execution.
When the module execution right is switched, post-switching processing is executed according to the procedure shown in FIG. When the module to be executed is switched from the module (# 1) 310 to the module (# 2) 320, in step S306-1, the post-switching processing unit 306B of the module (# 2) 320 displays the shared area information “# 1” and The module shared key Key_shared is designated, and the secure processor 400 is requested to acquire the execution module identifier.
That is, first, the module (# 2) 320 designates the shared area number “# 1” and the module shared key Key_shared. The secure processor 400 (module switching management unit 420) saves in the entry indicated by the shared area number “# 1” designated from the module (# 1) 310 from the module switching management table 422 according to the flowchart of FIG. The effective bits that have been set are acquired (step S424-1 in FIG. 22). The valid bit has been rewritten to “value indicating validity” in the initialization process described with reference to FIG. 23 (step S424-4). Accordingly, the module switching management unit 420 acquires the module shared key stored in the entry indicated by the shared area number “# 1” from the module switching management table 422 in step S424-7 in FIG.
The module switching management unit 420 determines whether or not the module shared key acquired from the module switching management table 422 matches the module shared key Key_shared given from the module (# 1) 310. In this example, since these module shared key and module shared key Key_shared match, the module switching management unit 420 executes from the execution module identifier field of the entry corresponding to the shared area number “# 1” in the module switching management table 422. The module identifier “# 2” is acquired. The acquired execution module identifier “# 2” is transmitted to the module (# 2) 320.
The post-switching processing unit 306B of the module (# 2) 320 determines whether or not the value “# 2” of the execution module identifier transmitted from the secure processor 400 matches the value of the module identifier of the module (# 2) 320. Is determined (step S306-2).
If it is determined in step S306-2 that the value of the execution module identifier does not match the value of the module identifier of module (# 2) 320, the process proceeds to step S306-9 to enter the sleep state. The state of the module (# 2) 320 returns to the state immediately before the calling process. On the other hand, if it is determined in step S306-2 that the value of the execution module identifier matches the value of the module identifier of module (# 2) 320, the process proceeds to step S306-3.
In this example, since the module identifier “# 2” is written in the execution module identifier field 182 of the secure shared area 181, it is determined that the value matches the module identifier of the module (# 2) 320. Therefore, since the post-switching processing unit 306B knows that the module (# 2) 320 should be executed, the process proceeds to step S306-3 and the post-switching process is continued.
In step S306-3, the post-switching processing unit 306B specifies the shared area number “# 1” and the module shared key Key_shared, and obtains a switching flag from the module switching management table 422. Also in this case, as described above, the module switching management unit 420 reads from the module switching management table 422 based on the determination result by the valid bit and the module shared key Key_shared for the entry indicated by the shared area number “# 1”. To control.
In the next step S306-4, it is determined whether the acquired value of the switching flag indicates “calling” or “returning”. If it is determined that the value of the switching flag indicates “calling”, the process proceeds to step S306-5. On the other hand, if it is determined that the value of the switching flag indicates “return”, the process proceeds to step S306-7.
In this example, as described above, the switching flag “call” indicating “calling” is written in the switching flag field of the module switching management table 422 in step S304-3 in FIG. Therefore, it is determined that the value of the switching flag indicates “call”, and it is understood that a function call is requested. Therefore, the process proceeds to step S306-5.
In step S306-5, the post-switching processing unit 306B specifies the shared area number “# 1” and the module shared key Key_shared in order to return to the calling source, and starts from the switching source module identifier field of the module switching management table 422. Get the switching source module identifier. Also in this case, as described above, the module switching management unit 420 reads from the module switching management table 422 based on the determination result by the valid bit and the module shared key Key_shared for the entry indicated by the shared area number “# 1”. To control. The extracted switching source module identifier is stored in the switching history area 128 of the module (# 2) 320.
In the next step S306-6, the post-switching processing unit 306B specifies the shared area number “# 1” and the module shared key Key_shared, and the function written as call information from the switching parameter field of the module switching management table 422 The name “sub” and the argument “5” are obtained. Also in this case, as described above, the module switching management unit 420 reads from the module switching management table 422 based on the determination result by the valid bit and the module shared key Key_shared for the entry indicated by the shared area number “# 1”. To control. The execution of the function sub (5) in the program (# 2) main body 122 is started in accordance with the extracted function name “sub” and the argument “5”.
As illustrated in FIG. 27, when the calling process is completed, the module switching management table 422 is written in the pre-switching process, that is, in steps S304-3, S304-4, and S304-9 in FIG. The execution module identifier “# 2”, the switching flag “call”, and the switching parameters “sub” and “5” are stored. The value of the valid bit field remains “1”. The switching history area 118 of the module (# 1) 310 stores the caller address Addr1 written in step S304-2. In the switching history area 128 of the module (# 2) 120, the module identifier “# 1” written in the post-switching process, that is, step S306-5 in FIG. 26 is stored.
Next, the return process will be described. In this example, execution is a process when returning from the callee module (# 2) 320 to the caller module (# 1) 310 that called the module (# 2) 320.
Immediately before returning from the module (# 2) 320 to the calling module, the switching pre-processing unit 304B of the module (# 2) 320 determines the type of module switching in step S304-1. Here, it is determined that the cause of switching is due to the return, and the process proceeds to step S304-5. In step S304-5, the switching pre-processing unit 304B uses the module identifier “# 1” of the switching source module stored in the switching history area 128 when called (step S306-5 in FIG. 26). obtain.
In the next step S304-6, the pre-switching processing unit 304B designates the shared area number “# 1” and the module shared key Key_shared, and sets the flag “ret” indicating restoration as a switching flag, in the module switching management table 422. Write in the switch flag field. Also in this case, as described above, the module switching management unit 420 writes to the module switching management table 422 based on the determination result by the valid bit for the entry indicated by the shared area number “# 1” and the module shared key Key_shared. Control.
In the next step S304-7. The pre-switching processing unit 304B designates the shared area number “# 1” and the module shared key Key_shared, and uses the module (#) as the call return information necessary for the return process for the switching parameter field of the module switching management table 422. 2) Write an execution result “Result_1” that is the result of the execution of 320.
The process proceeds to step S304-8, which is common to the calling process and the return process, and the pre-switching processing unit 304A sets its own module identifier “# 2” in the switching source module identifier field of the module switching management table 422. write. Further, in the next step S304-9, the pre-switching processing unit 304A makes the module identifier “of the module to be called (module (# 2) 310 in this example) with respect to the execution module identifier field of the module switching management table 422. # 1 ").
When the module (# 2) 320 enters the sleep state in step S304-10, the execution right is switched to the OS 180. Thereafter, the execution right is transferred to the module (# 1) 310 by the scheduler of the OS 180, and the module (# 1) 310 resumes execution.
When the module execution right is switched, post-switching processing is executed according to the procedure shown in FIG. When the module to be executed is switched from the module (# 2) 320 to the module (# 1) 310, the post-switching processing unit 306A of the module (# 1) 310 specifies the shared area number “# 1” and the module shared key Key_shared. Then, the secure processor 400 is requested to acquire the execution module identifier. In response to this request, the secure processor 400 retrieves the execution module identifier “# 1” written in the execution module identifier field of the module switching management table 422 and returns it to the module (# 1) 310.
That is, first, the module (# 1) 310 specifies the shared area number “# 1” and the module shared key Key_shared. The secure processor 400 (module switching management unit 420) saves in the entry indicated by the shared area number “# 1” designated from the module (# 1) 310 from the module switching management table 422 according to the flowchart of FIG. The effective bits that have been set are acquired (step S424-1 in FIG. 22). The valid bit has been rewritten to “value indicating validity” in the initialization process described with reference to FIG. 23 (step S424-4). Accordingly, the module switching management unit 420 acquires the module shared key stored in the entry indicated by the shared area number “# 1” from the module switching management table 422 in step S424-7 in FIG.
The module switching management unit 420 determines whether or not the module shared key acquired from the module switching management table 422 matches the module shared key Key_shared given from the module (# 1) 310. In this example, since these module shared key and module shared key Key_shared match, the module switching management unit 420 executes from the execution module identifier field of the entry corresponding to the shared area number “# 1” in the module switching management table 422. The module identifier “# 1” is acquired.
When the execution module identifier “# 1” is returned from the secure processor 400, the post-switching processing unit 306A returns the execution module identifier “# 1” returned from the secure processor 400 and the module (in step S306-2). # 1) It is determined whether or not the module identifier value 310 matches.
If it is determined in step S306-2 that the value of the execution module identifier does not match the value of the module identifier of module (# 1) 310, the process proceeds to step S306-9 to enter the sleep state. The state of the module (# 1) 310 returns to the state immediately before the calling process. On the other hand, if it is determined in step S306-2 that the value of the execution module identifier matches the value of the module identifier of module (# 1) 310, the process proceeds to step S306-3.
In this example, since the module identifier “# 1” is written in the execution module identifier field 182 of the secure shared area 181, it is determined that the value matches the module identifier of the module (# 1) 310. Therefore, since the post-switching processing unit 306 knows that the module (# 1) 310 should be executed, the process proceeds to step S306-3 and the post-switching process is continued.
In step S306-3, the post-switching processing unit 306A specifies the shared area number “# 1” and the module shared key Key_shared, and obtains a switching flag from the module switching management table 422. Also in this case, as described above, the module switching management unit 420 reads from the module switching management table 422 based on the determination result by the valid bit and the module shared key Key_shared for the entry indicated by the shared area number “# 1”. To control.
In this example, since the switching flag “ret” indicating “return” is written in the switching flag field 183 in step S304-6 of FIG. 25 as described above, it is determined that the value of the switching flag indicates “return”. It turns out that a function call is requested. Therefore, the process proceeds to step S306-7.
In step S306-7, the post-switching processing unit 306A obtains the caller address Addr1 stored in the above-described step S304-2 from the switching history area 118, and also stores the address stored in the switching history area 118. The address Addr1 is deleted. In the next step S306-8, the post-switching processing unit 306A specifies the shared area number “# 1” and the module shared key Key_shared, and obtains call return information from the switching parameter field 184 of the module switching management table 422. The module (# 1) 310 returns to the caller address Addr1 and resumes execution using the execution result “Result_1” included in the acquired call return information.
Thus, in the second embodiment, the module (# 1) 310 and the module (# 2) 320 share the module shared key, and the module switching management unit 420 uses the module shared key to store the module switching management table 422. Access control to the entry is performed. Thereby, reading / writing of the value written in the entry of the module switching management table 422 can be performed from the module (# 1) and the module (# 2) 320, and cannot be performed from the OS 180 and other modules. . As described above, the values written in the module switching management table 422 cannot be rewritten from the OS 180 or other modules modified by malicious intent. Therefore, it can be said that the module switching management unit 420 plays the same role as the secure shared area 181 of the first embodiment.
As illustrated in FIG. 27, when the return process is completed, the module switching management table 422 is written in the pre-switching process, that is, the steps S304-6, S304-7, and S304-9 in FIG. A switch flag “ret”, a switch parameter “Result_1”, and an execution module identifier “# 1” are stored. In the switching history area 118 of the module (# 1) 310, the caller address Addr1 is deleted in the post-switching process, that is, step S306-7 in FIG. 26, and nothing is saved. Similarly, in the switching history area 128 of the module (# 2) 120, the module identifier of the caller is deleted in the pre-switching process, that is, step S304-5, and nothing is stored.
In the second embodiment, the module switching management unit 420 is provided on the secure processor 400, but this is not limited to this example. That is, as illustrated in FIG. 28, a reliable virtual machine monitor (Trusted VMM) 440 can be configured to have a similar mechanism.
For example, the processor 450 may be a general processor that does not include the module switching management unit 420 unique to the second embodiment, and the module switching management unit 420 may be provided inside the virtual machine monitor 440. Each module (# 1) 310, module (# 2) 320, module (# 3) 330, and module (# 4) 340 use the module switching management unit 420 in the virtual machine monitor 440 to perform the second operation. Module switching can be performed in the same manner as in the embodiment. In the example of FIG. 28, a plurality of OSs (OS 180, OS_y 181 and OS_z 182) operate on the virtual machine monitor 440, and each module operates on the OS 180. Also, the module switching management unit 420 can be configured on the OS instead of hardware.
In the second embodiment, it has been described that all values in the module switching management table 422 are stored in the secure processor 400, but this is not limited to this example. That is, a part of the information of the module switching management table 422 is stored in the secure processor 400, and the remaining part is stored in the secure shared area 181 on the memory 280 shown in the first embodiment. You can also.
Furthermore, in the second embodiment, it has been described that reading / writing is performed in units of one field when accessing the module switching management table 422. However, this is not limited to this example. For example, a plurality of fields are read / written at once. You may do it.
Next, a third embodiment of the present invention will be described. In the first and second embodiments described above, a module is called by a general call process. On the other hand, the third embodiment is an example in which a module is called by a language exception.
Here, the language exception will be described. In the computer field, there are two types of exceptions: hardware exceptions and language exceptions. A hardware exception refers to an event such as a hardware interrupt or illegal instruction execution. A hardware exception is processed by a processor mechanism such as transferring control to an interrupt handler corresponding to the hardware exception.
On the other hand, the language exception refers to an exceptional event such as a file not being found, and the language exception is provided in a programming language environment such as C ++ or Java (registered trademark). The language exception is processed by a mechanism such as a library that traces the caller function from the function in which the language exception has occurred and transfers control to an exception handler corresponding to the language exception. In the third embodiment, the latter language exception is targeted.
A mechanism for handling such language exceptions is called a language exception handling mechanism. The language exception handling mechanism does not describe these processes in the callee function, but describes the process when a language exception occurs in the caller function, and executes error handling according to the caller function It is a mechanism to make it possible. Such a mechanism is described in, for example, “Design and Evolution of C ++” by “Bjarne Stroup”. In programming language environments such as C ++ and C #, it is described in the form of try to catch and is used in many applications, and its mechanism is well known.
FIG. 29 schematically shows an operation by the language exception handling mechanism 800. When a language exception occurs in a function in the module, the language exception handling mechanism 800 calls an exception handling library. First, the exception processing library searches for an exception handler corresponding to the generated language exception in the function in which the language exception has occurred. The search for the exception handler can be performed based on the type of the language exception that has occurred, for example. If a corresponding exception handler is found, control is transferred to the exception handler. If no exception handler is found, the function is rewound.
Function rewinding refers to processing to return to the caller function. Based on the frame information contained in the stack, etc., the stack is returned to the state before the call, the address of the caller is identified, and the address is returned to that address. Transfer control. When returning to the caller function, the exception handling library searches for an exception handler corresponding to the language exception. In this way, the exception processing library performs function rewind until an exception handler corresponding to the language exception is found, and goes back to the calling function.
In the example of FIG. 29, three modules # 1 to # 3 operate, and the modules are called in the order of module # 1, module # 2, and module # 3. This shows a case where a language exception occurs during execution of module # 3 and an exception handler that catches the language exception is in module # 1. The solid line in the figure indicates the flow of program execution, and the wavy line indicates the order of functions searched when the language exception handling mechanism 800 performs function rewinding.
When a language exception occurs in module # 3, the processing shifts to language exception processing mechanism 800. The language exception handling mechanism 800 first searches for an exception handler corresponding to the language exception with the function in the module # 3 in which the language exception has occurred. In this example, since no exception handler corresponding to the language exception is found, the function is rewound to return to the caller function in module # 3. Similarly, the caller function searches for an exception handler corresponding to the language exception. The language exception handling mechanism 800 repeats this until an exception handler corresponding to the language exception is found.
In the example of FIG. 29, the module # 3 returns to the module # 2, and the module # 2 searches for an exception handler. If no exception handler is found in module # 2, the process returns to module # 1 to search for an exception handler. In this example, by returning to the function of module # 1, an exception handler corresponding to the generated language exception is searched. When the exception handler is searched, the language exception handling mechanism 800 transfers the execution control to the searched exception handler.
Consider a case where the processing for a language exception by the language exception processing mechanism 800 is applied to the above-described first or second embodiment. In the secure processor, as described with reference to FIG. 3, each module manages the stack separately. Therefore, when the function is rewound in the module and when the function is rewound across the modules, Processing is different. When a function is rewound in a module, the function that called the function can be specified by examining the stack of the module as usual. On the other hand, when a function is rewound across modules, the function of the caller cannot be specified because another module cannot directly see the stack. Therefore, in the secure processor which is the premise of the present invention, when it is configured by a plurality of modules, the function rewinding of the conventional language exception handling mechanism 800 may not operate correctly.
FIG. 30 schematically shows a configuration of an example of a system applicable to the third embodiment of the present invention. FIG. 30 shows a schematic hardware configuration and a system view at the same time. In FIG. 30, the same reference numerals are given to the portions common to the configuration of FIG. 1 described above, and the detailed description is omitted.
Since the target system can apply the configuration described in FIG. 1 as it is in terms of hardware, description thereof is omitted here. In the target system, a single OS (Operating System) 180 operates on the core 210 of the secure processor 200, and one or more modules operate on the OS 180. In the example of FIG. 30, a plurality of modules (# 1) 510, module (# 2) 520, module (# 3) 530, and module (# 4) 540 are operating.
In the example of FIG. 30, the module (# 1) 510 has a task identifier “# 1” and is generated from the program A (Prg A). Module (# 2) 520 has a task identifier “# 2” and is generated from program B (Prg B). The module (# 3) 530 has a task identifier “# 3” and is generated from the program C (Prg C). The module (# 4) 540 has a task identifier “# 4” and is generated from the program B.
FIG. 31 is a functional block diagram illustrating an example of a module configuration according to the third embodiment. In FIG. 31, a module (# 1) 510, a module (# 2) 520, and a module (# 3) 530 operate in cooperation, and each includes the module switching mechanism according to the third embodiment. Here, it is assumed that module (# 1) 510 is an application module, and module (# 2) 520 and module (# 3) 530 are library modules.
The module (# 1) 510 includes an initialization processing unit 111, a program (# 1) main body 112, a pre-switching processing unit 104A, a post-switching processing unit 106A, and a switching history area 118 as in the configuration of FIG. Further, an exception notification unit 505A and an exception reception unit 507A are further provided. Similarly, the module (# 2) 520 includes an initialization processing unit 121, a program (# 2) main body 122, a pre-switching processing unit 104B, a post-switching processing unit 106B, and a switching history area 128. ) 510 further includes an exception notification unit 505B and an exception reception unit 507B that perform processing common to the exception notification unit 505A and the exception reception unit 507A. Further, the secure shared area 181 is shared on the memory 280 between the module (# 1) 510 and the module (# 2) 520 that cooperate with each other.
Further, although details are omitted in FIG. 31, the module (# 3) 530 also has the same configuration as the module (# 1) 510 and the module (# 2) 520. The module (# 3) 530 also shares the secure shared area 181 on the memory 280 with the module (# 1) 510 and the module (# 2) 520.
FIG. 32 schematically shows an example of processing when a language exception occurs between modules to which the third embodiment is applied. In FIG. 32, a long broken line shows an example of a flow of program execution generated by applying the third embodiment.
In the following, as illustrated in FIG. 32, the module (# 1) 510, the module (# 2) 520, and the module (# 3) 530 operate in association with each other, and the module (# 1) 510 to the module (# 2) 520 To call module (# 3) 530. In this case, a language exception occurs in the module (# 3) called from the module (# 2) 520, and the function is rewound from the module (# 3) 530 to the exception handler in the module (# 1) 510. Explained. Here, each module (# 1) 510, module (# 2) 520, and module (# 3) 530 have language exception handling mechanisms 800A, 800B, and 800C, respectively.
In the third embodiment, a process of rewinding a function across modules is realized by performing a process with some changes added to the switching process between modules shown in the first embodiment. As the initialization process, the same process as the process described with reference to FIGS. 7 and 8 in the first embodiment can be applied, and the description thereof is omitted here. By the initialization process, the module (# 1) 510, the module (# 2) 520, and the module (# 3) 530 can share the secure shared area 181 provided on the memory 280.
In the third embodiment, the process when calling another module from the module in the normal state where no language exception has occurred and the process when the module that called the other module returns are described above. Since the processing described with reference to FIGS. 6 to 10 in the first embodiment can be applied as it is, description thereof is omitted here.
Processing when performing function rewinding across modules according to the third embodiment will be described with reference to FIGS. 33 to 35. FIG. 33 is a flowchart showing an example of exception notification processing according to the third embodiment. FIG. 34 is a flowchart showing an example of exception reception processing according to the third embodiment.
FIG. 35 corresponds to FIG. 11 described above, and corresponds to the secure shared area 181 associated with the call processing and the return processing, the language exception notification processing, and the language exception reception processing when a language exception occurs, and each module ( The change in the state of the switching history area of # 1) 510, module (# 2) 520, and module (# 3) 530 is schematically shown.
The modules are sequentially called from the module (# 1) 510, and until the execution right is transferred to the module (# 3) 530, the secure shared area 181 is the same as described with reference to FIG. 11 in the first embodiment. And the state of each switching history area changes. In the example of FIG. 35, immediately after the initialization process, only the execution module identifier “# 1” is stored in the secure shared area 181. Also, nothing is stored in each switching history area.
When the module (# 2) 520 is called from this state, the execution module identifier “# 2” and the switching flag “call” are stored in the execution module identifier field 182 and the switching flag field 183 of the secure shared area 181, respectively. In addition, the function name “sub” and the argument “5” are stored as switching parameters in the switching parameter field 184. The switching history area 118 stores the caller address Addr1, and the switching history area 128 stores the module identifier “# 1”. Nothing is stored in the switching history area of the module (# 3) 530.
Further, when the module (# 3) 530 is called, the execution module identifier “# 3” and the switching flag “call” are stored in the execution module identifier field 182 and the switching flag field 183 of the secure shared area 181, respectively. At the same time, the function name “hello” is stored in the switching parameter field 184 as the switching parameter. The switching history area 118 has a caller address Addr1, the switching history area 128 has a module identifier “# 1” and the calling source address Addr2, and the module (# 3) 530 has a module identifier “# 2”. "Are stored respectively.
Referring to FIG. 33, when a language exception occurs in module (# 3) 530, control is transferred to language exception processing mechanism 800C included in module (# 3) 530 in the same manner as a normal language exception. The language exception handling mechanism 800C searches for an exception handler corresponding to the language exception from the function in which the language exception has occurred. As an example, the language exception handling mechanism 800C can search for an exception handler based on the type of the language exception that has occurred.
In the example of FIG. 32, the language exception handling mechanism 800C cannot find a corresponding exception handler from the function. Therefore, the language exception handling mechanism 800C executes function rewind, returns to the caller function in the module (# 3), and searches for the exception handler with the caller function. In this example, since no exception handler is found from this caller function, the language exception handling mechanism 800C transfers control to the exception notification unit of the module (# 3) 530. The exception notification unit 505 performs processing for returning to the module (# 2) 520 that is the caller of the module (# 3) 530.
In FIG. 33, in step S505-1, the exception notifying unit of the module (# 3) 530 switches from the switching history area of the module (# 3) 530 and saves the switching source (that is, the winding source). The module identifier “# 2” indicating the module of the return destination is obtained. Then, the module identifier “# 2” is deleted from the switching history area of the module (# 3) 530.
In the next step S505-2, the module (# 3) 530 indicates that the cause of switching to the module (# 2) 520 is “language exception” with respect to the switching flag field 183 in the secure shared area 181. Write a flag exception to indicate. In other words, this flag exception can be said to be a value indicating other than normal call or return.
In the next step S505-3, the module (# 3) 530 writes the language exception information excData in the switching parameter field 184 of the secure shared area 181. This language exception information excData includes the type of language exception, the content of the language exception, a message, and the like. That is, the language exception information excData is information indicating the content of the switching factor.
In the next step S505-4, the module (# 3) 530 writes the module identifier “# 2” indicating the rewind destination module in the execution module identifier field 182 of the secure shared area 181. Then, in the next step S505-5, the module (# 3) 530 stops the process immediately before the post-switching process and enters a sleep state in preparation for the re-calling.
When the module (# 3) 530 enters the sleep state in step S505-5, the execution right is switched to the OS 180. Thereafter, the execution right is transferred to the module (# 2) 520 by the scheduler of the OS 180, and the module (# 2) 520 resumes execution.
At this time, as illustrated in FIG. 35, in the secure shared area 181, the execution module identifier “# 2” written in the exception notification process and the switching flag “exception” (abbreviated as “exc” in FIG. 35). In addition, the switching parameter “excData” is stored. Further, the caller address Addr1 is stored in the switching history area 118, and the caller address Addr2 and the module identifier “# 1” are stored in the switching history area 128 of the module (# 2) 520, respectively. On the other hand, nothing is stored in the switching history area of the module (# 3) 530.
When the module (# 2) 520 receives an exception notification from the exception notification unit of the module (# 3) 530 by an interrupt or the like, the module (# 2) 520 transfers control to the exception reception unit 507B in the module (# 2) 520.
In FIG. 34, the exception receiving unit 507 obtains an execution module identifier from the execution module identifier field 182 of the secure shared area 181 (step S507-1). Then, in the next step S507-2, it is determined whether or not the value of the acquired execution module identifier matches the module identifier “# 2” of the module (# 2) 520. If it is determined that they do not match, the process proceeds to step S507-9, the module (# 2) 520 is put in the sleep state, and the next call is awaited. If there is a call, the process returns to step S507-1, and the process is resumed.
On the other hand, if it is determined in step S507-2 that the acquired execution module identifier value matches the module identifier “# 2” of the module (# 2) 520, the process proceeds to step S507-3. In this example, the execution module identifier “# 2” is stored in the module identifier field 182 of the secure shared area 181 and matches the module identifier “# 2” of the module (# 2) 520. It can be determined that the module (# 2) 520 should be executed, and the process proceeds to step S507-3.
In step S507-3, the module (# 2) 520 extracts the switching flag from the switching flag field 183 of the secure shared area 181. In the next step S507-4, the acquired switching flag value indicates a value “exception”. It is confirmed whether or not it is “exception”.
When it is confirmed that the value of the switching flag is “exception” indicating an exception, the module (# 2) 520 reads the saved caller address from the switching history area 128 in the next step S507-5. Addr2 is acquired, and the acquired caller address Addr2 is deleted from the switching history area 128.
In the next step S507-6, the module (# 2) 520 acquires the language exception information excData from the switching parameter field 184 of the secure shared area 181, and uses the value of the acquired language exception information excData to call A language exception is issued in a pseudo manner to the address Addr2.
When the language exception is issued, the module (# 2) 520 transfers control to the language exception processing mechanism 800B included in the module (# 2) 520. The language exception handling mechanism 800B searches for an exception handler corresponding to the generated language exception in the module (# 2) 520. If the exception handler is found, the processing by this exception handler is executed. On the other hand, when the exception handle is not found, the function is rewound. In this example, the language exception handling mechanism 800B cannot find an exception handler corresponding to the language exception in the module (# 2) 520, and therefore transfers control to the exception notification unit 505B.
Then, the exception notification unit 505B performs the module (# 2) 520 to the module (# 1) in the same manner as described above when the module (# 3) 530 notifies the module (# 2) 520 of the occurrence of the language exception. The occurrence of a language exception is notified to 510. When the occurrence of a language exception is notified to the module (# 1) 510, execution control is transferred to the module (# 1) 510, and a language exception is issued in a pseudo manner in the exception receiving unit 507A of the module (# 1) 510. Is done.
At this time, as illustrated in FIG. 35, the secure shared area 181 stores the execution module identifier “# 1”, the switching flag “exception”, and the switching parameter “excData” written in the exception notification process. Has been. Also, nothing is stored in the switching history area of each module.
When a language exception is issued, control is transferred to the language exception handling mechanism 800A included in the module (# 1) 510. The language exception handling mechanism 800A searches for an exception handler corresponding to the language exception as described above. If the corresponding exception handler is found by this search, control is transferred to the exception handler.
In this way, by adding language exception processing before and after switching modules, even if the module is protected between different modules and other modules cannot directly operate the context, Function rewinding processing in an exception can be realized.
In the third embodiment, the exception notification unit and the pre-switching processing unit have been handled separately, but this is not limited to this example, and the pre-switching processing unit is configured to include the function of the exception notification unit. You can also That is, in the pre-switching process, normal pre-switching process is performed in the case of normal calling, and processing by the function of the exception notification unit is performed in the case of calling by language exception.
Similarly, in the third embodiment, the exception receiving unit and the post-switching processing unit have been handled separately, but this is not limited to this example, and the post-switching processing unit includes the function of the exception receiving unit. It can also be configured. That is, in the post-switching processing unit, normal post-switching processing is performed in the case of normal calling, and processing of the exception receiving unit is performed in the case of calling by language exception.
In the third embodiment, each module is described as having a language exception handling mechanism, but this is not limited to this example. For example, the language exception handling mechanism may not be held in each module, but the language exception handling mechanism may be included in the platform executed by the module, and each module may generate and execute an instance thereof.
Furthermore, although the third embodiment has been described in which each module issues a language exception and calls the language exception handling mechanism in order to search for an exception handler, this is not limited to this example. For example, the exception receiving unit of each module may explicitly call and execute the language exception handling mechanism using an instruction such as a call instruction.
Next, a fourth embodiment of the present invention will be described. In the fourth embodiment, processing for a function setjmp and a function longjmp provided as a C library will be described. The function setjmp and the function longjmp are provided to realize a jumping mechanism outside the function.
FIG. 36 schematically shows an example of the operation according to the functions setjmp / longjmp. In the example of FIG. 36, three modules # 1 to # 3 operate and call modules in the order of module # 1, module # 2, and module # 3. The function setjmp is performed during the execution of the module # 1, and the function longjmp is performed during the execution of the module # 3.
The function setjmp holds context information such as a program counter and a stack pointer at the place where the function setjmp is executed. The function longjmp returns to the state immediately before the function setjmp is executed by using the context information stored by the function setjmp. In the example of FIG. 36, the state immediately before the function setjmp in the module # 1 is executed is saved by the function setjmp, and the state of the module # 1 is restored from the module # 3 to the module # 1 by the function longjmp. In this way, the mechanism for jumping out of the function is realized by acquiring the return destination context information and overwriting the current context with the context information.
In the secure processor which is the premise of the present invention, as described with reference to FIG. 3, each module manages the stack (context) separately, and thus jumps outside the function across the modules. Does not work properly.
This point will be described more specifically. In the case where the function setjmp / longjmp is performed in the module, the context information can be acquired with the function setjmp and switched to the context with the function longjmp as before. On the other hand, when the functions setjmp / longjmp are performed across a plurality of modules, if the context is managed separately between modules, the context of a module different from a certain module cannot be directly overwritten. Therefore, if it is assumed that context management is performed separately by modules, there is a case where it is not possible to switch to the context obtained by the function setjmp.
In addition, since the modules individually manage the context, when switching the context as in the function longjmp, the context is set to all the modules called from the module that executed the function setjmp until the function longjmp is executed. It is necessary to return to the state before executing setjmp. This is because if only the context of the module that executed the function setjmp is changed by the function longjmp, the other modules remain in the context of the state when the function longjmp is executed.
In the fourth embodiment, the functions setjmp / longjmp are realized between modules that manage contexts separately. In the fourth embodiment, context information is managed by a module identifier and a unique context number for each context, and direct exchange of context information between modules is not performed. Since the context information often includes information that should be concealed in other modules, a module identifier and a context number are used instead.
In the fourth embodiment using the secure processor, the current context information is registered and the context number indicating the context information is acquired by the context registration process corresponding to the function setjmp. The context in the registered context information is set by designating the module identifier and the context number by the context setting process corresponding to the function longjmp.
FIG. 37 shows a functional block diagram of an example of a module configuration according to the fourth embodiment of the present invention. Note that, in FIG. 37, the same reference numerals are given to the portions common to the configuration of FIG. 1 described above, and detailed description thereof is omitted. Note that the configuration described in FIG. 1 can be applied to the hardware configuration including the secure processor, and thus the description thereof is omitted here.
In FIG. 37, a module (# 1) 910 and a module (# 2) 920 each include a module switching mechanism according to the fourth embodiment. Here, it is assumed that module (# 1) 910 is an application module and module (# 2) 920 is a library module. The module (# 1) 910 and the module (# 2) 920 operate in cooperation with each other together with a module (# 3) 930 described later.
The module (# 1) 910 includes an initialization processing unit 111, a program (# 1) main body 912, a pre-switching processing unit 104A, and a switching history area 118 as in the configuration of FIG. A post-switching processing unit 906A that performs processing partially different from the processing unit 106A is provided. The module (# 1) 910 further includes a context change notification unit 905A, a context change reception unit 907A, and a context management table 919.
Similarly, the module (# 2) 920 includes an initialization processing unit 121, a program (# 1) main body 922, a pre-switching processing unit 104B, and a switching history area 128, and is part of the post-switching processing unit 106B of FIG. A post-switching processing unit 906B that performs different processes. The module (# 1) 910 further includes a context management table 929, and also includes a context change notification unit 905B and a context change that perform processing common to the context change notification unit 905A and the context change reception unit 907A of the module (# 1) 910. A reception unit 907B is provided.
The program (# 1) main body 912 that is an application module includes a context registration unit 908 and a context setting unit 909A. On the other hand, the module (# 2) 920 which is a library module includes a context setting unit 090B and does not include a context registration unit 908. The same applies to the module (# 3) 930 which is a library module. The context registration unit 908 corresponds to the function setjmp. The context setting unit 909A corresponds to the function longjmp.
Although details are omitted in FIG. 37, the module (# 3) 930 has the same configuration as the module (# 1) 910 and the module (# 2) 920. The module (# 1) 910, the module (# 2) 920, and the module (# 3) 930 share the secure shared area 181 on the memory 280.
FIG. 38 shows an example of the data configuration of the context management tables 919 and 929 and the context management table (not shown) of the module (# 3) 930. In the following, unless otherwise specified, the context management tables 919 and 929 and the context management table (not shown) of the module (# 3) 930 will be described as a representative context management table.
The context management table has n entries whose indexes indicating context numbers are “# 1” to “#n”. Each entry has a module identifier field and a context information field. In the context information field, a program counter, a stack pointer, and the like are stored as context information.
With reference to FIG. 39 to FIG. 44, processing for context registration / setting according to the fourth embodiment will be described. Here, context registration is executed by the module (# 1) 910, the module (# 2) 920 is called from the module (# 1) 910, and the module (# 3) 930 is called from the module (# 2) 920. An example in which context setting is executed by the module (# 3) 930 will be described. Note that the initialization processing of each module is the same as the processing according to the first embodiment described with reference to FIGS. 7 and 8, and thus detailed description thereof is omitted here.
FIG. 39 corresponds to FIG. 11 described above, and secure shared area 181 associated with execution of context registration / setting, and switching of each module (# 1) 910, module (# 2) 920, and module (# 3) 930 The change of the state of a history area is shown roughly. When the initialization process is completed, the execution module identifier “# 1” is stored in the execution module identifier field 182 in the secure shared area 181, and nothing is stored in the switching flag field 183 and the switching parameter field 184. Absent. Also, nothing is stored in the switching history area of each module (# 1) 910, module (# 2) 920, and module (# 3) 930.
The context registration process will be described. FIG. 40 is a flowchart showing an example of context registration processing according to the fourth embodiment. The module (# 1) 910 starts execution of the program (# 1) main body 912 and performs processing equivalent to the function setjmp, and the module (# 1) 910 transfers control to the context registration unit 908. In step S908-1, the context registration unit 908 acquires the current context information C in the same manner as the general function setjmp.
In the next step S908-2, the context registration unit 908 determines the context number “#m” of an empty entry in the context management table 919. The determined context number “#m” is returned to the module (# 1) 910. Then, the context registration unit 908 stores the context information C acquired in step S908-1 in the context information field in the entry of the context number “#m” in the context management table 919.
In general functions setjmp / longjmp, a context is directly passed to another module. In contrast, in the fourth embodiment, the context is managed by the context management table, and context setting information is passed to other modules. The context setting information here refers to a module identifier for identifying a module from which the context is derived and the contest number determined by the context registration unit 908 when the context information is registered in the context management table.
In the fourth embodiment, when each module sets a context, the context setting information is specified instead of specifying the context information directly.
Next, module call processing will be described. After the context registration is completed in the module (# 1) 910, the module (# 2) 920 is called from the module (# 1) 910, and further, the module (# 3) 930 is called from the module (# 2) 920. Since the processing by the switching pre-processing unit 104A is the same as the processing described with reference to FIG. 9, detailed description thereof is omitted here.
As a result of the pre-switching process, the caller address Addr1, the switch flag “call” indicating the call process, the execution module identifier “# 2” indicating the execution module, the secure shared area 181 also includes the caller address field Addr1, the switch flag It is written in the field 183 and the execution module identifier field 182, respectively.
As the switching parameter, the function name “sub” and the argument “5” of the call destination function are written in the switching parameter field 183 of the secure shared area 181. In the fourth embodiment, the context setting information, that is, the module identifier “# 1” indicating the module for which context registration has been executed, and the context number “#m” are the switching parameters of the secure shared area 181. Written to Lafield 183. As a result, the context setting can be executed in the called module.
These module identifier “# 1” and context number “#m” are sequentially passed to the called module by the pre-switching process and the post-switching process.
FIG. 41 is an example flowchart illustrating post-switching processing according to the fourth embodiment. In FIG. 41, the processes common to those in FIG. 10 described above are denoted by the same reference numerals, and detailed description thereof is omitted. When the module (# 2) 920 is called from the module (# 1) 910, the post-switching processing unit 906B of the module (# 2) 920 indicates that the value of the execution module identifier field 182 of the secure shared area 181 is “# 2”. It is confirmed (step S106-1, step S106-2).
Next, the post-switching processing unit 106B obtains a switch flag from the switch flag field 183 of the secure shared area 181 (Step S106-3). The post-switching processing unit 106B finds that a function call is requested from the acquired value “call” (step S106-4). Then, the post-switching processing unit 106B extracts the module identifier “# 1” from the switching source module identifier field 185 in step S106-5 and stores it in the switching history area 118.
In the next step S106-6, the post-switching processing unit 106B obtains the function name “sub” written as call information and the argument “5” from the switching parameter field 184 of the secure shared area 181 and registers the context. The module identifier “# 1” and the context number “#m” indicating the module for which the process has been executed are obtained.
In the next step S906-7, the post-switching processing unit 906B determines whether or not the acquired switching parameter includes context setting information. If it is determined that it is not included, the process proceeds to step S906-9. On the other hand, if it is determined that it is included, the process proceeds to step S906-8. In step S906-8, the post-switching processing unit 906B stores, in the context management table 929, each piece of information included in the context setting information among the switching parameters acquired in step S106-6 in FIG.
More specifically, in step S906-8, the module identifier and context number included in the context setting information are stored in the context management table 929. At the same time, the context information for returning to the calling module by the context setting process described later is stored in the context information field of the context management table 929. This context information is used by a context change notification process described later.
At this time, as illustrated in FIG. 39, the secure shared area 181 stores the execution module identifier “# 2” and the switching flag “call” written in the pre-switching process. At the same time, the function name “sub” and the argument “5”, the module identifier “# 1”, and the context number “#m” are stored in the secure shared area 181 as switching parameters. The caller address Addr1 is stored in the switching history area 118 of the module (# 1) 910, and the module identifier “# 1” is stored in the switching history area 128 of the module (# 2) 920.
In the next step S906-9, the post-switching processing unit 906B executes the program (# 2) based on the function name “sub” of the call destination and the argument “5” among the switching parameters acquired in step S106-6. The execution of the function “sub” in the main body 122 is started.
The same processing is performed when calling the module (# 3) 930 from the module (# 2) 920. When the call up to the module (# 3) 930 is completed, the context management tables of the module (# 1) 910, the module (# 2) 920, and the module (# 3) 930 have the module identifier “# 1” and the context number “#”. The entry “m” is included.
The context management table 919 stores context information at the time when context registration is performed according to the processing shown in FIG. Further, the context management table 929 and the context management table of the module (# 3) 930 each include context information for returning to the calling module.
At this time, as illustrated in FIG. 39, the secure shared area 181 stores the execution module identifier “# 3” and the switching flag “call” written in the pre-switching process. At the same time, the secure shared area 181 stores a function name “hello”, a module identifier “# 1”, and a context number “#m” as switching parameters. In the switching history area 128 of the module (# 2) 920, the module identifier “# 1” and the caller address Addr2 are stored. The module identifier “# 2” is stored in the switching history area of the module (# 3) 930. In the switching history area 118 of the module (# 1) 910, the caller address Addr1 is stored.
Next, the context setting process will be described. In this example, the context setting process is executed in the module (# 3) 930, as illustrated in FIG.
FIG. 42 is a flowchart illustrating an exemplary context setting process according to the fourth embodiment. In step S909-1, the context setting unit of the module (# 3) 930 receives the module identifier “# 1” included in the context setting information in the switching parameter acquired from the secure shared area 181 in step S106-5 in FIG. Based on the context number “#m”, the context management table of the module (# 3) 930 is referred to. Then, context information corresponding to the module identifier “# 1” and the context number “#m” is acquired. At the same time, the context information is deleted from the context management table.
In the next step S909-2, the context setting unit of the module (# 3) 930 overwrites the current context information in the module (# 3) 930 with the context information acquired in step S909-1. In this case, the context information acquired in step S909-1 is for returning to the module (# 2) 920 that is the caller of the module (# 3) 930. Therefore, the module (# 3) 930 transfers control to the context change notification unit of the module (# 3) 930.
FIG. 43 is a flowchart illustrating an exemplary context change notification process according to the fourth embodiment. In step S 905-1, the context change notification unit, from the switching history area of the module (# 3) 930, stores the module identifier “indicating the module of the caller stored when the module (# 2) 920 is called. "# 2" is extracted, and the acquired module identifier is deleted from the switching history area.
In the next step S905-2, the context change notification unit of the module (# 3) 930 indicates to the switching flag field 183 of the secure shared area 181 the switching flag “Context setting” indicating that the cause of module switching is “context setting”. Lj "is written. In other words, the switching flag “Lj” can be said to be a value indicating other than normal call, call return, or language exception. Further, in step S905-3, the context change notification unit writes the module identifier “# 1” and the context number “#m” as context setting information in the switching parameter field 184. In other words, this context setting information can be said to be information indicating the cause of module switching.
In the next step S905-4, the context change notification unit of the module (# 3) 930 writes the module identifier “# 2” indicating the calling source module in the execution module identifier field 182 of the secure shared area 181. Further, the context change notification unit of module (# 3) 930 sets module (# 3) 930 to the sleep state in step S905-6. By preparing the sleep state immediately before the post-switching process and stopping the process, it prepares for a call again.
At this time, as illustrated in FIG. 39, the secure shared area 181 stores the execution module identifier “# 2” and the switching flag “Lj” written in the context change notification process, and also includes the switching parameter. The module identifier “# 1” and the context number “#m” are stored. Further, the caller address Addr1 is stored in the switching history area 118 of the module (# 1) 910, and the caller address Addr2 is stored in the switching history area 128 of the module (# 2) 920. On the other hand, nothing is stored in the switching history area of the module (# 3) 930.
When the module (# 3) 930 enters the sleep state in step S905-5, the execution right is switched to the OS. Thereafter, the execution right is transferred to the module (# 2) 920 by the scheduler of the OS, and the module (# 2) 920 resumes execution. When the execution is resumed and the module (# 2) 920 receives the change notification from the context change notification unit of the calling module (# 3) 930, the module (# 2) 920 transfers the control to the context change reception unit 907B.
FIG. 44 is a flowchart showing an example of context change acceptance processing according to the fourth embodiment. In step S907-1, the context change receiving unit 907B obtains an execution module identifier from the execution module identifier field 182 of the secure shared area 181. In the next step S907-2, the context change accepting unit 907B determines whether or not the acquired execution module identifier value matches the module identifier “# 2” of the module (# 2) 920. If it is determined that they do not match, the process proceeds to step S907-9, the module (# 2) 920 is set in the sleep state, and the next call is awaited. If there is a call, the process returns to step S907-1, and the process is resumed.
On the other hand, if it is determined in step S907-2 that the acquired execution module identifier value matches the module identifier “# 2” of the module (# 2) 920, the process proceeds to step S907-3. In this example, the execution module identifier “# 2” is stored in the module identifier field 182 of the secure shared area 181, and this matches the module identifier “# 2” of the module (# 2) 920. Therefore, it can be determined that module (# 2) 920 should be executed, and the process proceeds to step S907-3.
In step S907-3, the context change accepting unit 907B extracts the switch flag from the switch flag field 183 of the secure shared area 181, and in the next step S907-4, the acquired switch flag value is “context”. It is confirmed whether or not the value is “Lj” indicating “setting”. If it is confirmed that the value of the switching flag is the value “Lj”, the process proceeds to step S907-5.
In step S907-5, the context change accepting unit 907B acquires context setting information from the switching parameter field 184 of the secure shared area 181. Thereafter, the control is transferred to the context setting unit 909B.
Referring to FIG. 42, in step S909-1, the context setting unit 909B includes the module identifier “# 1” and the context number “#m” included in the context setting information in the switching parameters stored in the secure shared area 181. Based on the above, the context management table 929 is referred to. Then, context information corresponding to the module identifier “# 1” and the context number “#m” is acquired. At the same time, the context information is deleted from the context management table.
In the next step S909-2, the module (# 2) 920 is information for returning the context information acquired in step S909-1 to the module (# 1) 910 that is the caller of the module (# 2) 920. Therefore, control is transferred from the context setting unit 909B to the context change notification unit 905B.
Referring to FIG. 43, context change notification section 905B performs the same process as the process performed by the context change notification section of module (# 3) 930 described above, and switches flag “ Lj ”, a module identifier“ # 1 ”and a context number“ #m ”for the switching parameter field 184, a module identifier“ # 1 ”indicating the calling module for the execution module identifier field 182, Write each one. Then, the context change notification unit 905B puts the module (# 2) 920 in the sleep state (see step S905-1 to step S905-6 in FIG. 43).
At this time, as illustrated in FIG. 39, the secure shared area 181 stores the execution module identifier “# 1” and the switching flag “Lj” written in the context change notification process, and also includes the switching parameter. The module identifier “# 1” and the context number “#m” are stored. Also, the caller address Addr1 is stored in the switching history area 118 of the module (# 1) 910. On the other hand, nothing is stored in the switching history area of other modules.
When the module (# 2) 920 enters the sleep state, the execution right is switched to the OS. Thereafter, the execution right is transferred to the module (# 1) 910 by the OS scheduler or the like, and the module (# 1) 910 resumes execution. When the module (# 1) 910 resumes execution and receives a change notification from the context change notification unit of the caller module (# 2) 920, the control is transferred to the context change reception unit 907A.
The context change accepting unit 907A performs the same processing as the context change accepting unit 907B of the module (# 2) 920 described above. Referring to FIG. 44, the context change accepting unit 907A confirms that the value of the execution module identifier field 182 of the secure shared area 181 is “# 1” (steps S907-1 and S907-2).
Next, the context change accepting unit 907B acquires a switching flag from the switching flag field 183 of the secure shared area 181 and the value of the acquired switching flag is “Lj” indicating that the cause of module switching is “context setting”. (Step S907-3, step S907-4).
In the next step S907-5, the context change accepting unit 907A obtains the context setting information included in the switching parameter from the switching parameter field 184 of the secure shared area 181 and acquires the module identifier and the context number from the context setting information. . Then, the module identifier and the context number acquired from the context setting information are designated, and control is transferred to the context setting unit 909A.
Referring to FIG. 42, in step S909-1, the context setting unit 90A includes the module identifier “# 1” and the context number “#m” included in the context setting information in the switching parameters stored in the secure shared area 181. The context management table 919 is referred to based on the above. Then, the context information corresponding to the module identifier “# 1” and the context number “#m” is acquired from the context management table 919, and the context information is deleted from the context management table.
The context information acquired in step S909-1 is the place where the context is registered by the context registration process in the module (# 1) 910. Therefore, in the next step S909-2, the module (# 1) 910 returns to the place where the execution position is registered in the context registration process, and resumes execution.
As described above, in the module in which context registration has been performed, context information at the time of context registration is stored. In modules other than context registration, a value for context setting is written, and context information in the pre-switching process when switching execution to the caller is saved. As a result, when returning by context setting, it is possible to return to the location where the context is registered by simply overwriting with the context information stored in the context management table.
In the fourth embodiment, the context change notification unit and the pre-switching processing unit have been handled separately, but this is not limited to this example, and the pre-switching processing unit includes the function of the context change notification unit. It can also be configured. That is, in the switching processing unit, normal switching pre-processing is performed in the case of a normal call, and processing by the function of the context change notification unit is performed in the context setting.
Similarly, in the fourth embodiment, the context change accepting unit and the post-switching processing unit have been handled separately, but this is not limited to this example, and the post-switching processing unit has the function of the context change accepting unit. It can also be configured to include. That is, in the post-switching processing unit, normal post-switching processing is performed in the case of a normal call, and in the context setting, processing by the function of the context change receiving unit is performed.
In the fourth embodiment, the context management table is described as being held in units of modules. However, this is not limited to this example. For example, a context management table can be provided in an area shared between cooperating modules as in the secure shared area. Furthermore, in the fourth embodiment, the context information is managed by the module identifier and the context number, but this is not limited to this example. That is, the module identifier and the context number may be a method having one unique value between modules.
Next, a fifth embodiment of the present invention will be described. The fifth embodiment is a modified example of the processing for the function setjmp and the function longjmp provided as the C library of the fourth embodiment described above. Here, as described above, an example will be described in which a context is registered with module # 1 that is an application module, and a context is set with module # 3 via module # 2 that is a library module.
In the fifth embodiment, the context information is managed by the module identifier and the context number as in the fourth embodiment. In the fifth embodiment, the context number indicating the context information is acquired by the context registration process corresponding to the function setjmp, the module identifier and the context number are specified by the context setting process corresponding to the function longjmp, and the context is set. Switch.
FIG. 45 shows a functional block diagram of an example of a module configuration according to the fifth embodiment of the present invention. In FIG. 45, the same reference numerals are given to portions common to the configuration of FIG. 37 described above, and detailed description thereof is omitted. Note that the configuration described in FIG. 1 can be applied to the hardware configuration including the secure processor, and thus the description thereof is omitted here.
In FIG. 45, a module (# 1) 710 and a module (# 2) 720 each include a module switching mechanism according to the fifth embodiment. Here, it is assumed that the module (# 1) 710 is an application module and the module (# 2) 720 is a library module. Module (# 1) 710 and module (# 2) 720 operate in cooperation with each other together with module (# 3) 730 described later.
The module (# 1) 710 includes an initialization processing unit 111, a program (# 1) main body 712, a pre-switching processing unit 104A, a post-switching processing unit 706A, a switching history area 118, a context change notification unit 905A, and a context change receiving unit 907A. And a context management table 719. The program (# 1) main body 712 includes a context registration unit 908 and a context setting unit 702A. The context registration unit 908 corresponds to the function setjmp, and the context setting unit 702A corresponds to the function longjmp.
Among these, the context setting unit 702A and the context management table 719 respectively correspond to the context setting unit 902A and the context management table 919 in the fourth embodiment described with reference to FIG.
Similarly, the module (# 2) 720 includes an initialization processing unit 121, a program (# 1) main body 722, a pre-switching processing unit 104B, a post-switching processing unit 106B, a switching history area 128, a context change notification unit 905B, and a context change. A reception unit 907B and a context management table 729 are provided. Further, the program (# 1) main body 722 includes a context setting unit 702B. The context setting unit 702B corresponds to the function longjmp.
Similar to the module (# 1) 710 described above, the context setting unit 702B and the context management table 729 are the context setting unit 902B and the context management table 929 in the fourth embodiment described with reference to FIG. And some functions are different.
Although details are omitted in FIG. 45, the module (# 3) 730 also has the same configuration as the module (# 2) 720, and the program (# 3) body has a context setting unit (not shown). . The module (# 1) 710, the module (# 2) 720, and the module (# 3) 730 share the secure shared area 181 as, for example, the area Sh_mem1 on the memory 280.
FIG. 46 shows an example of the data configuration of the context management tables 719 and 729 and the context management table (not shown) of the module (# 3) 730. In the following, unless otherwise specified, the context management tables 719 and 729 and the context management table (not shown) of the module (# 3) 730 will be described as a representative context management table.
The context management table has n entries whose indexes indicating context numbers are “# 1” to “#n”. Each entry has a context information field. In the context information field, a program counter, a stack pointer, and the like are stored as context information.
Processing when performing context registration / setting according to the fifth embodiment will be described with reference to FIGS. 43, 44, 47, and 48. Here, context registration is executed by the module (# 1) 710, the module (# 2) 720 is called from the module (# 1) 710, and the module (# 3) 730 is called from the module (# 2) 720. An example in which context setting is executed by the module (# 3) 730 will be described. Note that the initialization processing of each module is the same as the processing according to the first embodiment described with reference to FIGS. 7 and 8, and thus detailed description thereof is omitted here.
47 corresponds to FIG. 11 described above, and the secure shared area 181 associated with execution of context registration / setting, and switching of each module (# 1) 710, module (# 2) 720, and module (# 3) 730 The change of the state of a history area is shown roughly. When the initialization process is completed, the execution module identifier “# 1” is stored in the execution module identifier field 182 in the secure shared area 181, and nothing is stored in the switching flag field 183 and the switching parameter field 184. Absent. Also, nothing is stored in the switching history area of each module (# 1) 710, module (# 2) 720, and module (# 3) 730.
First, a context registration process is performed in the module (# 1) 710 which is an application module. This context registration process is performed by the same procedure as the context registration process according to the fourth embodiment described with reference to FIG. At this time, the context when the context registration process is executed is registered for the entry (#m) of the context management table 719.
After the context registration is completed in the module (# 1) 710, the module (# 2) 720 is called from the module (# 1) 710, and further, the module (# 3) 730 is called from the module (# 2) 720. Processing by the switching pre-processing unit 104A when calling the module (# 2) 720 from the module (# 1) 710 and processing by the pre-switching processing unit 104B when calling the module (# 3) 730 from the module (# 2) 720 Since the processing is the same as the processing described with reference to FIG. 7, detailed description thereof is omitted here.
As a switching parameter, the function name “sub” of the callee function and the argument “5” write the secure shared area 181 to the switching parameter field 183 as well. In the fifth embodiment, the context setting information, that is, the module identifier “# 1” indicating the module for which context registration has been executed, and the context number “#m” are the switching parameters of the secure shared area 181. Written to Lafield 183. As a result, the context setting can be executed in the called module.
When the pre-switching process in the pre-switching processing unit 104A or the pre-switching processing unit 104B is completed, the call destination module is called and the module to be executed is switched. When control is transferred to the called module, post-switching processing is performed in the module. The post-switching process is not different from the process described as being the same as the process according to the first embodiment in FIG. 41 in the above-described fourth embodiment, and thus detailed description thereof is omitted here.
Changes in the state of the secure shared area 181 and the switching history area of each module accompanying the module call processing will be described with reference to FIG. When the control is switched from the module (# 1) 710 to the module (# 2) 720 and the post-switching process is completed in the module (# 2) 720, the execution module identifier “# 2” and the secure shared area 181 A switching flag “call” is stored. At the same time, the function name “sub” and the argument “5”, the module identifier “# 1”, and the context number “#m” are stored in the secure shared area 181 as switching parameters. In addition, the caller address Addr1 is stored in the switching history area 118 of the module (# 1) 710, and the module identifier “# 1” is stored in the switching history area 128 of the module (# 2) 720.
Also, when the control is switched from the module (# 2) 720 to the module (# 3) 730 and the post-switching process is completed in the module (# 3) 730, the execution module identifier “# 3” and The switching flag “call” is stored. At the same time, the function name “hello”, the module identifier “# 1”, and the context number “#m” are stored in the switching parameters of the secure shared area 181. Further, the module identifier “# 1” and the caller address Addr2 are stored in the switching history area 128 of the module (# 2) 720. The module identifier “# 2” is stored in the switching history area of the module (# 3) 730. In the switching history area 118 of the module (# 1) 710, the caller address Addr1 is stored.
At this time, the context management table 719 of the module (# 1) 710 is in a state in which an entry of the context number “#m” is included. On the other hand, the context management tables of the module (# 2) 720 and the module (# 3) 730 are in a state of containing nothing. The fifth embodiment is different from the fourth embodiment described above in this point.
Next, context setting processing according to the fifth embodiment will be described. In this example, as illustrated in FIG. 36, a context setting process is executed in the module (# 3) 730.
FIG. 48 is an example flowchart illustrating a context setting process according to the fifth embodiment. First, the context setting unit of the module (# 3) 730 executes a context setting process using the context setting information (module identifier and context number) passed from the calling module via the secure shared area 181. . First, in step S707-1, it is determined whether or not the value of the module identifier matches the value of the module identifier indicating its own module. If it is determined that the value of the module identifier matches the value of the module identifier indicating its own module, the process proceeds to step S707-2.
In step S707-2, context information corresponding to the context number is acquired, and the context information is deleted from the context management table. Then, in the next step S707-3, the context setting unit of the module (# 3) 730 overwrites the current context information in the module (# 3) 730 with the context information acquired in step S707-1.
On the other hand, if it is determined in step S707-1 that the module identifier does not indicate its own module, the process proceeds to step S707-4. In this case, it can be determined that it is necessary to return to the calling module. Therefore, in step S707-4, the context setting unit of module (# 3) 730 returns the context such as the stack of module (# 3) 730 to the state immediately after switching. Then, the control is transferred to the context change notification unit of the module (# 3) 730.
In this example, since the module identifier “# 1” is different from the module identifier “# 3” indicating its own module, the process proceeds to step S707-4, and the context such as the stack of the module (# 3) 730 is changed. Return to the state before switching. Then, control is transferred to the context change notification unit of the module (# 3). Since the process by the context change notification unit of module (# 3) 730 is the same as the process by the context change notification unit according to the fourth embodiment described with reference to FIG. 43, the description thereof is omitted here.
At this time, as illustrated in FIG. 47, the secure shared area 181 stores the execution module identifier “# 2” and the switching flag “Lj” written in the context change notification process, and also includes the switching parameter. The module identifier “# 1” and the context number “#m” are stored. Further, the caller address Addr1 is stored in the switching history area 118 of the module (# 1) 710, and the module identifier “# 1” of the caller is stored in the switching history area 128 of the module (# 2) 720. . On the other hand, nothing is stored in the switching history area of the module (# 3) 730.
When the module (# 3) 730 enters the sleep state (see step S905-5 in FIG. 43), the execution right is switched to the OS. Thereafter, the execution right is transferred to the module (# 2) 720 by the scheduler of the OS or the like, and the module (# 2) 720 resumes execution. When the execution is resumed and the module (# 2) 720 receives the change notification from the context change notification unit of the calling module (# 3) 730, the module (# 2) 720 transfers the control to the context change reception unit 907B.
Since the process by the context change accepting unit 907B is the same as the process by the context change accepting unit according to the fourth embodiment described with reference to FIG. 44, the description thereof is omitted here. Finally, the context change notification unit 907B designates the context setting information included in the acquired switching parameter, and transfers control to the context setting unit 702B (see step S907-5 in FIG. 44).
Referring to FIG. 48, in step S707-1, the context setting unit 702B has a module identifier acquired from the switching parameter acquired by the context change receiving unit 907B as the value “# 1”, and indicates a module identifier indicating its own module. Is the value “# 2” and the two do not match, the process proceeds to step S707-4.
In step S707-4, the context setting unit 702B returns the context such as the stack of the module (# 2) 720 to the state immediately after switching. Then, the control is transferred to the context change notification unit 905B of the module (# 2) 720. Since the process by the context change notification unit 905B is the same as the process by the context change notification unit according to the fourth embodiment described with reference to FIG. 43, the description thereof is omitted here.
At this time, as illustrated in FIG. 47, the secure shared area 181 stores the execution module identifier “# 1” and the switching flag “Lj” written in the context change notification process, and also the switching parameter. The module identifier “# 1” and the context number “#m” are stored. Also, the caller address Addr1 is stored in the switching history area 118 of the module (# 1) 710. On the other hand, nothing is stored in each switching history area of the module (# 2) 720 and the module (# 3) 730.
When the module (# 2) 720 enters the sleep state (see step S905-5 in FIG. 43), the execution right is switched to the OS. Thereafter, the execution right is transferred to the module (# 1) 710 by the scheduler of the OS, and the module (# 1) 710 resumes execution. When the module (# 1) 710 resumes execution and receives a change notification from the context change notification unit of the calling module (# 2) 720, the module (# 1) 710 transfers control to the context change reception unit 907A.
The processing by the context change accepting unit 907A is the same as the processing by the context change accepting unit according to the fourth embodiment described with reference to FIG. 44, and thus description thereof is omitted here. Finally, the context change notification unit 907A designates the context setting information included in the acquired switching parameter, and transfers control to the context setting unit 702A (see step S907-5 in FIG. 44).
Referring to FIG. 48, the context setting unit 702A determines that the module identifier value included in the context setting information passed from the caller module via the secure shared area 181 is the module identifier value indicating its own module. It is determined whether or not they match. In this case, since the module identifier included in the context setting information is the value “# 1” and the module identifier indicating the module (# 1) 710 is the value “# 1”, the two match. Therefore, the context setting unit 702A can determine that it should return to the time of context registration issued in its own module.
The processing moves to step S707-2, where the context setting unit 702A extracts the context number from the context setting information, and acquires context information corresponding to the acquired context number from the context management table 919. Then, the context setting unit 702A deletes the acquired context information from the context management table 919. Then, in the next step S707-3, the context setting unit 702A overwrites the current context information in the module (# 1) 710 with the context information acquired in step S707-2, and the location where the context registration is performed Return to.
As described above, in the fifth embodiment, in context registration, a module identifier and a context number are provided as context setting information instead of a context. Then, in the context setting, the module identifier and the context number included in the context setting information provided by the context registration are specified, and the process returns to the caller in order. As a result, a function corresponding to the functions setjmp / longjmp can be realized even between modules that have individual contexts and are protected.
In the fifth embodiment, the context change notification unit and the pre-switch processing unit have been handled separately. However, this is not limited to this example, and the pre-switch processing unit includes the function of the context change notification unit. It can also be configured. That is, in the switching processing unit, normal pre-switching processing is performed in the case of a normal call, and context change notification processing is performed in the context setting.
In the fifth embodiment, the context change accepting unit and the post-switching processing unit have been handled separately, but the post-switching processing unit may be configured to include the function of the context change accepting unit. That is, in the post-switching processing unit, normal switching is performed in the case of a normal call, and processing by the function of the context change receiving unit is performed in the context setting.
In the fifth embodiment, the context management table is described as being held in units of modules, but this is not limited to this example. For example, a context management table can be provided in an area shared between cooperating modules as in the secure shared area.
In the fifth embodiment, the context information is managed by the module identifier and the context number. However, this is not limited to this example. That is, the module identifier and the context number only need to have unique values between modules, and a method without two numbers is conceivable. For example, in the initialization process, a range of context numbers used between modules is determined, module # 1 uses context numbers # 1 to # 100, module # 2 uses context numbers # 101 to # 200, and contexts A method using only the number is conceivable.
Further, the context number used by each module may be determined not only by the initialization process, but also by adjusting the context number so as not to collide with the context number used by each module. .
<Other correspondence of each embodiment>
According to another correspondence of each of the above-described embodiments, the program is called when the switching factor is due to a call immediately before the first processing step switches the operation from its own module to another module. The original address is stored in the switching history area, and if the switching flag indicates call return immediately after the second processing step is switched from another module, the caller address is changed from the switching history area. Obtaining and resuming execution from that address.
The program is characterized in that the initialization step determines the module identifier using a task identifier for the microprocessor to identify the module.
In addition, the program is characterized in that the initialization step determines the identifier of the module using a random number and confirms that the identifier does not overlap between the cooperating modules.
In addition, immediately before the first processing step switches from the own module to another module, the program specifies the shared key, encrypts the switching flag and the switching parameter, and stores them in the shared area. Immediately after switching from another module to its own module, the switching flag and the switching parameter stored in the shared area by specifying the shared key are decrypted, and the own module according to the decrypted switching flag and switching parameter It is characterized in that the functions within are executed.
In addition, a shared area and an access control unit that controls access to the shared area are provided on the microprocessor, and a program accesses the shared area via the access control unit.
Also, a shared area and an access control unit that controls access to the shared area are provided on a virtual machine monitor that operates on a microprocessor and operates a plurality of linked modules, and the program is accessed from the virtual machine monitor. The shared area is accessed through the network.
104A, 104B, 104C Pre-switching processing unit 106A, 106B, 106C, 906A, 906B Post-switching processing unit 111, 121 Initialization processing unit 112, 912 Program (# 1) main body 110, 310, 510, 710, 910 Module (# 1)
118, 128 switching history area 120, 320, 520, 720, 920 module (# 2)
122,922 program (# 2) main body 130,330,530,730,930 module (# 3)
140, 340, 540, 740, 940 Module (# 4)
181 Secure shared area 182 Execution module identifier field 183 Switch flag field 184 Switch parameter field 185 Switch source module identifier 190 Shared area 200, 400 Secure processor 210, 410 Core 212, 412 Current task identifier register 220 Encryption / decryption manager 222 Key table 224 Selector 226 Encryption / decryptor 280 Memory 420 Module switching management unit 422 Module switching management table 424 Table access control unit 505A, 505B Exception notification unit 507A, 507B Exception receiving unit 702A, 702B, 909A, 909B Context setting unit 905A, 905B Context change Notification unit 907A, 907B Context change reception unit 719, 729, 919, 929 Context management table Le 908 context registration unit
A program including a plurality of modules for causing a computer to execute,
An area that is accessible only to modules that operate in association with each other, and includes a memory including a shared area that stores an execution module identifier indicating an identifier of a module that operates on the OS among the modules operating in association with each other;
Each of the modules is
A first processing step of storing an identifier of the other module in the shared area as the execution module identifier immediately before switching the operation to another module to be linked;
Immediately after the operation is switched from the other module, when the execution module identifier stored in the shared area matches the identifier of the own module, the function in the own module is executed. A program comprising two processing steps.
The first processing step includes
Storing at least a switching flag indicating a factor of the switching and a switching parameter including information necessary for the switching in the shared area;
The second processing step includes
The program according to claim 1, wherein a function in the own module is executed according to the switching flag and the switching parameter stored in the shared area.
When the switching factor is a call, the switching flag indicating the call and the switching parameter including at least call information indicating a call position in the other module where the switching is performed by the call are shared. Store in the area,
3. The program according to claim 2, wherein when the switching flag indicates the call, the calling is performed in the own module according to the call information included in the switching parameter.
When the switching factor is a return from a call, the switching parameter including at least the switching flag indicating the return, and the switching parameter including at least the call return information indicating the execution result of the own module that has been switched due to the call; In the shared area,
4. When the switch flag indicates the return, the self-module returns to the position where the call is made using the call return information included in the switch parameter and resumes execution. The program described in.
Immediately before switching the operation to another module to be linked, when the switching factor is other than the call or the return, the switching flag indicating other than the call or the return and the content of the switching factor are indicated. A third processing step of storing the switching parameter including at least switching factor information in the shared area;
Immediately after the operation is switched from the other module, when the switching flag indicates other than the call or return, the processing corresponding to the factor indicated by the switching factor information included in the switching parameter is executed. The program according to claim 4, further comprising a fourth processing step.
The third processing step includes
When the switching factor is a language exception, the switching flag indicating the language exception and the switching parameter including at least language exception information necessary for notifying the language exception are stored in the shared area,
The fourth processing step includes
6. The program according to claim 5, wherein when the switching flag indicates the language exception, a language exception is generated for the module using the language exception information included in the switching parameter.
The context corresponding to the context number specified by the other module from the management table that manages the identifier, the context number unique to each context, and the context information indicating the context in one-to-one correspondence Further comprising a setting step of acquiring information and replacing the current context of the module with the acquired context information;
When the switching factor is context setting, immediately before the switching is performed, the context information corresponding to the identifier and the context number is deleted from the management table, and the switching flag indicating the context setting And the switching parameter including at least context setting information indicating the context set by the setting step in the shared area,
Immediately after the switching is performed, when the switching flag indicates the call and the switching parameter includes the context setting information, the identifier indicating the other module and the other module are designated. The context number and context information for returning to the first processing step are registered in the management table,
The program according to claim 6, wherein when the switching flag indicates context setting, control is transferred to a setting step using the context setting information included in the switching parameter.
The registration unit registers context information in a management table that manages the identifier, a unique context number for each context, and context information indicating the context in a one-to-one correspondence, and corresponds to the context information. A registration step for returning the context number to be
When the identifier specified by the own module matches the identifier of the own module, the context information corresponding to the context number specified by the own module is acquired from the management table and acquired. Replacing the context of the module with the context information
If the identifier specified by the own module and the identifier of the own module do not match, the setting step of replacing the context of the own module with the context immediately before execution of the first processing step Prepared,
When the switching factor is context setting, immediately before the switching is performed, the switching flag indicating context setting and the switching parameter including at least context setting information indicating the context set by the setting step. Store in the shared area,
7. When the switching flag indicates the context setting, immediately after the switching is performed, control is transferred to the setting step using the context setting information stored in the switching parameter. The listed program.
The shared area further stores a switching source identifier indicating a switching source module,
When the switching factor is calling, immediately before the switching is performed, the identifier indicating the own module is stored in the shared area as the switching source identifier,
When the switching factor is return from calling, the identifier indicating the switching source module is acquired from the switching history area holding the information by switching, and stored in the shared area as the switching source identifier,
3. The switching source identifier is acquired from the shared area and stored in the switching history area immediately after the switching is performed when the switching flag is a value indicating the call. The program described in.
JP2012500425A 2010-02-18 2010-02-18 program Active JP5377748B2 (en)
PCT/JP2010/052465 WO2011101972A1 (en) 2010-02-18 2010-02-18 Program
JPWO2011101972A1 JPWO2011101972A1 (en) 2013-06-17
JP5377748B2 true JP5377748B2 (en) 2013-12-25
ID=44482590
JP2012500425A Active JP5377748B2 (en) 2010-02-18 2010-02-18 program
US (1) US9116741B2 (en)
JP (1) JP5377748B2 (en)
WO (1) WO2011101972A1 (en)
CN103049683B (en) * 2012-12-18 2016-04-06 惠州市亿能电子有限公司 A kind of BMS host computer procedure mandate time slot scrambling
US10089126B2 (en) * 2013-03-21 2018-10-02 Vmware, Inc. Function exit instrumentation for tail-call optimized code
JP2005196257A (en) * 2003-12-26 2005-07-21 Toshiba Corp Microprocessor
JP2009064462A (en) * 2008-10-27 2009-03-26 Toshiba Corp Microprocessor
JPS63132334A (en) * 1986-11-21 1988-06-04 Nec Corp Parameter delivery system
JP2002041168A (en) 2000-07-24 2002-02-08 Sony Corp System and method for processing information and storage medium
2010-02-18 WO PCT/JP2010/052465 patent/WO2011101972A1/en active Application Filing
2010-02-18 JP JP2012500425A patent/JP5377748B2/en active Active
2012-08-15 US US13/585,941 patent/US9116741B2/en active Active
JPWO2011101972A1 (en) 2013-06-17
WO2011101972A1 (en) 2011-08-25
US20130219408A1 (en) 2013-08-22
US9116741B2 (en) 2015-08-25
Ref document number: 5377748