Data security processing method, memory controller and system for non-volatile memory

Abstract

The present invention discloses a data security processing method, a memory controller and a system for non-volatile memory, belonging to the field of memory security technology, including: constructing a traditional BMT as the Back_BMT, constructing a BMT with a certain layer of nodes as leaf nodes as the Fore_BMT, and the Back_BMT subtree and the NVM space corresponding to its leaf nodes are Region_BMT and the region respectively; when writing the data block B back from the CPU to the NVM, reading the counter of B from the Back_BMT and updating it, then updating the Region_BMT corresponding to the region R to which B belongs, and adding the Region_BMT to the protection of the Fore_BMT; encrypting B and then writing it into the NVM; adding the Region_BMT to the protection of the Fore_BMT, including: if there is no corresponding leaf node in the Fore_BMT, preferentially allocating an idle or synchronized leaf node from the Fore_BMT, if the allocation is unsuccessful, selecting a leaf node Fore_Victim from the Fore_BMT, updating the Back_BMT according to Fore_Victim, and then updating the Fore_BMT with the Region_BMT. The present invention can ensure the recoverability of metadata crashes in the secure NVM and reduce the overhead of updating the BMT root node.

Description

Technical Field

[0001] The present invention belongs to the technical field of memory security, and more specifically, relates to a data security processing method, a memory controller, and a system for non-volatile memory. Background Art

[0002] Non-volatile memory (NVM) has attracted much attention from memory system researchers due to its excellent characteristics such as high density, byte-addressability, and data persistent storage. Different from volatile dynamic random access memory (DRAM), the data stored on NVM will not be lost even after the system power-off, which enables attackers to more easily damage the security of the data on NVM through means such as data stealing and malicious modification. Therefore, efficient security protection is essential for the NVM memory system.

[0003] In a secure NVM system, any data on the CPU chip is considered secure and trustworthy, while any data not on the chip is considered untrusted. The data not on the chip mainly includes the data on the NVM memory and the memory bus. Data confidentiality and integrity are two main aspects of memory data security, which are respectively guaranteed by counter mode encryption (CME) and bonsai Merkle tree (BMT) verification in the current secure NVM design. As Figure 1 shown, in CME, each data cache line has a corresponding counter. Whenever data is written to or read from the NVM for a data cache line, it is XORed with a unique one-time pad (OTP) for data encryption or decryption. The OTP is generated using the encrypted counter corresponding to the data cache line, the data address, and other elements. When the same data block is encrypted, the counter is incremented to ensure the temporal uniqueness of the OTP. As Figure 2 shown in (a) of, BMT is an advanced integrity tree structure constructed by layer-by-layer hash calculation with the encrypted counters in CME as leaf nodes. The BMT root node is used to reflect the latest status of all counters in the NVM, and it is stored in the on-chip secure persistent register. The counters read from the memory must be verified by the BMT root first. To improve the performance of the secure NVM, the existing secure NVM design usually adds a volatile secure metadata cache in the on-chip memory controller to cache the frequently accessed BMT leaf counter nodes and other BMT intermediate nodes.

[0004] However, it is not easy to implement CME and BMT in secure NVM because the non-volatility of NVM makes it possible to instantly resume memory, which requires the secure metadata BMT (including leaf counter nodes and other intermediate nodes) to be correctly and quickly restored after a system crash. To this end, the update of the root node of BMT needs to be completed atomically with the data write request to ensure the correctness of BMT restoration and the security of the system. The number of nodes in BMT will increase as the size of the NVM memory increases. The larger the NVM, the higher the BMT level and the higher the update overhead of the BMT root. When any data cache line is written back from the CPU cache to the NVM, the entire corresponding BMT path up to the root node needs to be updated, as shown in (b) of Figure 2 as shown in (b) of

[0005] This is very unfriendly to NVMs sensitive to write performance. For example, for a 16GB secure NVM, BMT can reach 9 levels. When using a hash calculation engine with an 80 CPU clock cycle, 720 CPU clock cycles are required to complete the BMT root update corresponding to each data write request. For TB-level NVMs, the atomic update overhead of the BMT root will be even higher.

[0006] 1) Some of the existing work only considers how to implement the crash recovery of BMT and reduce the persistent overhead brought by the crash recovery mechanism, ignoring the overhead problem of the atomic update of the BMT root;

[0007] 2) Some of the existing work reduces the BMT root update overhead caused by hot pages through a hot tree with fewer levels, but has a high overhead for cold and hot page identification and tree node replacement;

[0008] 3) In order to achieve fast system recovery, the existing work often requires a long recovery time or a relatively large NVM write traffic overhead.

[0009] Generally speaking, in non-volatile memory systems, how to reduce the overhead of BMT root update on the premise of achieving fast secure metadata crash recovery is an issue to be studied. Summary of the Invention

[0010] In view of the deficiencies of the prior art and the improvement requirements, the present invention provides a data security processing method, a memory controller and a system for non-volatile memory, aiming to reduce the overhead of BMT root node update on the premise of ensuring the crash recoverability of metadata in secure NVM.

[0011] To achieve the above object, according to one aspect of the present invention, there is provided a data security processing method for non-volatile memory, including:

[0012] An initialization step, including: constructing a Merkle tree with the counter of the data cache line as the leaf node as Back_BMT, taking the subtree with the node in the specified layer as the root node as Region_BMT, and the non-volatile memory space corresponding to each Region_BMT as a region; initializing another Merkle tree, denoted as Fore_BMT, whose leaf nodes are the root nodes of Region_BMT, and the total number of leaf nodes does not exceed the threshold N;

[0013] A BMT update step, including:

[0014] (S1) For the Region_BMT that needs to be added to the protection of Fore_BMT, that is, RBMTB, determine whether there is a corresponding leaf node in Fore_BMT. If so, go to step (S3); otherwise, go to step (S2);

[0015] (S2) Determine whether there are idle or synchronized-to-Back_BMT leaf nodes in Fore_BMT. If so, allocate a leaf node for RBMTB from these leaf nodes and go to step (S3); otherwise, allocate a leaf node as Fore_Victim for RBMTB, update Back_BMT according to Fore_Victim, and then go to step (S3);

[0016] (S3) Update Fore_BMT using RBMTB;

