Memory integrity verification device, information processing device, memory integrity verification method, and program

Abstract

The present invention provides a memory integrity verification device, an information processing device, a memory integrity verification method, and a program capable of preventing deadlocks. [Solution] The memory integrity verification device includes a tree cache that temporarily stores data assigned to nodes in an integrity tree which includes nodes arranged in a tree structure, and a request processing unit that receives requests from the cache memory for leaf nodes in the integrity tree and requests the tree cache to search for intermediate nodes from the leaf nodes to the root node in the integrity tree. The tree cache includes a first registration unit that locks intermediate nodes to exclusively control requests for the same intermediate node and registers a waiting request for each locked intermediate node. The request processing unit includes a first blocking unit that blocks requests to be received by the request processing unit according to the number of waiting requests registered in the first registration unit.

Description

Technical Field

[0001] The present disclosure relates to a memory integrity verification device, an information processing device, a memory integrity verification method, and a program.

Background Art

[0002] In an information processing device mounted on a computer or the like, hierarchical storage areas such as registers, caches, memories, and storages are provided. Here, in the transfer of data between the cache and the memory, data integrity verification and, in some cases, data encryption processing (either encryption and decryption or one of them) are performed. Thereby, leakage of data stored in the information processing device due to a physical attack from the outside to the information processing device can be prevented. Hereinafter, the data integrity verification performed in the transfer of data between the cache and the memory is also referred to as memory integrity verification processing. When data encryption is added, it is also referred to as memory encryption with integrity verification.

[0003] Furthermore, in recent years, development of a data integrity verification method using an integrity tree composed of a plurality of nodes connected in a tree shape to which a set of a counter and an identifier is assigned to each has been advanced. In the integrity verification processing using the integrity tree, not only verification of data assigned to leaf nodes which are the lowest layer nodes among the plurality of nodes constituting the integrity tree is performed, but also verification of authenticators (tags) assigned to each of all nodes existing on the path from the leaf node to the root node is performed. When this data integrity verification is combined with data encryption, forgery of data and unauthorized reuse of past data are prevented, so that data processing based on unintended data is prevented. Therefore, the risk of data leakage is further reduced and confidentiality is improved. A technique related to authentication of data using an integrity tree is disclosed in, for example, Patent Document 1.

Prior Art Documents

Patent Documents

[0004] [Patent Document 1] Special Publication No. 2020-529657 [Overview of the project] [Problems that the invention aims to solve]

[0005] As described in Patent Document 1, in an integrity verification process using an integrity tree, the address space covered by the integrity tree is the target of the integrity verification process. In other words, the address space assigned to each of the multiple leaf nodes, which are the lowest-level nodes among the multiple nodes that make up the integrity tree, is the final target of the integrity verification process. Therefore, one leaf node and another leaf node may be connected to a common ancestor node. Consequently, if access to data assigned to one leaf node and access to data assigned to another leaf node occur in parallel, the update processes of the common ancestor node caused by these accesses may conflict.

[0006] To avoid such conflicts, one possible approach is to lock the node being accessed, blocking other accesses from processing that node. However, in this case, the necessary series of processes on the node may not be completed, potentially leading to a deadlock in the integrity check process.

[0007] One of the purposes of this disclosure is to provide a memory integrity verification device, an information processing device, a memory integrity verification method, and a program that can prevent deadlocks from occurring, in view of the above-mentioned problems. [Means for solving the problem]

[0008] A memory integrity verification device according to one aspect of the present disclosure is a memory integrity verification device that verifies the integrity of data between a cache memory and a memory, comprising: a tree cache that temporarily stores data assigned to nodes in an integrity tree including nodes arranged in a tree structure; a request processing unit that receives requests from the cache memory for leaf nodes in the integrity tree and requests the tree cache to search for intermediate nodes from the leaf nodes to the root node in the integrity tree, wherein the tree cache includes a first registration unit that locks the intermediate nodes to exclusively control requests for the search to the same intermediate node and registers a waiting request for each locked intermediate node, and the request processing unit includes a first blocking unit that blocks requests to be received by the request processing unit according to the number of waiting requests registered by the first registration unit.

[0009] An information processing device according to one aspect of the present disclosure includes a cache memory, a memory, and a memory integrity verification unit that verifies the integrity of data between the cache memory and the memory, wherein the memory integrity verification unit includes a tree cache that temporarily stores data assigned to nodes in an integrity tree including nodes arranged in a tree structure, and a request processing unit that receives requests from the cache memory for leaf nodes in the integrity tree and requests the tree cache to search for intermediate nodes from the leaf nodes to the root node in the integrity tree, wherein the tree cache includes a first registration unit that locks the intermediate nodes to exclusively control requests for the search to the same intermediate node and registers a waiting request for each locked intermediate node, and the request processing unit includes a first blocking unit that blocks requests to be received by the request processing unit according to the number of waiting requests registered by the first registration unit.

[0010] A memory integrity verification method according to one aspect of the present disclosure is a memory integrity verification method for verifying the integrity of data between a cache memory and a memory, wherein a tree cache temporarily stores data assigned to a node in an integrity tree, which includes nodes arranged in a tree structure, in the tree cache; a request processing unit receives a request from the cache memory for a leaf node in the integrity tree; requests the tree cache to search for intermediate nodes from the leaf node to the root node in the integrity tree; locks the intermediate node to mutually control requests for the same search for that intermediate node; registers a waiting request for each locked intermediate node; and blocks requests accepted by the request processing unit according to the number of registered waiting requests.

[0011] A program according to one aspect of this disclosure is a program for verifying the integrity of data between a cache memory and memory, wherein the program causes a computer to execute a process that includes: temporarily storing data assigned to nodes in an integrity tree, which includes nodes arranged in a tree structure, in the tree cache using a tree cache; receiving a request from the cache memory for a leaf node in the integrity tree; requesting the tree cache to search for intermediate nodes from the leaf node to the root node in the integrity tree; locking the intermediate node to mutually control requests for the same search for that intermediate node; registering a wait request for each locked intermediate node; and blocking requests accepted by the request processing unit according to the number of registered wait requests. [Effects of the Invention]

[0012] According to this disclosure, it is possible to prevent deadlocks from occurring. [Brief explanation of the drawing]

[0013] [Figure 1] This is a block diagram showing an example configuration of a memory integrity verification device according to several embodiments. [Figure 2] This is a block diagram showing an example configuration of an information processing device including a memory integrity verification unit according to several embodiments. [Figure 3] This is a conceptual diagram showing examples of the configuration of a completeness tree according to several embodiments. [Figure 4] This diagram shows the relationship between each node constituting the integrity tree according to several embodiments and the cache line corresponding to each node. [Figure 5] This figure illustrates the parallel processing of the completeness verification process using a completeness tree according to several embodiments. [Figure 6] This figure illustrates the parallel processing of the completeness verification process using a completeness tree according to several embodiments. [Figure 7] This shows examples of the data structure registered in MSHR according to several embodiments. [Figure 8] This is a block diagram showing detailed configuration examples of PAT Requester according to several embodiments. [Figure 9] This is a block diagram showing detailed configuration examples of PAT Cache according to several embodiments. [Figure 10] This is a block diagram showing detailed configuration examples of an Authenticator according to several embodiments. [Figure 11] This is a block diagram showing detailed configuration examples of a Verifier according to several embodiments. [Figure 12] This is a block diagram showing detailed configuration examples of Memory Requester according to several embodiments. [Figure 13] This flowchart shows examples of how PAT Requester operates according to several embodiments. [Figure 14] This flowchart shows examples of PAT Cache operation according to several embodiments. [Figure 15] This flowchart shows examples of PAT Cache operation according to several embodiments. [Figure 16] It is a flowchart showing an operation example of a PAT Cache according to some embodiments. [Figure 17] It is a flowchart showing an operation example of an Authenticator according to some embodiments. [Figure 18] It is a flowchart showing an operation example of an Authenticator according to some embodiments. [Figure 19] It is a flowchart showing an operation example of a Verifier according to some embodiments. [Figure 20] It is a flowchart showing an operation example of a Memory Requester according to some embodiments. [Figure 21] It is a flowchart showing an operation example of a Memory Requester according to some embodiments. [Figure 22] It is a block diagram showing a configuration example of a computer hardware according to some embodiments.

Embodiments for Carrying Out the Invention

[0014] Hereinafter, embodiments will be described with reference to the drawings. In each drawing, the same reference numerals are assigned to the same elements, and redundant descriptions are omitted as necessary. The arrows shown in each drawing are for illustrative purposes and do not limit the type or direction of signals (data).

[0015] (Examination of Related Technologies) As described above, computers have a memory hierarchy represented by a series such as register cache memory storage. In the memory integrity verification process, an authenticator is added when sending data from the cache to the memory, and the integrity of the data is verified when reading after writing data from the memory to the cache.

[0016] The inventors considered a method for parallel processing of a cache of auxiliary data used to verify memory integrity. As described above, in integrity verification using an integrity tree, if access to data assigned to one leaf node and access to data assigned to another leaf node occur in parallel, there is a possibility that the update processes of common ancestor nodes caused by these accesses may conflict.

[0017] To avoid this situation, in the completeness verification process using the completeness tree, when access to data assigned to a certain leaf node (first node) (first access) and then subsequent access to data assigned to another leaf node (second node) (second access) occurs, the following process is executed.