[0017] And a write-back step, including: when writing the data block B from the CPU back to the non-volatile memory, read and update the counter of the data block B to be written from Back_BMT, then update the Region_BMT corresponding to the region R to which the data block B belongs, and add the Region_BMT to the protection of Fore_BMT through the BMT update step; encrypt the data block B using the updated counter and write the obtained ciphertext into the non-volatile memory.

[0018] As the system runs, the number and data addresses of data written back from the CPU cache to the memory are different in different time periods, and the data blocks written back by an application at a certain moment do not occupy all the memory space. Especially for NVM at the TB level, the private data written back by users only accounts for a very small proportion of the memory most of the time. The present invention constructs Back_BMT in the construction manner of traditional BMT, and on this basis, constructs Fore_BMT with a region (usually the size of multiple cache lines) as the allocation granularity to store the counters corresponding to the data blocks recently written back by the current system. Along with the user's memory write request, it only dynamically constructs and modifies Fore_BMT, without the need to update the entire Back_BMT every time data is written back, thereby making Fore_BMT only cover the memory area involved in the current write pre-request as much as possible, effectively reducing the BMT level, and accelerating the update of the BMT root on the premise of ensuring the recoverability of metadata crashes in secure NVM.

[0019] Furthermore, the data security processing method for non-volatile memory provided by the present invention further includes: maintaining a specified number of cache line counters in the on-chip persistent register;

[0020] Moreover, in the write-back step, before reading the counter of the data block B to be written from Back_BMT, it further includes:

[0021] (T1) Search for the counter of data block B in the persistent register. If it hits, go to step (T4); otherwise, go to step (T2);

[0022] (T2) Select a cache line Reg_Victim to be replaced from the persistent register, and atomically replace Reg_Victim with the leaf node where the counter of data block B is located read from Back_BMT;

[0023] (T3) Update the corresponding Region_BMT with Reg_Victim, and add the Region_BMT to the protection of Fore_BMT using the BMT update step;

[0024] (T4) Update the counter of data block B in the persistent register, encrypt data block B using the updated counter, write the obtained ciphertext into the non-volatile memory, and then end the write-back step.

[0025] The present invention maintains a counter for a partial cache line in a persistent register, and when data is written back, it preferentially looks up the corresponding counter in the persistent register. In the case of a hit, the counter is directly updated in the persistent register without updating the BMT node in the persistent memory, thereby effectively reducing the number of accesses to non-volatile memory during the data write-back process and improving the execution efficiency of data write-back. In addition, in a secure NVM, adjacent data write-backs will cause adjacent counter updates, and adjacent counter updates will cause a large number of identical BMT node updates. Due to the effect of load locality and the CPU cache, memory data write requests exhibit strong spatial locality, resulting in these repeated BMT update operations usually occurring in consecutive write requests. The present invention caches some counters using a persistent register, which can merge the BMT updates caused by counter updates in adjacent regions, realizing a batch update, further reducing the update overhead of the BMT root caused by write requests and improving the system performance.

[0026] Furthermore, the data security processing method for non-volatile memory provided by the present invention further includes:

[0027] A node recovery step, including:

[0028] For a lost node in Back_BMT or Fore_BMT, if it is a leaf node, it is recovered using ECC during the system crash recovery phase;

[0029] If it is an intermediate node, its recovery is postponed until a replay attack is detected after the system restarts; when accessing the intermediate node to be recovered after the system restarts, the root node stored on the chip will detect a replay attack; at this time, the node is recovered; during recovery, the hash values of each node on the accessed path are recalculated using the current counter on the accessed path until the root node, and the calculated root node is compared with the root node stored on the chip. If the two are consistent, the intermediate nodes on the path are recovered using the calculated node values; if the two are inconsistent, it is determined that a real replay attack has occurred in the system.

[0030] The present invention delays the recovery of lost intermediate nodes in the BMT until an attack is detected after the system restarts, thereby reducing the recovery operations required after the system crashes and restarts, reducing the recovery time, and ensuring the availability of the system after it crashes and restarts.

[0031] Furthermore, the data security processing method for non-volatile memory provided by the present invention further includes:

[0032] The pre - synchronization step includes: identifying leaf nodes in Fore_BMT that have not been accessed in M consecutive memory write requests, and adding them to the synchronization queue; when the BMT engine is not occupied by foreground memory read - write requests, using the BMT engine to synchronize the Fore_BMT leaf nodes in the synchronization queue to the root node of Back_BMT. If a memory access occurs during the synchronization process, the synchronization terminates.

[0033] Where M is a preset positive integer.

[0034] In a secure NVM, the BMT engine is only used by foreground requests when a small number of read requests cause counter cache misses and write requests cause batch update register misses. At other times, the BMT engine is in an unused state. The pre - synchronization step of the present invention can well improve the utilization rate of the BMT engine by identifying leaf nodes in Fore_BMT that have not been accessed in M consecutive memory write requests, adding them to the synchronization queue, and synchronizing the Fore_BMT leaf nodes in the synchronization queue to the root node of Back_BMT when the BMT engine is not occupied by foreground memory read - write requests. Without affecting memory read - write requests, it can synchronize Fore_BMT leaf nodes that have not been used for too long to Back_BMT in advance, so that when processing write requests subsequently, it is very likely that only the update of the Fore_BMT root will occur on the critical path of the write request, and there is no need to update the Back_BMT root, further reducing the delay of BMT update during the write request process and improving the system performance.

[0035] Furthermore, the initialization step further includes: establishing a leaf node status table for recording the status information of each leaf node in Fore_BMT; the status information includes the area number corresponding to the leaf node, the total number of system memory write requests at the last update, and a state flag bit, where the state flag bit is used to indicate whether the leaf node is idle and whether it has been synchronized to Back_BMT.

[0036] And in the pre - synchronization step, by periodically scanning the leaf node status table, Fore_BMT leaf nodes that have not been accessed in M consecutive memory write requests are identified.

[0037] The present invention establishes a leaf node status table for recording the status information of each leaf node in Fore_BMT, so that in the pre - synchronization step, by periodically scanning this status table, leaf nodes that have not been used for too long can be conveniently and quickly identified. In addition, during the data write - back process, by querying this status table, it can be conveniently and quickly determined whether there are idle or already synchronized leaf nodes in Fore_BMT.

[0038] Furthermore, in step (S2) of the BMT update step, if there is no idle leaf node in Fore_BMT or a leaf node that has been synchronized to Back_BMT, the method of allocating a leaf node to RBMTB as Fore_Victim is as follows:

[0039] Randomly read K consecutive status information entries from the leaf node status table, and identify the Fore_BMT leaf node that has not been updated for the longest time from them, and allocate it to RBMTB as Fore_Victim; K is a preset positive integer.

[0040] Due to the temporal locality of access, the leaf node in Fore_BMT that has not been updated for the longest time is less likely to be accessed subsequently. When there is no idle leaf node in Fore_BMT or a leaf node that has been synchronized to Back_BMT, the present invention scans the leaf node status table and identifies the Fore_BMT leaf node that has not been updated for the longest time from some consecutive entries as the replacement node, which can make full use of the temporal locality of access, ensure that the counter corresponding to the data block recently written back by the current system is protected by Fore_BMT, and reduce the exchange frequency between Fore_BMT and Back_BMT.

[0041] Furthermore, the initialization step further includes: establishing a region index table for recording the protection information of each region in the non-volatile memory; the protection information includes: a Fore / Back flag bit for indicating whether the region is protected by Fore_BMT, and the order of the Fore_BMT leaf nodes corresponding to the region;

[0042] Moreover, in step (S1) of the BMT update step, for Region_BMT that needs to be added to the protection of Fore_BMT, that is, RBMTB, the method of determining whether there is a corresponding leaf node in Fore_BMT includes:

[0043] Determine the region corresponding to RBMTB, and look up the entry corresponding to this region in the region index table. If the Fore / Back flag bit therein indicates that the region is protected by Fore_BMT, it is determined that there is a corresponding leaf node in Fore_BMT; otherwise, it is determined that there is no corresponding leaf node in Fore_BMT.

[0044] In the present invention, different from the storage order determination of Back_BMT and its binding with corresponding data blocks, the order of leaf nodes of Fore_BMT and the corresponding data area change dynamically with memory write requests. When writing data back to the NVM area, the positioning process of the corresponding Fore_BTM leaf nodes will directly affect the write performance. The present invention records whether each area in the non-volatile memory is protected by Fore_BMT and the order of the corresponding Fore_BTM leaf nodes by establishing a region index table, so that when writing data back to the NVM, the corresponding Fore_BTM leaf nodes can be quickly located by querying the region index table, effectively improving the write performance of the system.

[0045] According to another aspect of the present invention, there is provided a memory controller for non-volatile memory, including: an initialization module, a BMT update module, and a write-back module;

[0046] The initialization module is used to execute initialization steps; the initialization steps include: constructing a Merkle tree with the counters of all data blocks as leaf nodes, denoted as Back_BMT, taking the subtree with the nodes in the specified layer as the root nodes as Region_BMT, and taking the corresponding non-volatile memory space of each Region_BMT as an area; initializing another Merkle tree, denoted as Fore_BMT, whose leaf nodes are the root nodes of Region_BMT, and the total number of leaf nodes does not exceed the threshold N;

[0047] The BMT update module is used to execute BMT update steps; the BMT update steps include:

[0048] (S1) For the Region_BMT that needs to be added to the protection of Fore_BMT, that is, RBMTB, judge whether there is a corresponding leaf node in Fore_BMT. If so, go to step (S3); otherwise, go to step (S2);

[0049] (S2) Judge whether there are idle or already synchronized leaf nodes to Back_BMT in Fore_BMT. If so, allocate a leaf node for RBMTB from these leaf nodes and go to step (S3); otherwise, allocate a leaf node as Fore_Victim for RBMTB, and after updating Back_BMT according to Fore_Victim, go to step (S3);

[0050] (S3) Update Fore_BMT with RBMTB;

[0051] A write-back module for performing a write-back step; the write-back step includes: when writing data block B from the CPU back to the non-volatile memory, reading the counter of the data block B to be written from the Back_BMT and updating it, then updating the Region_BMT corresponding to the region R to which the data block B belongs, and adding the Region_BMT to the Fore_BMT protection through the BMT update step; encrypting the data block B using the updated counter and writing the obtained ciphertext to the non-volatile memory.

[0052] Further, the memory controller for non-volatile memory provided by the present invention further includes: a persistent register for caching a specified number of cache line counters;

[0053] Moreover, in the write-back step, before reading the counter of the data block B to be written from the Back_BMT, it further includes:

[0054] (T1) Search for the counter of data block B in the persistent register. If a hit occurs, transfer to step (T4); otherwise, transfer to step (T2);

[0055] (T2) Select a cache line Reg_Victim to be replaced from the persistent register, and atomically replace Reg_Victim with the leaf node where the counter of data block B is located read from the Back_BMT;

[0056] (T3) Update the corresponding Region_BMT using Reg_Victim, and add the Region_BMT to the Fore_BMT protection using the BMT update step;

[0057] (T4) Update the counter of data block B in the persistent register, encrypt the data block B using the updated counter, write the obtained ciphertext to the non-volatile memory, and then end the write-back step.

[0058] According to another aspect of the present invention, a security processing system for non-volatile memory is provided, including: a non-volatile memory and the above-mentioned memory controller provided by the present invention;

[0059] The non-volatile memory is divided into a DR metadata storage area, a BMT node storage area, and a secure user data storage area; the DR metadata storage area is used to store DR metadata, and the DR metadata includes a leaf node status table and a region index table; the BMT node storage area is used to store BMT nodes, and the BMT nodes are nodes in the Fore_BMT or Back_BMT; the secure user data storage area is used to store encrypted user data;

[0060] The memory controller further includes: a CPU cache, a security engine, a security metadata cache, a DR cache, and a battery-supported NVM write queue;

[0061] A security metadata cache for caching some BMT nodes;

[0062] A DR cache for caching some DR metadata;

[0063] A CPU cache for caching plaintext and outputting the plaintext to the security engine or reading the plaintext from the security engine;

[0064] A security engine, which, when a data write request is received, accepts the plaintext output by the CPU cache, encrypts the plaintext according to a counter, outputs the ciphertext to a battery-backed NVM write queue, and updates the BMT nodes according to the counter;

[0065] The security engine is also used, when a data read request is received, to read the ciphertext from the NVM write queue, decrypt the plaintext according to the counter, and output the plaintext to the CPU cache; during the encryption and decryption processes, if the required counter is obtained from the security metadata cache, it is directly used for data encryption and decryption, and if it is obtained from the NVM memory, BMT verification is first performed;

[0066] A battery-backed NVM write queue for receiving the ciphertext output by the security engine and outputting the encrypted user data to the secure user data storage area in the NVM;