[0018] First, upon the first access, all nodes on the path from the first node to the root node, up to the first node on the path where the cache line was cached, are locked, and then the locked nodes are updated. Then, upon the second access, all nodes on the path from the second node to the root node, up to the first node on the path where the cache line was cached, are locked, and then the locked nodes are updated. Here, if there is a third node (i.e., a common ancestor node) on the path from the second node to the root node that was already locked upon the first access, all nodes on the path from the second node to the node immediately preceding the third node are locked. After all nodes locked upon the first access are released, the remaining nodes on the path from the third node to the root node, up to the first node on the path where the cache line was cached, are locked, and then the locked nodes are updated.

[0019] In related technologies, the above lock is implemented using a mechanism called MSHR (miss status holding register). That is, when a node is locked, its identifier (address) is registered in the MSHR. When there is new access to this registered node, it is added to the access waitlist for that node's address. In the above example, the third node is locked by access from the first node, meaning the third node is registered in the MSHR. Next, when the second access attempts to access the third node, it is added to the waitlist because it is already locked. Then, when the first access finishes its process and releases the lock on the third node, it grants access to the third node (which has been updated in this case) to the access source listed in the waitlist.

[0020] The MSHR described above has limitations on the number of nodes that can be registered, and also on the length of the wait list for each registered node. Smaller numbers and lengths allow for smaller circuit size and faster operation time. Due to these limitations, when the number of registered nodes reaches its limit, the cache of nodes in the completeness tree is blocked to prevent further registration requests. The cache is also blocked if the wait list for a registered node becomes full.

[0021] However, the blocks that occur in the two cases described above can cause deadlocks when this cache is operated in parallel. For example, suppose the first access locks the third node, and then the second access accesses the third node, causing the wait list for the third node to overflow and the cache to be blocked. At this time, if the first access has not accessed all the necessary nodes and further access to the cache is required, the above block will prevent this access from being completed. As a result, the series of operations for the necessary nodes cannot be completed, and the locked third node cannot be released. Until this third node is released, access sources registered in the wait list for the third node cannot be allowed to access the node, and the wait list cannot be released. In other words, the associated blocks cannot be released. Therefore, in related technologies, there was a problem that the entire memory integrity check process would fall into a deadlock.

[0022] (Embodiment 1) Next, Embodiment 1 will be described. This embodiment will outline several embodiments.

[0023] Figure 1 is a block diagram showing an example configuration of a memory integrity verification device 10 according to several embodiments. The memory integrity verification device 10 is a device that verifies the integrity of data between the cache memory and the main memory. Data integrity means that the data read and written between the cache memory and the main memory is consistent, that is, the data has not been tampered with. For example, the cache memory, the main memory, and the memory integrity verification device 10 may constitute an information processing device.

[0024] In the example shown in Figure 1, the memory integrity verification device 10 includes a tree cache 11 and a request processing unit 12.

[0025] The memory integrity verification device 10 performs integrity verification using an integrity tree that includes nodes arranged in a tree structure. The tree cache 11 temporarily stores the data assigned to the nodes in the integrity tree.

[0026] The request processing unit 12 receives a request from the cache memory for a leaf node in the integrity tree. To verify the integrity of the data in the leaf node, the request processing unit 12 requests the tree cache 11 to search for intermediate nodes from the leaf node to the root node in the integrity tree.

[0027] Furthermore, the request processing unit 12 may accept other requests. For example, the request processing unit 12 may accept a cache evicting request from the tree cache 11. In this case, the request processing unit 12 may prioritize the execution of the request from the tree cache 11 over the request from the cache memory. Also, the request processing unit 12 may accept an update request for a counter assigned to a node from the authentication unit, which generates authentication tags assigned to nodes. In this case, the request processing unit 12 may prioritize the execution of the request from the authentication unit over the request from the cache memory. Furthermore, if a request for searching for an intermediate node in the tree cache 11 conflicts with other requests, the request processing unit 12 may prioritize the execution of the request for searching for an intermediate node over the other requests.

[0028] The tree cache 11 includes a registration unit (e.g., a first registration unit) 13. The registration unit 13 locks intermediate nodes to exclusively control search requests for the same intermediate node. For example, the registration unit 13 is an MSHR that registers requests in the tree cache. That is, by registering the requested intermediate node in the MSHR, it locks the intermediate node and prohibits other access to the same intermediate node. Furthermore, the registration unit 13 registers a wait request for each locked intermediate node. For example, if there is a new request for an intermediate node registered in the MSHR, the new request is added to the wait list for each intermediate node and placed in a waiting state.

[0029] The request processing unit 12 includes a blocking unit (for example, a first blocking unit) 14. The blocking unit 14 blocks requests to the request processing unit 12. The blocking unit 14 blocks requests to be accepted by the request processing unit 12 in proportion to the number of waiting requests registered in the registration unit 13 of the tree cache 11. For example, the blocking unit 14 may block requests to be accepted by the request processing unit 12 if the number of waiting requests registered in the registration unit 13 is greater than a predetermined threshold. For example, the predetermined threshold is a value at which a shortage of waiting requests in the list can be expected, and is less than the maximum number of waiting requests that can be registered in the registration unit 13 (MSHR).

[0030] Furthermore, the tree cache 11 may include a blocking section (for example, a second blocking section) that blocks requests to the tree cache 11. Note that if the tree cache 11 and the request processing unit 12 each include a blocking section, either the first blocking section or the second blocking section may be included. The blocking section of the tree cache 11 may block requests accepted by the tree cache 11 in accordance with the number of intermediate nodes locked in the registration unit 13. For example, the blocking section of the tree cache 11 may block requests accepted by the tree cache 11 when the number of intermediate nodes locked in the registration unit 13 reaches its upper limit (the maximum number of intermediate nodes that can be locked in the registration unit 13).

[0031] Furthermore, the request processing unit 12 may include a registration unit (for example, a second registration unit) for registering leaf nodes. Note that if both the tree cache 11 and the request processing unit 12 include a registration unit, either the first or second registration unit may be included. The registration unit of the request processing unit 12 locks leaf nodes to exclusively control requests from the cache memory for the same leaf node. Furthermore, the registration unit of the request processing unit 12 registers a waiting request for each locked leaf node. For example, the registration unit of the request processing unit 12 is an MSHR that registers requests in the request processing unit 12. For example, the blocking unit 14 may block requests accepted by the request processing unit 12 according to the number of leaf nodes locked in the registration unit of the request processing unit 12, or the number of waiting requests registered in the registration unit of the request processing unit 12. The blocking unit 14 may block requests accepted by the request processing unit 12 if the number of leaf nodes locked in the registration unit of the request processing unit 12 reaches the upper limit (the maximum number of leaf nodes that can be locked in the registration unit of the request processing unit 12), or if the number of waiting requests registered in the registration unit of the request processing unit 12 reaches the upper limit (the maximum number of waiting requests that can be registered in the registration unit of the request processing unit 12).

[0032] In this memory integrity checker, which performs integrity checks using an integrity tree, the system comprises a request processing unit that accepts requests from cache memory and a tree cache that accepts requests from the request processing unit. Furthermore, the tree cache includes a registration unit (MSHR) that locks requests for the same intermediate node, and the request processing unit blocks requests it accepts in proportion to the number of waiting requests in the registration unit. This allows requests to be blocked before the list of waiting requests in the registration unit reaches its upper limit. At this time, requests to be entered into the tree cache are not blocked, making it possible to process requests entered into the tree cache from the request processing unit. Therefore, the integrity tree search process (a series of processes for higher-level nodes of leaf nodes) can continue between the request processing unit and the tree cache without increasing the processing load due to requests to the request processing unit, thus preventing deadlocks.

[0033] (Embodiment 2) Next, Embodiment 2 will be described. In this embodiment, a specific example of Embodiment 1 will be described.

[0034] <Overview of the Information Processing Device> First, the general configuration of the information processing device will be described. Figure 2 is a block diagram showing an example configuration of the information processing device 1, including a memory integrity verification unit 100 according to several embodiments. In the example in Figure 2, the information processing device 1 includes a memory integrity verification unit 100, memory 200, and LLC (Last Level Cache) 300. The information processing device 1 also includes a processor, primary cache, secondary cache, etc., as needed.

[0035] Memory 200 is the main memory that stores data used by the processor. LLC300 is a cache memory that temporarily stores data from memory 200 and provides that data to the processor at high speed. Of the cache memories, LLC300 is the one closest to memory 200.

[0036] The memory integrity verification unit 100 is installed between the memory 200 and the LLC 300. The memory integrity verification unit 100 and the memory 200 are connected by a memory bus 201. The memory integrity verification unit 100 and the LLC 300 are connected by an LLC bus 301. The memory integrity verification unit 100 performs memory integrity verification processing using an integrity tree between the memory 200 and the LLC 300. The memory integrity verification unit 100 can process multiple requests from the LLC 300 in parallel.

[0037] The memory integrity verification unit 100 performs memory integrity authentication processing on data exchanged between LLC 300 and memory 200, specifically for data written from the cache (LLC 300) to memory 200. An option to add encryption processing to the memory integrity authentication processing is also available. Furthermore, the memory integrity verification unit 100 performs memory integrity verification processing on data read from memory 200 to the cache (LLC 300). An option to add decryption processing to the memory integrity verification processing is also available. The memory integrity authentication processing and memory integrity verification processing utilize an integrity tree consisting of multiple nodes arranged in a tree structure. Each node in the integrity tree is assigned a pair of counters and identifiers.

[0038] In this integrity verification process using an integrity tree, authentication or verification is performed not only on the data assigned to the leaf node, which is the lowest-level node among the multiple nodes that make up the integrity tree, but also on the authenticators (authentication tags) assigned to each node on the path from the leaf node to the root node. This reduces the risk of data leakage and improves confidentiality. The authentication tags assigned to each node are generated using the counter and identifier assigned to that node.

[0039] In the example shown in Figure 2, the memory integrity verification unit 100 comprises a PAT Requester 110, a PAT Cache 120, an Authenticator 130, a Verifier 140, a Memory Requester 150, and an Encryption Engine 160. PAT stands for Parallelizable Authentication Tree.

[0040] The PAT Requester (PAT Request Processing Unit) 110 receives data read requests from memory 200 and data write requests to memory 200 from LLC 300 (LLC bus 301). For example, PAT Requester 110 corresponds to the request processing unit 12 in Figure 1. PAT Requester 110 also receives command requests (evict, carry-up, update) from PAT Cache 120 and Authenticator 130. Based on the received requests, PAT Requester 110 sends nodes and requests to PAT Cache 120 and Memory Requester 150. For example, PAT Requester 110 includes Arbiter 111, block unit 112, MSHR unit 113, command processing unit 114, and traverse unit 115. For example, block unit 112 corresponds to block unit 14 in Figure 1. Details of each part of PAT Requester 110 will be described later.

[0041] The PAT Cache 120 is a storage unit that caches data assigned to each node of the integrity tree. Specifically, the PAT Cache 120 is a cache that temporarily stores some of the counters and identifiers assigned to each node of the integrity tree, and the tags generated using them. For example, the PAT Cache 120 corresponds to the tree cache 11 in Figure 1. In response to requests from the PAT Requester 110, the PAT Cache 120 searches for cached nodes and makes requests to the Authenticator 130, etc. For example, the PAT Cache 120 includes a block unit 121 and an MSHR unit 122. For example, the MSHR unit 122 corresponds to the registration unit 13 in Figure 1. Details of each part of the PAT Cache 120 will be described later.

[0042] The Authenticator (authentication unit) 130 generates an authentication tag for the node to be written to memory 200. The Authenticator 130 generates the authentication tag according to the cryptographic protocol using the Encryption Engine 160. The Encryption Engine 160 encrypts or decrypts the input information according to a predetermined encryption method. For example, the Authenticator 130 includes a converge unit 131. Details of each part of the Authenticator 130 will be described later.

[0043] The Verifier 140 performs verification on the nodes read from memory 200. The Verifier 140 uses the Encryption Engine 160 to verify the read nodes (data) according to the cryptographic protocol. Details of each part of the Verifier 140 will be described later.

[0044] The Memory Requester 150 requests data to be read from or written to the memory 200 (memory bus 201). For example, the Memory Requester 150 includes a converge unit 151. Details of each part of the Memory Requester 150 will be described later.

[0045] <Structure of the completeness tree> Figure 3 is a conceptual diagram showing examples of the configuration of a completeness tree according to several embodiments. As shown in Figure 3, a completeness tree is composed of multiple nodes linked in a tree-like structure. Among the multiple nodes that make up the completeness tree, the node in the top layer is called the root node, the node in the lowest layer is called a leaf node, and the nodes between the root node and the leaf nodes are called intermediate nodes. In a tree structure, a node above a given node is called a parent node, a node below a given node is called a child node, and two nodes that share the same parent node are called sibling nodes.

[0046] The address space covered by this integrity tree is the target of the memory integrity verification process of the memory integrity verification unit 100. In other words, the address space allocated to each of the leaf nodes, which are the lowest-level nodes among the multiple nodes that make up this integrity tree, is the target of the memory integrity verification process. If encryption is involved, it is also the target of encryption. From now on, we will only consider cases involving encryption and decryption. If neither of these is involved, it is clear that the authenticated encryption used can be changed to a simple authentication process.

[0047] Figure 4 shows the relationship between each node constituting the completeness tree according to several embodiments and the cache line corresponding to each node.

[0048] In the example in Figure 4, the completeness tree 400 includes a leaf node 401, an intermediate node 411, and a root node 421. Each node is allocated a data block. The data block allocated to each node is called a cache line. The PAT Cache 120 stores the cache lines (data blocks) allocated to each node.

[0049] Each cache line shall have at least one bit indicating either "dirty" or "clean". "Clean" indicates that the cache line stored in PAT Cache 120 is the same as the corresponding cache line stored in memory 200. "Dirty" indicates that the cache line stored in PAT Cache 120 has been updated and is different from the corresponding cache line stored in memory 200.

[0050] Furthermore, each node is assigned a counter and an identifier. Each leaf node 401 is assigned counter 405 and address 404. That is, the identifier of each leaf node 401 is the address 404 of the corresponding cache line.

[0051] Each intermediate node 411 is assigned a counter 413 and an identifier 412. The identifier 412 of each intermediate node 411 can be derived from its position in the completeness tree 400. For example, the identifier 412 assigned to the parent node (intermediate node 411) of a leaf node 401 identified by a certain address 404 can be derived from the address 404 of that leaf node 401.

[0052] The root node 421 is assigned a root counter 423 and a root identifier 422, similar to the intermediate node 411. Additionally, the root counter 423 is associated with key 430.

[0053] Furthermore, each leaf node 401 is assigned data 406 corresponding to address (identifier) ​​404. When this data 406 is written to the data cache (LLC300), it matches the cache line written to the data cache. The cache line written to the data cache contains only data 406.

[0054] At any leaf node 401, encrypted data (hereinafter also simply referred to as ciphertext) 403 is generated using the plaintext data 402 of the corresponding cache line and the key 430, and an authentication tag (authentication agent, MAC (Message Authentication Code)) 407 is generated using the ciphertext 403, the address 404 of the leaf node 401, the value of the counter 405 of the leaf node 401, and the key 430. The authentication tag may sometimes be simply referred to as a tag. The authentication tag 407 generated at the leaf node 401 is stored in a cache line 408 (a set of tags from sibling nodes), separate from the cache line of the plaintext data 402, along with authentication tags generated at other nodes (sibling nodes) that share a common parent node with the leaf node 401.

[0055] When a cache line allocated to leaf node 401 is written from the data cache (LLC300) to memory 200, the ciphertext 403 generated by encrypting the plaintext data 402 is written to memory 200 in place of the plaintext data 402.

[0056] In contrast, when a cache line assigned to leaf node 401 is read from memory 200 into the data cache, a tag is first generated using the address 404 of leaf node 401, the value of the counter 405 of leaf node 401, the ciphertext 403 read from memory 200, and the key 430. Only if the generated tag matches the tag 407 stored in cache line 408, the ciphertext 403 read from memory 200 is decrypted into plaintext data 402 using the key 430, and then read into the data cache as a cache line for leaf node 401. Note that at this time, the value of the counter 405 of leaf node 401 must be included in the cache line of its parent node (intermediate node 411) and must exist in PAT Cache 120.

[0057] At any intermediate node 411, a tag 415 is generated using the values ​​of counters 414 of all of the intermediate node 411's child nodes, the value of counter 413 of the intermediate node 411, the identifier 412 of the intermediate node 411, and the key 430. The cache line assigned to the intermediate node 411 consists of the values ​​of counters 414 of all of the intermediate node 411's child nodes and the tag 415 generated at the intermediate node 411.

[0058] When a cache line allocated to intermediate node 411 is written from PAT Cache 120 to memory 200, the authentication tags contained in that cache line must be generated using the counter values ​​of each of the child nodes contained in that cache line. In other words, after the tags contained in the cache line are generated, the counter values ​​of any of the child nodes contained in the cache line must not be updated.

[0059] In contrast, when a cache line allocated to intermediate node 411 is read from memory 200 into PAT Cache 120, an authentication tag is first generated using the values ​​of counters 414 of all child nodes of intermediate node 411 included in the cache line read from memory 200, the value of counter 413 of intermediate node 411, the identifier 412 of intermediate node 411, and the key 430. Only if the generated authentication tag matches the authentication tag included in the cache line allocated to intermediate node 411 is the cache line read from memory 200 read into PAT Cache 120. Note that at this time, the value of counter 413 of intermediate node 411 must be included in its parent node's cache line and must exist in PAT Cache 120.

[0060] At the root node 421, an authentication tag 425 is generated using the values ​​of the counters 424 of all of the root node 421's child nodes, the value of the root node 421's counter (root counter) 423, the root node 421's identifier (root identifier) ​​422, and the key 430. The cache line assigned to the root node 421 consists of the values ​​of the counters 424 of all of the root node 421's child nodes and the authentication tag 425 generated at the root node 421.

[0061] The value of the counter assigned to any node is updated in the following case: When a cache line assigned to any node is written from the data cache (LLC300) or PAT Cache120 to memory 200, and the cache line has been updated since it was read from memory 200 to the data cache or PAT Cache120, the value of the counter assigned to that node is updated, and then the authentication tags included in the cache line assigned to that node are updated. Subsequently, the updated cache line is written from the data cache or PAT Cache120 to memory 200.

[0062] When data (cache lines) assigned to any leaf node 401 is updated, the counter values ​​of all nodes along the path from this leaf node 401 to the root node 421 are incremented. Here, the counter assigned to the root node 421 (root counter) 423 is specially protected to prevent direct manipulation by an attacker. The tags of the corresponding nodes are then updated by the counter 423 of the root node 421, the counters 413 of each intermediate node 411, or the counters 405 and data 406 of each leaf node 401. As a result, the tags of each node keep up with the latest status.

[0063] Furthermore, the counter assigned to each node in the completeness tree may consist of a major counter, whose value is represented by the higher bits of the multiple bits representing the value of the counter, and a minor counter, whose value is represented by the lower bits. In this case, the major counter assigned to a node is shared by other nodes that share a common parent node (i.e., sibling nodes). This suppresses the increase in size due to the counters. In addition, the cache line of an intermediate node will store, as the value of the counter, the values ​​of multiple minor counters assigned to each of the intermediate node's child nodes, and the value of a single major counter shared by all of the intermediate node's child nodes. Hereafter, a counter composed of a major counter and a minor counter will also be referred to as a split counter.