[0067] The battery-backed NVM write queue is also used for receiving the BMT nodes output by the security metadata cache and outputting the BMT to the BMT node storage area in the NVM;

[0068] The battery-backed NVM write queue is also used for receiving the DR metadata output by the DR cache and outputting the DR metadata to the DR metadata storage area in the NVM;

[0069] Among them, a leaf node status table is used to record the status information of each leaf node in the Fore_BMT; the status information includes the area number corresponding to the leaf node, the total number of system memory write requests at the last update, and a state flag bit, and the state flag bit is used to indicate whether the leaf node is idle and whether it has been synchronized to the Back_BMT; a region index table is used to record the protection information of each region in the non-volatile memory; the protection information includes: a Fore / Back flag bit for indicating whether the region is protected by the Fore_BMT, and the order of the Fore_BMT leaf nodes corresponding to the region.

[0070] Generally speaking, through the above technical solutions conceived by the present invention, the following beneficial effects can be achieved:

[0071] (1) The present invention proposes a dynamically recoverable BMT structure based on user memory requirements, whose update method is adapted to the load access characteristics, effectively alleviating the problem that the existing secure NVM system has a high atomic update overhead of the BMT root, or the problem that the method of reducing the atomic update overhead of the BMT root has high complexity, and greatly reducing the overhead and complexity of the atomic update of the BMT root.

[0072] (2) The fast BMT recovery method based on delayed recovery proposed by the present invention effectively alleviates the problem that the existing secure NVM system has a long recovery time, or the problem that the method of accelerating system recovery has a large NVM write traffic overhead, and realizes the fast recovery of the secure NVM system while reducing the write traffic overhead. Brief Description of the Drawings

[0073] Figure 1 It is a schematic diagram of the existing Counter Mode Encryption (CME);

[0074] Figure 2 It is a schematic diagram of the existing Bosai Merkle Tree (BMT) and a schematic diagram of the data write-back process in a traditional secure NVM; among them, (a) is a schematic diagram of the traditional BMT, and (b) is a schematic diagram of the data write-back process based on the BMT shown in (a);

[0075] Figure 3 It is a schematic diagram of the Fore_BMT provided by an embodiment of the present invention;

[0076] Figure 4 It is a schematic diagram of the Region_BMT, Back_BMT, and Fore_BMT provided by an embodiment of the present invention;

[0077] Figure 5 It is a schematic diagram of the leaf node status table and the area index provided by an embodiment of the present invention; among them, (a) is a schematic diagram of the leaf node status, and (b) is a schematic diagram of the area index;

[0078] Figure 6 It is a schematic diagram of the data write-back process provided by an embodiment of the present invention;

[0079] Figure 7 It is a schematic diagram of the secure processing system for non-volatile memory provided by an embodiment of the present invention. Detailed Embodiment

[0080] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0081] In the present invention, the terms "first", "second", etc. (if any) in the present invention and the accompanying drawings are used to distinguish similar objects and do not necessarily describe a specific order or sequence.

[0082] In order to reduce the BMT root update overhead on the premise of achieving fast and secure metadata crash recovery in a non-volatile memory system, the present invention provides a data security processing method, a memory controller and a system for non-volatile memory. The overall idea is as follows: Modify the BMT structure and update method based on the application memory requirements and access characteristics, and make the BMT only cover the memory area involved in the current pre-write request as much as possible, so as to reduce the BMT level and accelerate the update of the BMT root.

[0083] The following are the embodiments.

[0084] Embodiment 1:

[0085] A data security processing method for non-volatile memory. In this embodiment, the traditional BMT structure is modified based on the application memory requirements and access characteristics, specifically as Figure 3 shown.

[0086] In this embodiment, two types of BMTs are constructed, namely Back_BMT and Fore_BMT. Among them, Back_BMT is similar to the BMT in the traditional secure NVM, and is a high-level integrity tree structure constructed by layer-by-layer hash calculation with the cache line counter as the leaf node; it should be noted that in NVM, data is stored in the form of data blocks, and each data block has its corresponding counter, and a cache line is composed of multiple data blocks.

[0087] As the system runs, the number of data items and their addresses written back from the CPU cache to memory in different time periods are not the same. More importantly, the data blocks written back by an application at a certain moment do not occupy all of the memory space. Especially for NVM at the TB level, the private data written back by users only accounts for a very small proportion of the memory most of the time. Based on this feature of secure NVM, in this embodiment, Fore_BMT is constructed on the basis of Back_BMT to protect the integrity of the data blocks written back by the current system recently. There is node exchange between Fore_BMT and Back_BMT. To reduce the exchange frequency, in this embodiment, the update of the leaf nodes of Fore_BMT is performed with regions as the allocation granularity. Specifically, one layer in Back_BMT is designated as the allocation layer, and the subtree with the nodes in this allocation layer as the root nodes is used as Region_BMT. The NVM storage space corresponding to the leaf nodes of a Region_BMT is a region, and a leaf node of Fore_BMT is the root node of a Region_BMT; when the load memory write request exceeds the current region, the addition of nodes in Fore_BMT will be triggered, which may lead to the exchange between Fore_BMT and Back_BMT; optionally, in this embodiment, the region size is 32KB. Compared with Back_BMT, Fore_BMT adopts a coarse-grained allocation scheme. To effectively reduce the levels of BMT, in this embodiment, the number of leaf nodes of Fore_BMT is limited to no more than 512. In this embodiment, the storage of Region_BMT, Fore_BMT and Back_BMT in the NVM memory is as Figure 4 shown.

[0088] For Figure 3 and Figure 4 the BMT structures shown, this embodiment correspondingly proposes BMT update steps, which specifically include:

[0089] The BMT update steps include:

[0090] (S1) For the Region_BMT that needs to be protected by Fore_BMT, denoted as RBMTB, determine whether there is a corresponding leaf node in Fore_BMT. If so, it means that the region corresponding to this Region_BMT has been protected by Fore_BMT, and then go to step (S3); otherwise, it means that the region corresponding to this Region_BMT has not been protected by Fore_BMT, and go to step (S2);

[0091] (S2) Determine whether there are idle leaf nodes in Fore_BMT or leaf nodes that have been synchronized to Back_BMT. If so, allocate a leaf node for RBMTB from these leaf nodes and proceed to step (S3); otherwise, allocate a leaf node as Fore_Victim for RBMTB, update Back_BMT according to Fore_Victim, and then proceed to step (S3);