[0064] If the counters assigned to each node are split counters, the value of the minor counter is updated, or the value of the minor counter is initialized and then the value of the major counter is updated. If the major counter is updated, the values ​​of the minor counters assigned to each node that shares the major counter are initialized.

[0065] <Specific examples of parallel processing> Next, we will explain specific examples of parallel processing of the integrity check process using an integrity tree, using Figures 5 and 6. Figures 5 and 6 are diagrams illustrating parallel processing of the integrity check process using an integrity tree according to several embodiments.

[0066] The integrity verification process using a integrity tree requires improved processing power through parallelization of data access. However, if access to data assigned to one leaf node and access to data assigned to another leaf node occur in parallel, there is a possibility that the update processes of common ancestor nodes of these leaf nodes may conflict.

[0067] To avoid such a situation, the integrity verification process using the integrity tree in the memory integrity verification unit 100 executes the following process when access to data assigned to a certain leaf node (first node) (first access) and then subsequently access to data assigned to another leaf node (second node) (second access).

[0068] First, as shown in Figure 5, upon the first access, the memory integrity verification unit 100 locks all nodes N1 to N4 located on the path from leaf node N1 to root node N5, up to the first node N4 where the cache line is cached, and then updates the locked nodes N1 to N4.

[0069] Next, upon the second access, the memory integrity verification unit 100 attempts to lock all the nodes N6, N7, N3, N4 that exist on the path from the leaf node N6 to the first node N4 where the cache line is cached among the nodes that exist on the path from the leaf node N6 to the root node N5. However, among the nodes that exist on the path from the leaf node N6 to the node N4, there is a node N3 (common ancestor node) that has already been locked with the first access. In that case, the memory integrity verification unit 100 first locks all the nodes N6, N7 that exist on the path from the leaf node N6 to the node N7 immediately preceding the node N3.

[0070] Next, as shown in FIG. 6, after the locks of the nodes N1 to N4 locked with the first access are released, the memory integrity verification unit 100 locks the remaining nodes N3, N4 that exist on the path from the node N3 to the node N4, and then updates the locked nodes N6, N7, N3, N4.

[0071] <Data Structure of MSHR> To implement the locks in the parallel processing as described above, the memory integrity verification unit 100 uses an MSHR. Specifically, the MSHR unit 113 of the PAT Requester 110 locks the nodes requested by the PAT Requester 110, and the MSHR unit 122 of the PAT Cache 120 locks the nodes requested by the PAT Cache 120. FIG. 7 shows an example of the structure of the data registered in the MSHR according to some embodiments.

[0072] In the example of FIG. 7, the MSHR stores (registers) the address of the node to be locked, and for each node to be locked, stores (registers) a wait list for access (request). As shown in FIG. 7, the node address and the wait list for each node address may be registered in a two-dimensional table, or the wait list may be registered in a queue for each node address.

[0073] For example, if an address is registered in the MSHR, the node associated with that address is locked. When a node is registered and locked, requests for that node are placed on a waitlist and remain in a waiting state until the node is unlocked. Once the node is unlocked, the requests on the waitlist are executed.

[0074] <Detailed configuration of the memory integrity verification unit> Next, the detailed configuration of each part of the memory integrity verification unit 100, which performs integrity verification processing using the integrity tree described above, will be explained.

[0075] Figure 8 is a block diagram showing a detailed configuration example of a PAT Requester 110 according to several embodiments. In the example in Figure 8, the PAT Requester 110 comprises an Arbiter 111, a block unit 112, an MSHR unit 113, a command processing unit 114, a traverse unit 115, an Arbiter 116, and an Arbiter 117.

[0076] Arbiter 111 processes incoming requests according to their priority. Arbiter 111 receives requests from LLC 300 (LLC bus 301) to read data from memory 200 and write data to memory 200, and also receives command requests (evict, carry-up, update) from PAT Cache 120 and Authenticator 130. If requests conflict, it executes each request according to its priority and sends it to block unit 112. In Figure 8, the numbers written in the input of Arbiter 111 indicate the priority. The same applies to other Arbiters. For example, the priority of each request is set in the following order from highest to lowest: update request, carry-up request, evict request, and request from LLC 300.

[0077] The block unit 112 blocks (discards) or allows incoming requests to pass through depending on the configured state (blocked state / non-blocked state). If the block unit 112 is in a blocked state (blocked), it blocks the request from Arbiter 111; otherwise, it sends the request from Arbiter 111 to MSHR unit 113.

[0078] The MSHR unit 113 is a registration unit (locking unit) that registers (locks) nodes (leaf nodes) requested by the PAT Requester 110. The MSHR unit 113 includes MSHR 113a and MSHR control unit 113b. MSHR 113a stores the addresses of the nodes (leaf nodes) that the PAT Requester 110 locks and a waiting list for each address.

[0079] The MSHR control unit 113b controls the registration of node addresses and the wait list to MSHR 113a. If the requested address (leaf node) is not registered in MSHR 113a, the MSHR control unit 113b registers the requested address in MSHR 113a, locks the leaf node, and sends the request to the command processing unit 114. If the number of addresses registered in MSHR 113a reaches the upper limit, the MSHR control unit 113b sets the block unit 112 to a blocked state. In other words, if the number of addresses registered in MSHR 113a reaches the upper limit, the block unit 112 sets the block unit 112 to a blocked state, thereby blocking requests input to the PAT Requester 110.

[0080] Furthermore, if the requested address (leaf node) is registered in MSHR113a, the MSHR control unit 113b adds the request to the waiting list for that address. If the length of the waiting list reaches its limit, the MSHR control unit 113b sets the block unit 112 to a blocked state. In other words, if the length of the waiting list in MSHR113a reaches its limit, the block unit 112 sets the block unit 112 to a blocked state, thereby blocking requests input to the PAT Requester 110.

[0081] The command processing unit 114 executes the processing of each command and sends requests based on each command to the PAT Cache 120. For example, the command processing unit 114 includes the leaf processing unit 114a, the carry-up processing unit 114b, the update processing unit 114c, and the evict processing unit 114d.

[0082] The leaf processing unit 114a processes requests from LLC 300 for leaf nodes. The leaf processing unit 114a requests the leaf node requested by LLC 300, the node containing its counter, and, if it is a read request, the node containing its authentication tag (if it is a write request, the authentication tag is not requested) from PAT Cache 120.

[0083] The carry-up processing unit 114b processes the carry-up request from the Authenticator 130. The update processing unit 114c processes the update request from the Authenticator 130. The evict processing unit 114d processes the evict request from the PAT Cache 120.

[0084] The traverse unit (search request unit) 115 receives a response from the PAT Cache 120 and, depending on the received response, sends a request (node) to the Memory Requester 150 (Arbiter 117) or the PAT Cache 120 (Arbiter 116). If the cache line of the node requested from the PAT Cache 120 is found in the PAT Cache 120, or if the node is registered in the MSHR of the PAT Cache 120, the traverse unit 115 sends the response result from the PAT Cache 120 to the Memory Requester 150. If the cache line of the node requested from the PAT Cache 120 is not found in the PAT Cache 120 and the node is not registered in the MSHR of the PAT Cache 120, the traverse unit 115 extracts the parent node of that node and requests the extracted parent node from the PAT Cache 120 (requests a search for the parent node).

[0085] Arbiter 116 receives requests from command processing unit 114 and requests from traverse unit 115, and if there is a conflict of requests, it processes them according to priority. For example, the priority of a request from traverse unit 115 is higher than the priority of a request from command processing unit 114.

[0086] Arbiter 117 receives requests from MSHR unit 113 and requests from traverse unit 115, and if the requests conflict, it processes them according to priority. For example, the priority of a request from MSHR unit 113 is higher than the priority of a request from traverse unit 115.

[0087] Figure 9 is a block diagram showing a detailed configuration example of the PAT Cache 120 according to several embodiments. In the example in Figure 9, the PAT Cache 120 comprises a block section 121, an MSHR section 122, and a cache section 123.

[0088] The block unit 121 blocks (discards) or allows incoming requests to pass through depending on the configured state (blocked state / non-blocked state). The block unit 112 blocks requests from PAT Requester 110 if it is in a blocked state (blocked), and sends requests from PAT Requester 110 to Cache unit 123 if it is not in a blocked state.

[0089] The cache unit 123 includes a cache 123a and a cache control unit 123b. The cache 123a caches (stores) the data assigned to each node of the integrity tree.

[0090] The Cache control unit 123b controls the caching and retrieval of data for Cache 123a. If the requested node is not a leaf node, the Cache control unit 123b searches for the requested node in Cache 123a. If the requested node is cached, the Cache control unit 123b reads the corresponding cache line and returns the read result to the PAT Requester 110 (sends a response). If this node needs to be updated, the Cache control unit 123b updates the cached data at the time of reading.

[0091] The MSHR unit 122 is a registration unit (locking unit) that registers (locks) nodes (intermediate nodes) requested by the PAT Cache 120. The MSHR unit 122 includes MSHR 122a and MSHR control unit 122b. MSHR 122a stores the addresses of nodes (intermediate nodes) that the PAT Cache 120 locks and a wait list for each address.