[0092] (S3) Update Fore_BMT using RBMTB; specifically, update the value of the corresponding leaf node in Fore_BMT to the hash value of the root node of RBMTB, and then update the hash values of the nodes on the path from this leaf node to the Fore_BMT root through layer-by-layer hashing until the root node of Fore_BMT is updated.

[0093] Based on the above BMT update steps, in this embodiment, the write-back step of writing data from the CPU back to NVM includes: when writing data block B from the CPU back to non-volatile memory, read and update the counter of data block B to be written from Back_BMT, then update Region_BMT corresponding to the region R to which data block B belongs, and add this Region_BMT to Fore_BMT protection through the BMT update step; encrypt data block B using the updated counter and write the obtained ciphertext to non-volatile memory.

[0094] In this embodiment, since only the data blocks written back to the current system most recently are used to construct Fore_BMT for integrity protection, compared with Back_BMT, the level of Fore_BMT is greatly reduced. Figure 3 For example, each write-back data write-induced BMT root update will be reduced from 5 hash calculations in the traditional BMT to 3 times, effectively reducing the overhead of BMT root update; it should be noted that the allocation granularity of Fore_BMT and the allocation layer in Back_BMT can be flexibly set according to the actual load characteristics.

[0095] In the above write-back step, when performing Fore_BMT replacement in this embodiment, the unused or Fore_BMT leaf nodes that have been synchronized to Back_BMT are preferentially selected, so that on the critical path of the data write request, there is a high probability that only the Fore-BMT root will be updated, and there will be no Back_BMT root update, thereby effectively reducing the swap overhead. In addition, in the secure NVM system, there is a security engine, which specifically includes an encryption engine for data encryption and decryption, and a BMT engine for BMT verification. Only when the counter cache misses caused by a small number of read requests and the batch update register misses caused by write requests occur, the BMT engine will be used by the foreground request. Based on this, in this embodiment, further through the early synchronization step, when the BMT engine is idle, the Fore_BMT leaf nodes that have not been used for a long time are synchronized to Back_BMT in advance, rather than waiting until it is replaced from Fore-BMT to synchronize, so as to reduce the number of updates to the Back_BMT root during Fore_BMT replacement. In this embodiment, the early synchronization step includes: identifying the leaf nodes in Fore_BMT that have not been accessed in M consecutive memory write requests and adding them to the synchronization queue; when the BMT engine is not occupied by the foreground memory read and write requests, using the BMT engine to synchronize the Fore_BMT leaf nodes in the synchronization queue to the root node of Back_BMT, and if a memory access occurs during the synchronization process, the synchronization terminates;

[0096] where M is a preset positive integer; optionally, in this embodiment, M = 64; through the early synchronization step, when allocating new Fore-BMT leaf nodes, the already synchronized leaf nodes will be evicted, thereby improving the utilization rate of the BMT engine and reducing the number of updates to the Back_BMT root during Fore_BMT replacement.

[0097] To support the early synchronization step to be completed conveniently and quickly, in this embodiment, the Fore_BMT is designed as follows Figure 5The leaf node status table shown in (a) in [document] is used to record the status information of each leaf node in Fore_BMT; the status information includes: the region number corresponding to the leaf node, denoted as R_num; the total number of memory write requests of the system when the leaf node was last updated, denoted as tick; the state flag bit, which is used to indicate whether the leaf node is idle and whether it has been synchronized to Back_BMT. In this embodiment, the state flag bit is specifically represented by 2 bits of data, where 00 indicates unused, 01 indicates in use but already synchronized to Back_BMT, and 10 indicates in use but not yet synchronized to Back_BMT; for each leaf node, R_num and tick are recorded in the form of an R_num-Tick pair, and each R_num-Tick pair occupies 64 bits.

[0098] Based on the maintained leaf node status table, in the early synchronization step of this embodiment, by periodically scanning the leaf node status table, Fore_BMT leaf nodes that have not been accessed in 64 consecutive memory write requests are identified.

[0099] When a leaf node with a state flag bit of 10 has not been accessed in 64 consecutive memory write requests, the leaf node will be added to the synchronization queue, and the background synchronization process will synchronize it to Back_BMT. After synchronization is completed, the corresponding state flag bit will be modified to 01 to indicate that the Fore_BMT leaf node is in use but already synchronized to Back_BMT.

[0100] Since the number of Fore-BMT leaf nodes is limited (default not exceeding 512), the storage overhead of the leaf node status table is very small.

[0101] Based on the maintained leaf node status table, in step (S2) of the BMT update step of this embodiment, when there are no idle or already synchronized-to-Back_BMT leaf nodes in Fore_BMT, the method of allocating a leaf node for RBMTB as Fore_Victim is as follows:

[0102] Randomly read K consecutive status information entries from the leaf node status table, and identify the Fore_BMT leaf node that has not been updated for the longest time from them, that is, the leaf node corresponding to the entry with the smallest Tick, and allocate it to RBMTB as Fore_Victim; K is a preset positive integer. Preferably, the specific value of K is set according to the maximum data size read by the read request and the size of a single status information entry to ensure that the required K consecutive status information entries can be obtained through one read operation; optionally, in this embodiment, the value of K is 8.

[0103] Due to the temporal locality of access, the leaf node in Fore_BMT that has not been updated for the longest time is less likely to be accessed subsequently. When there are no idle leaf nodes or leaf nodes that have been synchronized to Back_BMT in Fore_BMT, by scanning the leaf node status table, the present invention identifies the Fore_BMT leaf node that has not been updated for the longest time from some consecutive entries as the replacement node, which can make full use of the temporal locality of access, ensure that the counter corresponding to the data block recently written back by the current system is protected by Fore_BMT, and reduce the exchange frequency between Fore_BMT and Back_BMT.

[0104] In this embodiment, different from the storage order of Back_BMT being determined and bound to the corresponding data block, the order of the leaf nodes of Fore_BMT and the corresponding data area change dynamically with the memory write request. When writing data back to the NVM area, the positioning process of the corresponding Fore_BMT leaf node will directly affect the writing performance. To address this problem, this embodiment also designs a region index table as shown in (b) of Figure 5 to record the protection information of each area in the non-volatile memory, where "region" represents the area. The protection information includes: a Fore / Back flag bit used to indicate whether the area is protected by Fore_BMT. In this embodiment, the Fore / Back flag bit occupies 1 bit. When an area is protected by Fore_BMT, its Fore / Back flag bit is set to 1, and when an area is evicted from Fore_BMT, its Fore / Back flag bit is set to 0; and the order of the Fore_BMT leaf nodes corresponding to the area. In this embodiment, this information is represented by DR-Index, and DR-Index occupies at most 9 bits, and this information is only meaningful when the area is protected by Fore_BMT.

[0105] Based on the designed region index table, in this embodiment, in (S1) of the BMT update step, for Region_BMT that needs to be added to the protection of Fore_BMT, that is, RBMTB, the method for determining whether there is a corresponding leaf node in Fore_BMT includes:

[0106] Determine the area corresponding to RBMTB, and look up the entry corresponding to this area in the region index table. If the Fore / Back flag bit in it indicates that the area is protected by Fore_BMT, that is, Fore / Back = 1, it is determined that there is a corresponding leaf node in Fore_BMT; otherwise, that is, Fore / Back = 0, it is determined that there is no corresponding leaf node in Fore_BMT.

[0107] In the NVM system, the above-mentioned leaf node status table and region index table can be used as DR metadata and cached on-chip to accelerate their access. The DR metadata is stored directly in plain text, just like the security metadata. To ensure correct recovery, any modification to R_num in the leaf node status table needs to be written back to the NVM.

[0108] It is easy to understand that during the data write-back process, Fore_BMT and Back_BMT will be updated. When the BMT is updated, the relevant information in the leaf node status table and region index table will also be updated synchronously.

[0109] To alleviate the problem that the existing secure NVM system has a long recovery time or the method for accelerating system recovery has a large NVM write traffic overhead, in the node recovery step adopted in this embodiment, the recovery of the lost intermediate nodes will be delayed until an attack is detected after the system restarts. The node recovery step specifically includes:

[0110] For the lost nodes in Back_BMT or Fore_BMT, if they are leaf nodes, they will be recovered using ECC during the system crash recovery phase;

[0111] If they are intermediate nodes, their recovery will be postponed until a replay attack is detected after the system restarts. When accessing the intermediate node to be recovered after the system restarts, the root node stored on-chip will detect the replay attack. At this time, the node will be recovered. When recovering, the hash values of each node on the accessed path will be recalculated using the current counter on the path until the root node. The calculated root node will be compared with the root node stored on-chip. If they are the same, the intermediate nodes on the path will be recovered using the calculated node values. If they are different, it is determined that a real replay attack has occurred in the system. If a real replay attack is detected, the system service will be suspended and an attack report will be reported.

[0112] In this embodiment, the recovery of the lost intermediate nodes in the BMT is delayed until an attack is detected after the system restarts, thereby reducing the recovery operations that need to be performed after the system crashes and restarts, reducing the recovery time, and ensuring the availability of the system after it crashes and restarts.

[0113] Embodiment 2:

[0114] A data security processing method for non-volatile memory. This embodiment is similar to the above-mentioned Embodiment 1, except that this embodiment further includes maintaining a specified number of cache line counters in the on-chip persistent register, and when writing back data, preferentially searching for the corresponding counter in the persistent register. In the case of a hit, directly update the counter in the persistent register and encrypt the data before writing it back; in the case of a miss, read the required counter from the Back_BMT and evict a cache line counter from the persistent register to cache the read counter. The cache line counter evicted from the persistent register will be added to the protection of the Fore_BMT; as Figure 6 shown, the write-back step of this embodiment specifically includes:

[0115] ① Check whether the corresponding counter hits in the batch update persistent register;

[0116] ② If the persistent register is hit, only update the counter in the persistent register and the metadata cache, and then encrypt the data and write it back;

[0117] ③ If the persistent register is not hit, read the required counter from the Back_BMT and cache it in the persistent register. At the same time, evict a counter node Reg_Victim from the persistent register and update the Region-BMT according to Reg_Victim. Query the region index table to determine whether this Reg_Victim belongs to the protection of the Fore_BMT;

[0118] ④ If Reg_Victim belongs to the protection of the Fore_BMT, atomically update the Fore_BMT root, then update the counter in the persistent register, and encrypt the data and write it back;

[0119] ⑤ If Reg_Victim does not belong to the protection of the Fore_BMT, a Fore-BMT replacement occurs; when replacing, first query the leaf node status table to determine whether there is an idle or already synchronized-to-Back_BMT leaf node in the Fore_BMT that can be used as the replacement node Fore_Victim;

[0120] ⑥ If there is an idle or already synchronized-to-Back_BMT leaf node that can be used as the replacement node Fore_Victim, directly modify the region index table and the leaf node status table for replacement, where the R_num in the status needs to be written back to the NVM to ensure recovery;

[0121] ⑦ If there is no idle leaf node or a leaf node that has been synchronized to Back_BMT can be used as the replacement node Fore_Victim, randomly read 8 consecutive entries in the leaf node status table, and select the Fore_BMT leaf node with the smallest Tick as Fore_Victim. At this time, it will trigger the atomic update of the Back_BMT root caused by Fore_Victim; when the Fore_BMT replacement is completed, update the Fore-BMT according to Reg_Victim, and finally update the counter in the persistent register, and encrypt the data and write it back.

[0122] Compared with the traditional BMT, this embodiment greatly reduces the number of hash calculations required for the BMT root update caused by data writing.

[0123] In this embodiment, by maintaining the counters of some cache lines in the persistent register, and when writing back data, preferentially searching for the corresponding counters in the persistent register. In the case of a hit, directly update the counters in the persistent register without updating the BMT nodes in the persistent memory. This can effectively reduce the number of accesses to non-volatile memory during the data write-back process and improve the execution efficiency of data write-back. In addition, in the secure NVM, adjacent data write-backs will cause adjacent counter updates, and adjacent counter updates will cause a large number of identical BMT node updates. Due to the effect of load locality and CPU cache, the memory data write requests show strong spatial locality, resulting in these repeated BMT update operations usually occurring in consecutive write requests. This embodiment uses the persistent register to cache some counters, which can merge the BMT updates caused by the counter updates in adjacent regions, realizing a batch update, further reducing the update overhead of the BMT root caused by write requests, and improving the system performance.

[0124] Embodiment 3:

[0125] A memory controller for non-volatile memory, this embodiment is used to execute the steps in the above Embodiment 2; this embodiment includes: a persistent register, an initialization module, a BMT update module, and a write-back module;

[0126] The persistent register is used to cache the counters of a specified number of cache lines;

[0127] The initialization module is used to execute the initialization steps in the above Embodiment 2;

[0128] The BMT update module is used to execute the BMT update steps in the above Embodiment 2;

[0129] The write-back module is used to execute the write-back steps in the above Embodiment 2;

[0130] In this embodiment, for the specific implementation manners of each module, reference may be made to the description in Embodiment 2 above, which will not be repeated here.

[0131] Embodiment 3:

[0132] A security processing system for non-volatile memory, such as Figure 7 as shown, includes: a non-volatile memory and the memory controller provided in Embodiment 2 above;

[0133] As Figure 7 shown, in this embodiment, the non-volatile memory is divided into a DR metadata storage area, a BMT node storage area, and a secure user data storage area; the DR metadata storage area is used to store DR metadata, and the DR metadata includes a leaf node status table and a region index table; the BMT node storage area is used to store BMT nodes, and the BMT nodes are nodes in Fore_BMT or Back_BMT; the secure user data storage area is used to store encrypted user data;

[0134] In this embodiment, the memory controller further includes: a CPU cache, a security engine, a security metadata cache, a DR cache, and a battery-backed NVM write queue;

[0135] The security metadata cache is used to cache some BMT nodes;

[0136] The DR cache is used to cache some DR metadata;

[0137] The CPU cache is used to cache plaintext and output the plaintext to the security engine or read the plaintext from the security engine;

[0138] The security engine includes an encryption engine for data encryption and decryption, and a BMT engine for BMT verification;

[0139] The security engine is used, when a data write request is received, to accept the plaintext output by the CPU cache, encrypt the plaintext according to a counter, output the ciphertext to the battery-backed NVM write queue, and update the BMT nodes according to the counter;

[0140] The security engine is further used, when a data read request is received, to read the ciphertext from the NVM write queue, decrypt the plaintext according to the counter, and output the plaintext to the CPU cache; during the encryption and decryption processes, if the required counter is obtained from the security metadata cache, it is directly used for data encryption and decryption, and if it is obtained from the NVM memory, BMT verification is first performed;

[0141] The battery-backed NVM write queue is used to receive the ciphertext output by the security engine and output the encrypted user data to the secure user data storage area in the NVM;

[0142] The battery - supported NVM write queue is also used for the BMT node that receives the output of the security metadata cache, and outputs the BMT to the BMT node storage area in the NVM;

[0143] The battery - supported NVM write queue is also used for receiving the DR metadata output by the DR cache, and outputs the DR metadata to the DR metadata storage area in the NVM.

[0144] Those skilled in the art can easily understand that the above is only a preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present invention should be included within the protection scope of the present invention.

Claims

1. A data security processing method for non-volatile memory, characterized in that Including: Initialization step, including: constructing a Merkle tree with the counter of the data cache line as the leaf node as Back_BMT, taking the subtree with the node in the specified layer as the root node as Region_BMT, and the non-volatile memory space corresponding to each Region_BMT as a region; initializing another Merkle tree, denoted as Fore_BMT, whose leaf nodes are the root nodes of Region_BMT, and the total number of leaf nodes does not exceed the threshold N; BMT update step, including: (S1) For the Region_BMT that needs to be added to the protection of Fore_BMT, that is, RBMTB, determine whether there is a corresponding leaf node in Fore_BMT. If so, go to step (S3); otherwise, go to step (S2); (S2) Determine whether there are idle or already synchronized leaf nodes to Back_BMT in Fore_BMT. If so, allocate a leaf node for RBMTB from these leaf nodes and go to step (S3); otherwise, allocate a leaf node as Fore_Victim for RBMTB, and after updating Back_BMT according to Fore_Victim, go to step (S3); (S3) Update Fore_BMT using RBMTB; And the write-back step, including: when writing the data block B from the CPU back to the non-volatile memory, read the counter of the data block B to be written from Back_BMT and update it, then update the Region_BMT corresponding to the region R to which the data block B belongs, and add this Region_BMT to the protection of Fore_BMT through the BMT update step; encrypt the data block B using the updated counter and write the obtained ciphertext to the non-volatile memory.

2. The data security processing method for non-volatile memory according to claim 1, wherein Also including: Maintaining a specified number of cache line counters in the on-chip persistent register; And, in the write-back step, before reading the counter of the data block B to be written from Back_BMT, it also includes: (T1) Search for the counter of the data block B in the persistent register. If a hit occurs, go to step (T4); Otherwise, go to step (T2); (T2) Select a cache line Reg_Victim to be replaced from the persistent register, and atomically replace Reg_Victim with the leaf node where the counter of the data block B is located read from Back_BMT; (T3) Update the corresponding Region_BMT using Reg_Victim, and add this Region_BMT to the protection of Fore_BMT through the BMT update step; (T4) Update the counter of the data block B in the persistent register, encrypt the data block B using the updated counter, write the obtained ciphertext to the non-volatile memory, and then end the write-back step.

3. The data security processing method for non-volatile memory according to claim 1 or 2, characterized in that, Also including: Node recovery step, including: For the lost node in Back_BMT or Fore_BMT, if it is a leaf node, use ECC to recover it during the system crash recovery phase; If it is an intermediate node, its recovery is postponed until a replay attack is detected after the system restarts; during recovery, the hash values of each node on the accessed path are recalculated using the current counter on the accessed path until the root node, and the calculated root node is compared with the root node stored on the chip. If the two are consistent, the intermediate nodes on the path are recovered using the calculated node values; If they are inconsistent, it is determined that a real replay attack has occurred in the system.

4. The data security processing method for non-volatile memory according to claim 3, wherein It further includes: An early synchronization step, including: identifying leaf nodes in Fore_BMT that have not been accessed in M consecutive memory write requests and adding them to the synchronization queue; when the BMT engine is not occupied by foreground memory read / write requests, using the BMT engine to synchronize the Fore_BMT leaf nodes in the synchronization queue to the root node of Back_BMT. If a memory access occurs during the synchronization process, the synchronization terminates; where M is a preset positive integer.