[0092] The MSHR control unit 122b controls the registration of node addresses and waitlists to MSHR122a. If the requested node (intermediate node) is not cached and is not registered in MSHR122a, the MSHR control unit 122b registers the requested address in MSHR122a, locks the intermediate node, requests this node from the Authenticator 130, and responds to the PAT Requester 110. If the number of addresses registered in MSHR122a reaches the upper limit, the MSHR control unit 122b sets the block unit 121 to a blocked state. In other words, if the number of addresses registered in MSHR122a reaches the upper limit, the block unit 121 sets the block unit 121 to a blocked state, thereby blocking requests that are input to the PAT Cache 120.

[0093] Furthermore, if the requested node (intermediate node) is not cached but is registered in MSHR122a, the MSHR control unit 122b writes the request to the waiting list for the corresponding address and sends a reply to the PAT Requester 110. When the length of the waiting list reaches a predetermined threshold, the MSHR control unit 122b sets the block unit 112 of the PAT Requester 110 to a blocked state. In other words, when the length of the waiting list of MSHR122a reaches a predetermined threshold, the block unit 112 of the PAT Requester 110 is set to a blocked state, thereby blocking requests input to the PAT Requester 110.

[0094] Figure 10 is a block diagram showing a detailed configuration example of an Authenticator 130 according to several embodiments. In the example in Figure 10, the Authenticator 130 comprises a converge unit 131, a branch unit 132, an Arbiter 133, an Arbiter 134, a branch unit 135, a counter update unit 136, a mode of operation unit 137, and an Arbiter 138.

[0095] The branch unit 132 receives node requests and write-back nodes from the PAT Cache 120, sends the write-back nodes to the converge unit 131 (Arbiter 133), and sends the rest to the Verifier 140 (Arbiter 134).

[0096] Arbiter 133 receives requests from branch 132 and branch 135, and if there is a conflict of requests, it processes them according to priority. Either the request from branch 132 or the request from branch 135 may be given priority.

[0097] The convergence unit (node ​​storage unit) 131 stores the nodes to be written back from the PAT Cache 120 and sends the stored nodes to the counter update unit 136.

[0098] The branch unit 135 receives verified nodes from the Verifier 140, sends nodes that need to be updated to the counter update unit 136, and sends the rest to the converge unit 131 (Arbiter 133).

[0099] The counter update unit 136 updates the node's counter. If a carry-up request is necessary, the counter update unit 136 sends the carry-up request to the PAT Requester 110 (Arbiter 138).

[0100] The mode of operation unit (authentication tag generation unit) 137 generates authentication tags using the Encryption Engine and sends the node where the authentication tags were generated to the PAT Cache 120. If an update request is required, the mode of operation unit 137 sends the update request to the PAT Requester 110 (Arbiter 138).

[0101] Arbiter134 receives node requests from PAT Cache120 and node requests from mode of operation unit137, and processes them according to priority if there is a conflict. Either node request from PAT Cache120 or node request from mode of operation unit137 may be given priority.

[0102] Arbiter 138 receives carry-up requests from counter update unit 136 and update requests from mode of operation unit 137, and processes them according to priority if there is a conflict. For example, the update request from mode of operation unit 137 has a higher priority than the carry-up request from counter update unit 136.

[0103] Figure 11 is a block diagram showing detailed configuration examples of Verifier 140 according to several embodiments. In the example shown in Figure 11, Verifier 140 includes a mode of operation unit 141 and a Confirm verified unit 142.

[0104] The mode of operation unit (node ​​verification unit) 141 receives a response from the Memory Requester 150 and verifies the nodes (data) of the received response using the Encryption Engine 160.

[0105] The Confirm Verification Unit (flag verification unit) 142 sets a flag indicating that a node has been verified, and after confirming that the verified flag is set, it sends the information to the Authenticator 130.

[0106] Figure 12 is a block diagram showing a detailed configuration example of a Memory Requester 150 according to several embodiments. In the example in Figure 12, the Memory Requester 150 includes a converge unit 151, an Aarbiter 152, and an A-tag confirm unit 153.

[0107] Arbiter152 receives requests (nodes) from the traverse unit 115 of PAT Requester110 and responses from memory 200, and processes them according to priority if they conflict. For example, the priority of a request from the traverse unit 115 is higher than the priority of a response from memory 200.

[0108] The converge unit (node ​​storage unit) 151 stores the nodes (anchors) received from the traverse unit 115. The converge unit 151 also stores the response nodes (data) received from the memory 200.

[0109] The A-tag confirm unit (authentication tag confirmation unit) 153 receives a request from the Verifier 140 (Authenticator 130) and sends the received request to the memory 200. If the received request is accompanied by data, the A-tag confirm unit 153 confirms that a flag indicating that an authentication tag is attached is set.

[0110] <Operation of the memory integrity verification unit> Next, we will describe examples of the operation of each part of the memory integrity verification unit 100 described above.

[0111] Figure 13 is a flowchart showing an example of the operation of PAT Requester 110 as shown in Figure 8.

[0112] In the example in Figure 13, Arbiter 111 accepts requests from LLC300 (LLC bus 301), PAT Cache 120, or Authenticator 130 (S101). For example, Arbiter 111 accepts requests from LLC300 (LLC bus 301) to read cache lines from memory 200 to the data cache (LLC300) and to write cache lines from the data cache to memory 200. These requests relate to data stored in the data cache and therefore relate to leaf nodes. Arbiter 111 compares requests from LLC300 with requests from other sources and accepts requests from LLC300 with the lowest priority (3). That is, if there are other requests, Arbiter 111 will execute those requests before requests from LLC300.

[0113] Next, the block unit 112 determines whether or not it is in a blocked state (S102). If it is in a blocked state (blocked), it blocks the request from Arbiter 111 (S103). If it is not in a blocked state, it sends the request from Arbiter 111 to MSHR unit 113.

[0114] If the block unit 112 is not in a blocked state, the MSHR control unit 113b determines whether the address of the requested node is registered in MSHR 113a (i.e., locked) (S104). In other words, it determines whether a previous request for the same address (leaf node) has been completed.

[0115] If the requested address (leaf node) is not registered in MSHR113a (i.e., there are no past requests that have not been completed for the same leaf node), the MSHR control unit 113b registers and locks the requested address (leaf node) in MSHR113a (S105) and sends the request to the command processing unit 114. At this time, if the number of addresses registered in MSHR113a reaches the upper limit, the MSHR control unit 113b sets the block unit 112 to a blocked state (S106).

[0116] Furthermore, if the requested address (leaf node) is registered in MSHR113a (i.e., if previous requests for the same leaf node have not been completed), the MSHR control unit 113b writes the request to the waiting list for that address (S107), and this request enters a waiting state. At this time, if the length of the waiting list reaches its upper limit, the MSHR control unit 113b sets the block unit 112 to a blocked state (S108).

[0117] When a leaf node is registered with MSHR113a in S105, the command processing unit 114 executes the requested processing (each command processing) and sends the request (node) based on each command to the PAT Cache 120 (S109).

[0118] For example, the leaf processing unit 114a processes requests from LLC300 regarding leaf nodes. The leaf processing unit 114a requests the PAT Cache 120 for the leaf node requested by LLC300, the node containing its counter, and, if it is a read request, the node containing its authentication tag (if it is a write request, the authentication tag is not requested).

[0119] After the leaf processing unit 114a makes a request to the PAT Cache 120, the traverse unit 115 receives a response from the PAT Cache 120 (S110). If the response received from the PAT Cache 120 contains a cache line read from the PAT Cache 120, the traverse unit 115 sends the information of this response (information of the hit node (anchor)) to the Memory Requester 150 (S111). Also, if the response received from the PAT Cache 120 indicates that the node is registered in the MSHR 122a of the PAT Cache 120, the traverse unit 115 sends the information of this response (information indicating that the node is registered in the MSHR 122a) to the Memory Requester 150 (S111).

[0120] Furthermore, if the response received by the traverse unit 115 from the PAT Cache 120 relates to a counter node, is not cached, and is not registered in the MSHR 122a of the PAT Cache 120, the traverse unit 115 derives the identifier of the parent node of this node and requests the derived node from the PAT Cache 120 (S109). If the request from the traverse unit 115 and the request from the command processing unit 114 conflict, the Arbiter 116 prioritizes executing the request from the traverse unit 115.

[0121] After the traverse unit 115 makes a request to the PAT Cache 120, the traverse unit 115 receives a response from the PAT Cache 120, similar to the request from the leaf processing unit 114a (S110). The request from the traverse unit 115 and the response from the PAT Cache 120 (S109~S110) are repeated until a node present in the PAT Cache 120 or a node registered in the MSHR 122a of the PAT Cache 120 is encountered. For example, in Figure 5, the first access is repeated up to nodes N1 to N4 (up to the cached node N4), and the second access is repeated up to nodes N6, N7, and N3 (up to the node N3 registered in the MSHR 122a).

[0122] Figure 14 is a flowchart illustrating an example of the operation of the PAT Cache 120 shown in Figure 9. Figure 14 shows an example of operation when a request is received from the PAT Requester 110.

[0123] In the example shown in Figure 14, when the block unit 121 receives a request from the PAT Requester 110 (S201), it determines whether or not it is in a blocked state (S202). If it is in a blocked state, it blocks the request from the PAT Requester 110 (S203). If it is not in a blocked state, it sends the request from the PAT Requester 110 to the cache unit 123.

[0124] If the block unit 121 is not in a blocking state, the Cache control unit 123b determines whether the requested node is a leaf node or not (S204). If the requested node is a leaf node, it sends the request to the Authenticator 130 as is (S205). If the requested node is not a leaf node, it searches for this leaf node in the Cache 123a (S206).