5. The data security processing method for non-volatile memory according to claim 4, wherein The initialization step further includes: establishing a leaf node status table for recording the status information of each leaf node in Fore_BMT; the status information includes the area number corresponding to the leaf node, the total number of system memory write requests at the last update, and a state flag bit, where the state flag bit is used to indicate whether the leaf node is idle and whether it has been synchronized to Back_BMT; Moreover, in the early synchronization step, by periodically scanning the leaf node status table, Fore_BMT leaf nodes that have not been accessed in M consecutive memory write requests are identified.

6. The data security processing method for non-volatile memory according to claim 5, wherein In (S2) of the BMT update step, if there are no idle or synchronized-to-Back_BMT leaf nodes in Fore_BMT, the method of allocating a leaf node to RBMTB as Fore_Victim is: Randomly read K consecutive status information entries from the leaf node status table, and identify the Fore_BMT leaf node that has not been updated for the longest time from them, and allocate it to RBMTB as Fore_Victim; K is a preset positive integer.

7. The data security processing method for non-volatile memory according to claim 6, characterized in that, The initialization step further includes: establishing a region index table for recording the protection information of each region in the non-volatile memory; the protection information includes: a Fore / Back flag bit for indicating whether the region is protected by Fore_BMT, and the order of the Fore_BMT leaf nodes corresponding to the region; Moreover, in (S1) of the BMT update step, for Region_BMT that needs to be added to the protection of Fore_BMT, that is, RBMTB, the method of determining whether there is a corresponding leaf node in Fore_BMT includes: Determine the region corresponding to RBMTB, and look up the entry corresponding to this region in the region index table. If the Fore / Back flag bit therein indicates that the region is protected by Fore_BMT, it is determined that there is a corresponding leaf node in Fore_BMT; otherwise, it is determined that there is no corresponding leaf node in Fore_BMT.

8. A memory controller for non-volatile memory, characterized in that It includes: An initialization module, a BMT update module, and a write-back module; The initialization module is used to perform an initialization step; The initialization step includes: constructing a Merkle tree with the counters of all data blocks as leaf nodes, denoted as Back_BMT, taking the subtree with nodes in the specified layer as the root node as Region_BMT, and the non-volatile memory space corresponding to each Region_BMT as a region; initializing another Merkle tree, denoted as Fore_BMT, whose leaf nodes are the root nodes of Region_BMT, and the total number of leaf nodes does not exceed the threshold N; The BMT update module is used to perform a BMT update step; the BMT update step includes: (S1) For the Region_BMT that needs to be added to the protection of Fore_BMT, i.e., RBMTB, determine whether there is a corresponding leaf node in Fore_BMT. If so, go to step (S3); otherwise, go to step (S2); (S2) Determine whether there are idle or synchronized-to-Back_BMT leaf nodes in Fore_BMT. If so, allocate a leaf node for RBMTB from these leaf nodes and go to step (S3); otherwise, allocate a leaf node for RBMTB as Fore_Victim, update Back_BMT according to Fore_Victim, and then go to step (S3); (S3) Update Fore_BMT using RBMTB; The write-back module is used to perform a write-back step; the write-back step includes: when writing the data block B from the CPU back to the non-volatile memory, read and update the counter of the data block B to be written from Back_BMT, then update the Region_BMT corresponding to the region R to which the data block B belongs, and add the Region_BMT to the protection of Fore_BMT through the BMT update step; encrypt the data block B using the updated counter and write the obtained ciphertext into the non-volatile memory.

9. The memory controller for non-volatile memory according to claim 8, wherein It further includes: a persistent register for caching a specified number of cache line counters; Moreover, in the write-back step, before reading the counter of the data block B to be written from Back_BMT, it further includes: (T1) Search for the counter of the data block B in the persistent register. If a hit occurs, go to step (T4); otherwise, go to step (T2); (T2) Select a cache line to be replaced, Reg_Victim, from the persistent register, and atomically replace Reg_Victim with the leaf node where the counter of the data block B is located read from Back_BMT; (T3) Update the corresponding Region_BMT using Reg_Victim, and add the Region_BMT to the protection of Fore_BMT through the BMT update step; (T4) Update the counter of the data block B in the persistent register, encrypt the data block B using the updated counter, write the obtained ciphertext into the non-volatile memory, and then end the write-back step.

10. A security processing system for non-volatile memory, characterized in that, It includes: A non-volatile memory and a memory controller as claimed in claim 9; The non-volatile memory is divided into a DR metadata storage area, a BMT node storage area, and a secure user data storage area; The DR metadata storage area is used to store DR metadata, and the DR metadata includes a leaf node status table and a region index table; The BMT node storage area is used to store BMT nodes, and the BMT nodes are nodes in Fore_BMT or Back_BMT; The secure user data storage area is used to store encrypted user data; The memory controller further includes: a CPU cache, a security engine, a security metadata cache, a DR cache, and a battery-backed NVM write queue; The security metadata cache is used to cache some BMT nodes; The DR cache is used to cache some DR metadata; The CPU cache is used to cache plaintext and output the plaintext to the security engine or read the plaintext from the security engine; The security engine is used, when a data write request is received, to receive the plaintext output by the CPU cache, encrypt the plaintext according to a counter, output the ciphertext to the battery-backed NVM write queue, and update the BMT nodes according to the counter; The security engine is further used, when a data read request is received, to read the ciphertext from the NVM write queue, decrypt the plaintext according to the counter, and output the plaintext to the CPU cache; during the encryption and decryption processes, if the required counter is obtained from the security metadata cache, it is directly used for data encryption and decryption, and if it is obtained from the NVM memory, a BMT verification is first performed; The battery-backed NVM write queue is used to receive the ciphertext output by the security engine and output the encrypted user data to the secure user data storage area in the NVM; The battery-backed NVM write queue is further used to receive the BMT nodes output by the security metadata cache and output the BMT to the BMT node storage area in the NVM; The battery-backed NVM write queue is further used to receive the DR metadata output by the DR cache and output the DR metadata to the DR metadata storage area in the NVM; Wherein, the leaf node status table is used to record the status information of each leaf node in Fore_BMT; the status information includes the region number corresponding to the leaf node, the total number of memory write requests of the system at the last update, and a state flag bit, and the state flag bit is used to indicate whether the leaf node is idle and whether it has been synchronized to Back_BMT; the region index table is used to record the protection information of each region in the non-volatile memory; the protection information includes: a Fore / Back flag bit used to indicate whether the region is protected by Fore_BMT, and the order of the Fore_BMT leaf nodes corresponding to the region.

Images