[0125] The Cache control unit 123b determines, based on the search results, whether the requested node is cached (whether it is stored in Cache 123a) (S207). If the requested node is cached, it reads this cache line from Cache 123a (S208). If this node needs to be updated, it updates the cached data during the read operation. Furthermore, the Cache control unit 123b sends a response (reply) of the read result to the PAT Requester 110 (S209). This response is received by the traverse unit 115 as described above.

[0126] Furthermore, if the requested node is not cached, the Cache control unit 123b sends the request to the MSHR control unit 122b, and the MSHR control unit 122b determines whether or not the address of the requested node is registered with MSHR 122a (i.e., whether or not it is locked) (S210).

[0127] If the requested node is not cached but is registered with MSHR122a, the MSHR control unit 122b writes the request to the wait list of registered nodes (S211), and the request enters a waiting state. Furthermore, the MSHR control unit 122b replies to the PAT Requester 110 that the requested node is not cached but is registered with MSHR122a (S212). This reply is received by the traverse unit 115 as described above. At this time, if the length of the wait list reaches a predetermined threshold, the MSHR control unit 122b sets the block unit 112 of the PAT Requester 110 to a blocked state (S213).

[0128] If the requested node is not cached and is not registered in MSHR122a, the MSHR control unit 122b registers the requested node in MSHR122a (S214) and requests this node from the Authenticator 130 (S215). In addition, if it is a counter node, the MSHR control unit 122b replies to the PAT Requester 110 that the requested node is not cached and is not registered in MSHR122a (S216). This reply is received by the traverse unit 115 as described above. At this time, if the number of addresses registered in MSHR113a reaches the upper limit, the MSHR control unit 122b sets the block unit 121 to a block state (S217).

[0129] As described above, in response to a request from PAT Requester 110, PAT Cache 120 may perform the process of registering the node with MSHR 122a and adding the registered node to the waiting list. However, since there is a limit to the number of nodes that can be registered with MSHR 122a, the number of nodes may reach this limit. In this case, the MSHR control unit 122b changes the block unit 121 of PAT Cache 120 to a blocked state (S217). From then on, until the block unit 121 is released from its blocked state, PAT Cache 120 will not accept any new requests from PAT Requester 110. Processing for one leaf node involves multiple nodes by traveling back and forth between PAT Cache 120 and the traverse unit 115. Processing for the first node cannot be completed until all of these related nodes are collected (until all processing for multiple nodes is completed). If these nodes cannot be collected due to the blocked state of the block unit 121, processing cannot be completed, and the associated locked nodes cannot be released. This could lead to a deadlock where one block prevents the release of all other locks, leaving no room for MSHR122a to register new nodes. However, if the number of nodes that can be registered with MSHR122a is greater than the number of nodes related to instructions that are currently traveling back and forth between PAT Cache120 and traverse section 115, there will always be a process that can complete its processing and release the lock, and the block will eventually be resolved.

[0130] During the process of adding to the waiting list described above, the waiting list of nodes registered in MSHR122a may run out. If the block section 121 of PAT Cache120 is blocked to prevent this list from overflowing, and the process of collecting related nodes has not yet finished, requests to PAT Cache120 will be stopped because block section 121 is blocked, resulting in a deadlock. Therefore, as described above, if it is anticipated that the waiting list will run out, the block section 112 of PAT Requester110 is blocked (S213). In this case, since the block section 121 of PAT Cache120 is not blocked, the round trip of requests and responses between PAT Cache120 and traverse section 115 is not hindered, and related nodes can be collected. However, multiple requests may be in this round trip state, and these may be added to the waiting list. Therefore, the block request to block section 112 of PAT Requester110 is made while there is still some room in the waiting list (when the length of the waiting list reaches a predetermined threshold). Prioritizing the completion of this round trip minimizes the consumption of the waitlist. Therefore, as described above, in PAT Requester 110, Arbiter 116 prioritizes requests from traverse unit 115 over requests from command processing unit 114. The block unit 112 of PAT Requester 110 handles carry-up, update, and evict requests in a way that allows them to be blocked, also for the same reason of minimizing the consumption of the waitlist.

[0131] For example, in Figure 5, after registering (locking) intermediate node N3 with MSHR122a in response to the first access, a wait list is written to intermediate node N3 of MSHR122a in response to the second access. However, if the length of the wait list exceeds a threshold, the block section 121 of PAT Cache120 is not put into a blocked state, but the block section 112 of PAT Requester110 is put into a blocked state. This allows processing of nodes N1 to N4 of the first access to continue. Therefore, as shown in Figure 6, after processing of nodes N1 to N4 of the first access is completed and the locks on nodes N1 to N4 are released, processing of nodes N6, N7, N3, and N4 of the second access can be performed.

[0132] Figure 15 is a flowchart illustrating another example of the operation of PAT Cache 120 shown in Figure 9. PAT Cache 120 may evict a cache line, which is an element of Cache 123a. This is to free up space to read and store a new cache line from memory 200. Figure 15 shows an example of the operation when a cache line is evicted from Cache 123a.

[0133] In the example shown in Figure 15, when the Cache control unit 123b evicts a cache line from Cache 123a, it determines whether the cache line to be evicted is clean or not (S221). If the cache line to be evicted is clean, that is, if the same data as the cache line is stored in memory 200, the Cache control unit 123b deletes this cache line from Cache 123a (S222). This frees up space to read and store a new cache line from memory 200.

[0134] Furthermore, if the cache line to be evicted is dirty, that is, if the data has been modified after being read from memory 200, the Cache control unit 123b must write the cache line back to memory 200. This writing method is similar to the method used to write leaf nodes back from LLC 300 to memory 200.

[0135] In other words, first, the Cache control unit 123b sends the cache line to be written back to the Authenticator 130 (S223). This is the same as when the PAT Requester 110 receives a write-back request for a leaf node from the LLC 300, and this node is sent to the Authenticator 130 via the PAT Cache 120.

[0136] Furthermore, the Cache control unit 123b sends the node address sent to the Authenticator 130 along with an evict request to the Arbiter 111 of the PAT Requester 110 (S224).

[0137] In PAT Requester 110, evict requests, like leaf node requests, pass through block section 112 and MSHR section 113 and are sent to evict processing section 114d. The evict processing section 114d derives the identifier of the parent node of the evicted node and sends it to PAT Cache 120. After that, just like with leaf node requests, a process is executed that travels back and forth between traverse section 115 and PAT Cache 120 until an entry is found that is cached in PAT Cache 120 by an ancestor node or registered in MSHR 122a of PAT Cache 120.

[0138] Here, since the evict request goes through the block section 112 of the PAT Requester 110, if the wait list of a node registered in the MSHR 122a of the PAT Cache 120 becomes low on space and the block section 112 is blocked, this evict request will not be executed by the PAT Requester 110, thus preventing it from putting pressure on the wait list which is running low on space.

[0139] Figure 16 is a flowchart showing another example of the operation of PAT Cache120 shown in Figure 9. Figure 16 shows an example of operation when PAT Cache120 requests Authenticator130 and then receives a verified node from Authenticator130.

[0140] In the example shown in Figure 16, when the MSHR control unit 122b receives a verified node from the Authenticator 130 (S231), it determines whether there is a request in the node's waitlist because this node is registered with MSHR 122a (S232). If there is a request in the waitlist of the registered node, the MSHR control unit 122b sends the node to the traverse unit 115 of the PAT Requester 110 to respond to the request in the waitlist (S233).

[0141] Furthermore, the Cache control unit 123b may store verified nodes in Cache 123a. This storage may cause other cache lines to be evicted. The nodes to be stored may be updated in response to requests from the waitlist.

[0142] Furthermore, the MSHR control unit 122b unregisters the verified node from MSHR122a (S234). That is, it removes the address of the verified node from MSHR122a. If the block unit 121 is set to a blocked state because the number of registered nodes in MSHR122a has reached its limit, the MSHR control unit 122b releases this blocked state (S235). That is, it sets the block unit 121 to a non-blocked state.

[0143] When a node is unregistered from MSHR122a, the node's waitlist is deleted. Therefore, if the length of this node's waitlist has set the block section 112 of PAT Requester110 to a blocked state, the MSHR control unit 122b releases this blocked state (S236). In other words, the block section 112 is set to a non-blocked state.

[0144] Figure 17 is a flowchart illustrating an example of the operation of Authenticator 130 shown in Figure 10. Figure 17 shows an example of operation when receiving node requests and write-back node requests from PAT Cache 120.

[0145] In the example shown in Figure 17, when branch unit 132 receives a request from PAT Cache 120 (S301), it determines whether or not it has received a request for a node to write back to (S302). If it is not a request for a node to write back to (a request for a node), it sends the request for a node to Verifier 140 (S303).

[0146] Furthermore, when a node to be written back is received, the branch unit 132 sends the node to be written back to the converge unit 131, and the converge unit 131 saves the node to be written back (S304).

[0147] Subsequently, the mode of operation unit 137 generates authentication tags for the nodes stored in the converge unit 131 using an encryption protocol (S305). Nodes for which these authentication tags have been generated are flagged to indicate that they are tagged. Furthermore, the mode of operation unit 137 sends the tagged nodes to the Verifier 140 via the Arbiter 134 (S306).

[0148] Figure 18 is a flowchart showing another example of operation for Authenticator 130 shown in Figure 10. Figure 18 shows an example of operation when Authenticator 130 requests Verifier 140 and then receives a verified node from Verifier 140.

[0149] In the example shown in Figure 18, when the branch unit 135 receives a verified node from the Verifier 140 (S311), it determines whether the received node is a node that contains a node counter stored in the converge unit 131 (S312).

[0150] If the received node is not a node that contains a node counter stored in the converge unit 131, the branch unit 135 sends the node to the counter update unit 136, and the counter update unit 136 increments the node's counter if the node is updated (S313). If the value of the minor counter reaches the upper limit at this point, the counter update unit 136 sends a carry-up request to the PAT Requester 110 (S314).

[0151] This request will result in PAT Requester 110 requesting multiple nodes from PAT Cache 120. However, since this request is subject to blocking by the block section 112 of PAT Requester 110, it will be blocked by the block section 112 when the wait list of MSHR 122a in PAT Cache 120 is congested, thus preventing an increase in the number of requests traveling back and forth between PAT Cache 120 and traverse section 115.

[0152] Subsequently, the mode of operation unit 137 generates authentication tags for nodes that require authentication tags using the Encryption Engine 160 (S315). Furthermore, the mode of operation unit 137 sends the nodes for which authentication tags have been generated to the PAT Cache 120 (S316).

[0153] Furthermore, if the node received from Verifier 140 is a node that contains a counter of a node stored in converge unit 131, Arbiter 133 sends the node to converge unit 131, and converge unit 131 supplies the counter of the received node to the child node stored in converge unit 131 (S317). The received node is sent to counter update unit 136, and thereafter is processed in the same way as the node sent to counter update unit 136 as described above (S313~S316).

[0154] Nodes supplied with counters by the convergence unit 131 are also sent to the counter update unit 136 along with these counters. Subsequently, the mode of operation unit 137 generates an authentication tag (S318). The mode of operation unit 137 sends the generated authentication tag (update request) to the Arbiter 111 of the PAT Requester 110 (S319). Furthermore, the mode of operation unit 137 sends the node that generated the authentication tag to the Verifier 140 via the Arbiter 134 (S320). After that, it is written back to memory 200 via the Memory Requester 150 from the Verifier 140.

[0155] Figure 19 is a flowchart illustrating an example of the operation of Verifier 140 shown in Figure 11. Figure 19 shows examples of the operation of Verifier 140 when it receives a request from Authenticator 130, and when it receives a response from Memory Requester 150 after making a request to Memory Requester 150.

[0156] In the example in Figure 19, when Verifier 140 receives a request from Authenticator 130 (S401), it sends the received request directly to Memory Requester 150 (S402).

[0157] Furthermore, when the mode of operation unit 141 receives a response from the Memory Requester 150 (S403), it uses the Encryption Engine 160 to verify the node of the received response according to the cryptographic protocol (S404).

[0158] Next, the Confirm verified unit 142 sets a flag indicating that the verified node is verified and sends it to the Authenticator 130 (S405). The Confirm verified unit 142 confirms that the verified flag is set just before sending.

[0159] Figure 20 is a flowchart showing an example of the operation of Memory Requester 150 as shown in Figure 12. Figure 20 shows an example of operation when a request is received from Authenticator 130 or the traverse unit 115 of PAT Requester 110.

[0160] In the example shown in Figure 20, when the A-tag confirm unit 153 receives a request from the Authenticator 130 (S501), if the received request is accompanied by data, it confirms that a flag indicating that an authentication tag is attached is set (S502), and then sends the received request to the memory 200 (S503). The A-tag confirm unit 153 also sends the received request to the memory 200 if it is not accompanied by data. In all other cases, the A-tag confirm unit 153 generates an error.

[0161] Furthermore, when the converge unit 151 receives information from the traverse unit 115 of the PAT Requester 110 that a certain node is registered in MSHR (S504), it understands that this node will eventually arrive and waits for this node to arrive from the Authenticator 130 (S505). In other words, it can determine which node is the closest ancestor in the set of related nodes.

[0162] Furthermore, when the converge unit 151 receives a node (anchor) from the traverse unit 115 of the PAT Requester 110 (S506), it saves the received node (S507). At this time, the node received from the PAT Requester 110 has been verified.

[0163] Figure 21 is a flowchart showing another example of operation of Memory Requester 150 shown in Figure 12. Figure 21 shows an example of operation when Memory Requester 150 makes a request to memory 200 and receives a response from memory 200.

[0164] In the example shown in Figure 21, when the converge unit 151 receives a response from the memory 200 (S511), it saves the received response (S512). The converge unit 151 processes each saved node A as follows:

[0165] The converge unit 151 determines whether node A is a leaf node or not (S513). If node A is not a leaf node, and its parent node B is also stored and node B has been verified, the converge unit 151 extracts the counter for node A from node B and sends node A, along with the extracted counter, to the Verifier 140 for verification (S514). The converge unit 151 states that node A is being verified (S515).

[0166] Furthermore, if node A is not a leaf node, and node A's parent node B is also stored, and node B is currently being verified, the converge unit 151 extracts node A's counter from node B and sends node A, along with the extracted counter, to the Verifier 140 for verification (S516). The converge unit 151 then marks node A as being verified (S517) and deletes node B (S518).

[0167] Furthermore, if node A is a leaf node, and node T containing node A's authentication tag and node B containing node A's counter are also stored, and node B is verified or in the process of being verified, the converge unit 151 extracts node A's (leaf node's) authentication tag from node T, extracts node A's counter from node B, and sends node A, along with the extracted authentication tag and counter, to Verifier 140 for verification (S519). The converge unit 151 marks node A (leaf node) as being verified (S520) and deletes node B (S521).

[0168] <Effects> As described above, the memory integrity verification unit according to this embodiment includes a mechanism (PAT Requester) equipped with a mechanism (traverse) that sequentially traverses from a given node to its ancestor nodes in the integrity tree, a cache (PAT Cache) that can temporarily store nodes in the integrity tree, and a mechanism (Authenticator) that generates authentication tags. In this memory integrity verification unit, the PAT Cache controls access to the same node by the PAT Requester via MSHR. If the number of nodes that can be registered in MSHR becomes insufficient for this locking, the request receiving port on the PAT Requester side of the PAT Cache is blocked. Furthermore, if the number of requests (waitlist) waiting for a node registered in MSHR exceeds a certain amount, the PAT Requester is blocked. As a result, even if the number of requests waiting for a certain node registered in the PAT Cache's MSHR exceeds a certain amount, it is possible to avoid increasing new processing and stopping the search of the integrity tree. This makes it possible to prevent cache deadlocks while reducing the space of MSHR.

[0169] This disclosure is not limited to the embodiments described above, and may be modified as appropriate without departing from its spirit.

[0170] Each configuration in the above-described embodiment may consist of hardware, software, or both, and may consist of one piece of hardware or software, or multiple pieces of hardware or software. The functions (processing) of the information processing device including the memory integrity verification unit (device) may be realized by a computer 20 having a processor 21 such as a CPU (Central Processing Unit) and a memory 22 which is a storage device, as shown in Figure 22. For example, a program for performing the integrity verification method in the embodiment may be stored in the memory 22, and each function may be realized by executing the program stored in the memory 22 with the processor 21.

[0171] The above program, when loaded into a computer, includes a set of instructions (or software code) for causing the computer to perform one or more of the functions described in the embodiments. The program may be stored on a non-temporary computer-readable medium or a physical storage medium. Examples, but not limited to, include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technologies, CD-ROM, digital versatile disc (DVD), Blu-ray® disc or other optical disc storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices. The program may be transmitted over a temporary computer-readable medium or a communication medium. Examples, but not limited to, include temporary computer-readable medium or a communication medium that includes electrically, optically, acoustically or otherwise propagating signals.

[0172] Although the present disclosure has been described above with reference to embodiments, the present disclosure is not limited to the embodiments described above. Various modifications to the structure and details of the present disclosure can be made as can be understood by those skilled in the art within the scope of the present disclosure. Furthermore, each embodiment can be combined with other embodiments as appropriate.

[0173] Each drawing is merely illustrative to illustrate one or more embodiments. Each drawing may be associated with one or more other embodiments rather than with only one specific embodiment. As those skilled in the art will understand, various features or steps described with reference to any one drawing can be combined with features or steps shown in one or more other drawings, for example, to create embodiments not explicitly shown or described. Not all features or steps shown in any one drawing to illustrate an exemplary embodiment are necessarily required, and some features or steps may be omitted. The order of steps shown in any of the drawings may be changed as appropriate.

[0174] Some or all of the above embodiments may also be described as follows, but are not limited to the following: (Note 1) A memory integrity verification device that verifies the integrity of data between cache memory and memory, A tree cache that temporarily stores data assigned to nodes in an integrity tree that includes nodes arranged in a tree structure, A request processing unit receives a request from the cache memory for a leaf node in the completeness tree and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. Equipped with, The tree cache includes a first registration unit that locks the intermediate nodes to exclusively control the search requests for the same intermediate node, and registers a wait request for each locked intermediate node. The request processing unit includes a first blocking unit that blocks requests to be received by the request processing unit according to the number of waiting requests registered in the first registration unit. Memory integrity verification device. (Note 2) The first blocking unit blocks requests to be received by the request processing unit when the number of waiting requests registered in the first registration unit is greater than a predetermined threshold. The predetermined threshold is smaller than the maximum number of waiting requests that can be registered in the first registration unit. The memory integrity verification device described in Appendix 1. (Note 3) The tree cache includes a second blocking unit that blocks requests accepted in the tree cache in proportion to the number of locked intermediate nodes in the first registration unit. A memory integrity verification device as described in Appendix 1 or 2. (Note 4) The second blocking unit blocks requests accepted by the tree cache when the number of locked intermediate nodes in the first registration unit reaches the maximum number of intermediate nodes that can be locked in the first registration unit. The memory integrity verification device described in Appendix 3. (Note 5) The aforementioned first registration unit is the MSHR (Miss Status Holding Register). A memory integrity verification device as described in Appendix 1 or 2. (Note 6) The request processing unit includes a second registration unit that locks the leaf node to exclusively control requests from the cache memory to the same leaf node, and registers a waiting request for each locked leaf node. A memory integrity verification device as described in Appendix 1 or 2. (Note 7) The first block unit blocks requests to be received by the request processing unit according to the number of locked leaf nodes in the second registration unit, or the number of waiting requests registered in the second registration unit. The memory integrity verification device described in Appendix 6. (Note 8) The first blocking unit blocks requests accepted by the request processing unit when the number of locked leaf nodes in the second registration unit reaches the maximum number of leaf nodes that can be locked in the second registration unit, or when the number of waiting requests registered in the second registration unit reaches the maximum number of waiting requests that can be registered in the second registration unit. The memory integrity verification device described in Appendix 7. (Note 9) The second registration unit is the MSHR (Miss Status Holding Register). The memory integrity verification device described in Appendix 6. (Note 10) The tree cache requests the request processing unit to remove the temporarily stored data. The request processing unit executes requests from the tree cache with priority over requests from the cache memory. A memory integrity verification device as described in Appendix 1 or 2. (Note 11) The system includes an authentication unit that generates an authentication tag to be assigned to the node and requests the request processing unit to update the counter assigned to the node. The request processing unit prioritizes executing requests from the authentication unit over requests from the cache memory. A memory integrity verification device as described in Appendix 1 or 2. (Note 12) If the request processing unit encounters a conflict with another request for searching for an intermediate node in the tree cache, it will prioritize executing the request for searching for an intermediate node over the other request. A memory integrity verification device as described in Appendix 1 or 2. (Note 13) Cache memory and Memory and The system includes a memory integrity verification unit that verifies the integrity of data between the cache memory and the memory, The memory integrity verification unit, A tree cache that temporarily stores data assigned to nodes in an integrity tree that includes nodes arranged in a tree structure, A request processing unit receives a request from the cache memory for a leaf node in the completeness tree and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. Equipped with, The tree cache includes a first registration unit that locks the intermediate nodes to exclusively control the search requests for the same intermediate node, and registers a wait request for each locked intermediate node. The request processing unit includes a first blocking unit that blocks requests to be received by the request processing unit according to the number of waiting requests registered in the first registration unit. Information processing device. (Note 14) A memory integrity verification method for verifying data integrity between cache memory and memory, The tree cache temporarily stores data assigned to nodes in an integrity tree, which includes nodes arranged in a tree structure, in the tree cache. The request processing unit receives a request from the cache memory for a leaf node in the completeness tree, and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. In order to exclusively control the search requests for the same intermediate node, the intermediate node is locked, and a wait request is registered for each locked intermediate node. Depending on the number of registered waiting requests, the request processing unit blocks the requests it accepts. Method for verifying memory integrity. (Note 15) A program for a memory integrity verification device that verifies the integrity of data between cache memory and memory, The tree cache temporarily stores data assigned to nodes in an integrity tree, which includes nodes arranged in a tree structure, in the tree cache. The request processing unit receives a request from the cache memory for a leaf node in the completeness tree, and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. In order to exclusively control the search requests for the same intermediate node, the intermediate node is locked, and a wait request is registered for each locked intermediate node. Depending on the number of registered waiting requests, the request processing unit blocks the requests it accepts. A program that causes a computer to perform a process.

[0175] Some or all of the elements (e.g., configuration and function) described in Appendices 2 to 12 that are subordinate to Appendice 1 (Memory Integrity Verification Device) may also be subordinate to Appendice 13 (Information Processing Device), Appendice 14 (Memory Integrity Verification Method), and Appendice 15 (Program) in the same way as those described in Appendices 2 to 12. Some or all of the elements described in any appendice may be applied to various hardware, software, recording means, systems, and methods for recording software. [Explanation of symbols]

[0176] 1. Information Processing Device 10. Memory Integrity Verification Device 11 Tree Cache 12 Request Processing Unit 13 Registration Department 14 Block Section 20 Computers 21 processors 22 memory 100 Memory Integrity Verification Unit 110 PAT Requester 111 Arbiter 112 block part 113 MSHR Department 113a MSHR 113b MSHR Control Unit 114 Command Processing Unit 114a leaf processing unit 114b Carry-up processing unit 114c update processing unit 114d evict processing section 115 traverse section 120 PAT Cache 121 block part 122 MSHR Department 122a MSHR 122b MSHR Control Unit 123 Cache section 123a Cache 123b Cache Control Unit 130 Authenticator 131 converge part 132 branch part 133 Arbiter 134 Arbiter 135 branch part 136 counter update section 137 Mode of Opera 138 Arbiter 140 Verifier 141 Mode of operation section 142 Confirm verification section 150 Memory Requesters 151 converge part 152 Arbiters 153 A-tag confirm section 160 Encryption Engine 200 memory 201 memory bus 300 LLC 301 LLC Bus

Claims

1. A memory integrity verification device that verifies the integrity of data between cache memory and memory, A tree cache that temporarily stores data assigned to nodes in an integrity tree that includes nodes arranged in a tree structure, A request processing unit receives a request from the cache memory for a leaf node in the completeness tree and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. Equipped with, The tree cache includes a first registration unit that locks the intermediate nodes to exclusively control the search requests for the same intermediate node, and registers a wait request for each locked intermediate node. The request processing unit includes a first blocking unit that blocks requests to be received by the request processing unit according to the number of waiting requests registered in the first registration unit. Memory integrity verification device.

2. The first blocking unit blocks requests to be received by the request processing unit when the number of waiting requests registered in the first registration unit is greater than a predetermined threshold. The predetermined threshold is smaller than the maximum number of waiting requests that can be registered in the first registration unit. The memory integrity verification device according to claim 1.

3. The tree cache includes a second blocking unit that blocks requests accepted in the tree cache in proportion to the number of locked intermediate nodes in the first registration unit. A memory integrity verification device according to claim 1 or 2.

4. The second blocking unit blocks requests accepted by the tree cache when the number of locked intermediate nodes in the first registration unit reaches the maximum number of intermediate nodes that can be locked in the first registration unit. The memory integrity verification device according to claim 3.

5. The first registration unit is an MSHR (Miss Status Holding Register). A memory integrity verification device according to claim 1 or 2.

6. The request processing unit includes a second registration unit that locks the leaf node to exclusively control requests from the cache memory to the same leaf node, and registers a waiting request for each locked leaf node. A memory integrity verification device according to claim 1 or 2.

7. The first block unit blocks requests to be received by the request processing unit according to the number of locked leaf nodes in the second registration unit, or the number of waiting requests registered in the second registration unit. The memory integrity verification device according to claim 6.

8. The first blocking unit blocks requests received by the request processing unit when the number of locked leaf nodes in the second registration unit reaches the maximum number of leaf nodes that can be locked in the second registration unit, or when the number of waiting requests registered in the second registration unit reaches the maximum number of waiting requests that can be registered in the second registration unit. The memory integrity verification device according to claim 7.

9. The second registration unit is an MSHR (Miss Status Holding Register). The memory integrity verification device according to claim 6.

10. The tree cache requests the request processing unit to remove the temporarily stored data. The request processing unit executes requests from the tree cache with priority over requests from the cache memory. A memory integrity verification device according to claim 1 or 2.

11. The system includes an authentication unit that generates an authentication tag to be assigned to the node and requests the request processing unit to update the counter assigned to the node. The request processing unit prioritizes executing requests from the authentication unit over requests from the cache memory. A memory integrity verification device according to claim 1 or 2.

12. If the request processing unit encounters a conflict with another request for searching for an intermediate node in the tree cache, it will prioritize executing the request for searching for an intermediate node over the other request. A memory integrity verification device according to claim 1 or 2.

13. Cache memory and Memory and The system includes a memory integrity verification unit that verifies the integrity of data between the cache memory and the memory, The memory integrity verification unit, A tree cache that temporarily stores data assigned to nodes in an integrity tree that includes nodes arranged in a tree structure, A request processing unit receives a request from the cache memory for a leaf node in the completeness tree and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. Equipped with, The tree cache includes a first registration unit that locks the intermediate nodes to exclusively control the search requests for the same intermediate node, and registers a wait request for each locked intermediate node. The request processing unit includes a first blocking unit that blocks requests to be received by the request processing unit according to the number of waiting requests registered in the first registration unit. Information processing device.

14. A memory integrity verification method for verifying data integrity between cache memory and memory, The tree cache temporarily stores data assigned to nodes in an integrity tree, which includes nodes arranged in a tree structure, in the tree cache. The request processing unit receives a request from the cache memory for a leaf node in the completeness tree, and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. In order to exclusively control the search requests for the same intermediate node, the intermediate node is locked, and a wait request is registered for each locked intermediate node. Depending on the number of registered waiting requests, the request processing unit blocks the requests it accepts. Method for verifying memory integrity.

15. A program for verifying data integrity between cache memory and memory, The tree cache temporarily stores data assigned to nodes in an integrity tree, which includes nodes arranged in a tree structure, in the tree cache. The request processing unit receives a request from the cache memory for a leaf node in the completeness tree, and requests the tree cache to search for an intermediate node from the leaf node to the root node in the completeness tree. In order to exclusively control the search requests for the same intermediate node, the intermediate node is locked, and a wait request is registered for each locked intermediate node. Depending on the number of registered waiting requests, the request processing unit blocks the requests it accepts. A program that causes a computer to perform a process.

Images