Data integrity verification method, chip and electronic equipment

Abstract

The invention discloses a data integrity verification method, a chip and electronic equipment, and relates to the technical field of information. The method is applied to a chip, the chip comprises a processor, a storage controller and a storage device, and the method comprises the following steps: responding to a read operation for a read-only partition through the processor, issuing a corresponding data request to the storage controller, and issuing the data request to the storage device through the storage controller, the method comprises the steps of feeding back target data to a storage controller in response to a data request through storage equipment, performing hash calculation on the target data through the storage controller to obtain an actual hash value corresponding to the target data, and performing integrity verification on the target data based on the actual hash value through the storage controller or a processor to obtain the integrity of the target data. And obtaining an integrity verification result of the target data. According to integrity verification of the read-only partition, calculation of the hash value is solidified in the storage controller, so that the software overhead time is saved, and the reading efficiency of the read-only partition can be improved.

Description

Technical Field

[0001] The present application relates to the field of information technology, and more specifically, to a data integrity verification method, a chip, and an electronic device. Background Art

[0002] The security of the file system is crucial to the operating system. Usually, the protection of the file system is mostly aimed at the read-write file system, while the protection of the read-only file system is ignored. However, in some fields and projects, especially on some embedded devices with limited storage capacity, there is often no need to write data during use, and read-only file systems are often used. Therefore, once attackers break into these read-only file systems through vulnerabilities and other means, they may be able to download and execute illegal programs, implant Trojans in the system to steal system information, and destroy the system operating environment, which seriously threatens the security of the operating system. Summary of the invention

[0003] In view of the above problems, the present application proposes a data integrity verification method, chip and electronic device to solve the above problems.

[0004] In a first aspect, an embodiment of the present application provides a method for verifying data integrity, which is applied to a chip, wherein the chip includes a processor, a storage controller, and a storage device, and the method includes: in response to a read operation on a read-only partition file, the processor sends a corresponding data request to the storage controller; the storage controller sends the data request to the storage device; the storage device feeds back target data to the storage controller in response to the data request; the storage controller performs a hash calculation on the target data to obtain an actual hash value corresponding to the target data; the storage controller or the processor performs an integrity check on the target data based on the actual hash value to obtain an integrity check result of the target data.

[0005] In a second aspect, an embodiment of the present application provides a method for verifying data integrity, which is applied to a storage controller of a chip, wherein the chip also includes a processor and a storage device, and the method includes: receiving a data request issued by the processor, wherein the data request is generated by the processor in response to a read operation on a read-only partition file; issuing the data request to the storage device, and receiving target data fed back by the storage device in response to the data request; performing a hash calculation on the target data to obtain an actual hash value corresponding to the target data; performing an integrity check on the target data based on the actual hash value to obtain an integrity check result of the target data, or performing an integrity check on the target data by the processor to obtain an integrity check result of the target data.

[0006] In a third aspect, an embodiment of the present application provides a chip including a processor, a storage controller, and a storage device, and the chip is used to execute the above-mentioned data integrity verification method.

[0007] In a fourth aspect, an embodiment of the present application provides an electronic device, which includes the above-mentioned chip.

[0008] The data integrity verification method, chip and electronic device provided in the embodiments of the present application respond to the read operation on the read-only partition by the processor of the chip, send the corresponding data request to the storage controller of the chip, send the data request to the storage device of the chip by the storage controller, feedback the target data to the storage controller by the storage device in response to the data request, perform hash calculation on the target data by the storage controller to obtain the actual hash value corresponding to the target data, perform integrity verification on the target data based on the actual hash value by the storage controller or the processor to obtain the integrity verification result of the target data, so as to improve the read efficiency of the read-only partition by saving software overhead time by solidifying the calculation of the hash value in the storage controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0010] Figure 1 A schematic diagram showing a flow chart of a data integrity verification method provided by an embodiment of the present application;

[0011] Figure 2 A schematic diagram of a data integrity verification method according to an embodiment of the present invention is shown;

[0012] Figure 3 This application shows Figure 2 The flowchart of step S220 of the data integrity verification method shown is as follows;

[0013] Figure 4 This application shows Figure 2 The flowchart of step S230 of the data integrity verification method shown is as follows;

[0014] Figure 5 This application shows Figure 2 The flowchart of step S270 of the data integrity verification method shown is as follows;

[0015] Figure 6 A schematic diagram showing a specific implementation of an embodiment of the present application;

[0016] Figure 7 A schematic diagram of a data integrity verification method according to an embodiment of the present invention is shown;

[0017] Figure 8 This application shows Figure 7 The flowchart of step S320 of the data integrity verification method shown is as follows;

[0018] Fig. 9 This application shows Figure 7 The flowchart of step S330 of the data integrity verification method shown is as follows;

[0019] Fig.10 This application shows Figure 7 The flowchart of step S370 of the data integrity verification method shown is as follows;

[0020] Fig.11 A schematic diagram showing a specific implementation of another embodiment of the present application;

[0021] Fig.12 A flow chart of a data integrity verification method provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0023] Among them, since the read-only file system will seriously threaten the security of the operating system when it is attacked by attackers through loopholes and other means, the protection of the read-only file system is crucial. At present, the read-only partition data is generally detected by performing integrity check on the read-only partition data to determine whether the read-only file system is safe.

[0024] At present, the integrity check of read-only partitions is generally implemented through the dm-verity software driver, where dm-verity is a target of dm (device mapper), a virtual block device, specifically used for file system verification. The main function of dm-verity is to perform integrity check on read-only file systems to ensure the integrity and consistency of the file system at startup, thereby improving the security of the device.

[0025] Taking the hash algorithm sha256 as an example, the principle is as follows:

[0026] Each 4K block in the read-only partition will have a 32-byte hash checksum calculated when the packet is sent.

[0027] When a read IO occurs in the read-only partition, the hash value calculation of the data block is performed in the return interrupt context of the IO or further deferred to the asynchronous thread.

[0028] If the checksum does not match the checksum calculated when the packet is shot, the data in the read-only partition is considered unreliable and EIO is returned.

[0029] Among them, since the hash value of the current technical solution is calculated by the kernel thread, when the CPU is highly loaded or other high-priority threads are executed for a long time, the thread may not get enough execution opportunities, resulting in a longer time to complete the calculation. For example, the hardware interrupt reaches the CPU at 1.000000s, and after the hard interrupt is processed, the work of calculating the hash value is forwarded to the kernel daemon thread. In extreme cases, the kernel daemon thread may not start to execute the calculation until after 1.100000s. In this case, the overall IO time is stretched to more than 100ms from the upper layer's point of view. Therefore, calculating the hash value in the soft interrupt will slow down the interrupt processing speed, and calculating the hash value in the asynchronous thread will lengthen the time it takes for the file system to return when the CPU is highly loaded, and even cause the entire machine to freeze.

[0030] In view of the above problems, the inventors have discovered after long-term research and proposed a data integrity verification method, chip and electronic device provided in the embodiments of the present application. The integrity verification of the read-only partition saves software overhead time by solidifying the calculation of the hash value in the storage controller, and can improve the read efficiency of the read-only partition. The specific data integrity verification method is described in detail in the subsequent embodiments.

[0031] See also Figure 1 , Figure 1 The flowchart of the data integrity verification method provided by an embodiment of the present application is shown. The method is used for integrity verification of read-only partitions. By solidifying the calculation of hash values ​​in the storage controller, software overhead time is saved, and the read efficiency of read-only partitions can be improved. In a specific embodiment, the data integrity verification method is applied to a chip, which includes a processor, a storage controller, and a storage device. Figure 1 The process shown is described in detail, and the data integrity verification method may specifically include the following steps:

[0032] Step S110: In response to a read operation on a read-only partition file, the processor sends a corresponding data request to the storage controller.

[0033] The data integrity verification method may be applied to a chip, which may include a processor, a storage controller, and a storage device.

[0034] Optionally, the processor may include one or more processing cores. The processor uses various interfaces and lines to connect various parts of the entire chip, and executes various functions of the chip and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory, and calling data stored in the memory. Optionally, the processor can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing the content to be displayed; and the modem is used to handle wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor, but may be implemented separately through a communication chip.

[0035] Optionally, the storage controller may include a Universal Flash Storage (UFS) controller, an Embedded Multi Media Card (EMMC) controller, etc., which is not limited here.

[0036] Optionally, the storage device may include a universal flash memory storage device (UFSDevice), an embedded multimedia memory card storage device (EMMC Device), etc., which is not limited here.

[0037] It can be understood that, when the storage device is a UFS Device, the storage controller may be a UFS controller, and when the storage device is an EMMC Device, the storage controller may be an EMMC controller.

[0038] In this embodiment, when an application or system process needs to read data in a read-only partition, a read operation on the read-only partition file can be initiated. Accordingly, the chip can respond to the read operation on the read-only partition file through the processor and send a corresponding data request to the storage controller.

[0039] In some implementations, when an application or system process initiates a read operation for a read-only partition, the processor can detect whether the file requested by the read operation is on the read-only partition, and if it is detected that the file exists on the read-only partition, the physical location of the file (block address on the storage device) can be calculated, and then a data request containing the address and size of the data block to be read is generated, and the data request is sent to the storage controller.

[0040] In some implementations, the processor may send a data request to a storage controller via a system bus (eg, PCI-E, SATA, etc.).

[0041] Step S120: Sending the data request to the storage device through the storage controller.

[0042] In this embodiment, when the storage controller receives the data request sent by the processor, the storage controller may send the data request to the storage device.

[0043] In some embodiments, when the storage controller receives a data request sent by the processor, it can parse the data request, determine the type of request (read or write) and the data block address specified in the request, prepare corresponding control signals and data formats, and then the storage controller sends these control signals and data formats to the storage device.

[0044] In some implementations, the storage controller may send a data request to the storage device via an internal bus or interface (such as SATA, SAS, PCIe, etc.).

[0045] Step S130: Feedback target data to the storage controller via the storage device in response to the data request.

[0046] In this embodiment, when the storage device receives a data request sent by the storage controller, it can search for corresponding target data in response to the data request and feed back the found target data to the storage controller.

[0047] In some embodiments, after receiving a data request from a storage controller, the storage device can parse the data block address in the data request, locate the specified data block address, and read the corresponding target data. When the target data is read, the storage device can load the target data from the storage medium into an internal buffer and transmit it back to the storage controller.

[0048] In some implementations, the storage device may feed the target data back to the storage controller via an internal bus or interface (such as SATA, SAS, PCIe, etc.).

[0049] Step S140: performing hash calculation on the target data by the storage controller to obtain an actual hash value corresponding to the target data.

[0050] In this embodiment, when the storage controller receives the target data fed back by the storage device, it can perform hash calculation on the target data to obtain the actual hash value corresponding to the target data.

[0051] In some embodiments, the hash calculation may use an algorithm called a hash function, which may convert the target data into a hash value of a fixed length. Based on this, the storage controller may use the selected hash function to calculate the target data to generate an actual hash value corresponding to the target data.

[0052] Optionally, selectable hash functions include MD5, SHA-1, SHA-256, etc., which are not limited here.

[0053] It can be understood that this embodiment performs hash calculation in the storage controller so that the hash value calculation is completed by the auxiliary hardware circuit. After the hardware interrupt reaches the CPU, the IO completion process is directly triggered and will not be affected by the CPU scheduling problem. Therefore, the reading efficiency of the read-only partition under high load can be improved as a whole.

[0054] Step S150: performing integrity check on the target data based on the actual hash value through the storage controller or the processor to obtain an integrity check result of the target data.

[0055] Among them, in the process of data storage and transmission, it is crucial to ensure the integrity of the data. Therefore, when the actual hash value of the target data is calculated by the storage controller, the target data can be checked for integrity based on the actual hash value by the storage controller or the processor to verify whether the target data has been tampered with or damaged during the transmission or storage process. Therefore, in this embodiment, when the actual hash value of the target data is calculated by the storage controller, the target data can continue to be checked for integrity based on the actual hash value by the storage controller to obtain the integrity check result of the target data. Alternatively, when the actual hash value of the target data is calculated by the storage controller, the target data can be checked for integrity based on the actual hash value by the processor to obtain the integrity check result of the target data.

[0056] It is understandable that in data communication or storage systems, data integrity verification can be used to ensure the accuracy and reliability of data. Hash values ​​are widely used for data integrity verification because of their unique properties (such as determinism, unidirectionality, and collision resistance). In this embodiment, the actual hash value represents the unique identification of the target data in the current state, and the storage controller or processor can use the actual hash value to compare with the expected hash value to perform an integrity check, wherein the expected hash value can be a previously stored hash value associated with the target data, or a hash value obtained from other reliable sources. Among them, if the actual hash value completely matches the expected hash value, it indicates that the target data has not changed during the transmission or storage process, and the data is complete. If it does not match, it indicates that the data may have been tampered with or damaged, and the data is incomplete.

[0057] In some implementations, when the integrity check result of the target data is obtained, different subsequent operations can be triggered according to different integrity check results. Optionally, if the integrity check result indicates that the target data is complete and has not been tampered with or damaged, the end request process of the file system can be directly called; if the integrity check result indicates that the target data is incomplete, tampered with or damaged, error correction can be attempted, and when the error correction fails or is not corrected, a request failure status mark can be set, and the end request process of the file system can be called.

[0058] An embodiment of the present application provides a method for verifying data integrity. In response to a read operation on a read-only partition, the processor of the chip sends a corresponding data request to the storage controller of the chip. The storage controller sends the data request to the storage device of the chip. The storage device feeds back target data to the storage controller in response to the data request. The storage controller performs hash calculation on the target data to obtain an actual hash value corresponding to the target data. The storage controller or the processor performs integrity verification on the target data based on the actual hash value to obtain an integrity verification result of the target data. Thus, for the integrity verification of the read-only partition, by solidifying the calculation of the hash value in the storage controller, software overhead time is saved, and the reading efficiency of the read-only partition can be improved.

[0059] See also Figure 2 , Figure 2 The flowchart of the method for data integrity verification provided by an embodiment of the present application is shown. The method is applied to the above chip, which includes a processor, a storage controller and a storage device. Figure 2 The process shown is described in detail, and the method for data integrity verification may specifically include the following steps:

[0060] Step S210: In response to a read operation on a read-only partition file initiated by a business layer running on the processor, the file system layer running on the processor generates a corresponding first block input / output request bio, and sends the first bio to a software driver layer running on the processor.

[0061] The data integrity verification method can be applied to a chip, which may include a processor, a storage controller, and a storage device. In addition, the processor may run a business layer, a file system layer, a software driver layer, and an underlying device layer. Optionally, the software driver layer may include a dm-verity device. The underlying device layer may include a block device layer + a driver layer, the storage controller may include UFSHCI, and the storage device may include UFSDevice.

[0062] In this embodiment, when the business layer (such as an application or system process) needs to read data in a read-only partition, it can initiate a read operation on the read-only partition file. Accordingly, the file system layer can generate a corresponding first bio in response to the read operation on the read-only partition file initiated by the business layer, and send the first bio to the software driver layer.

[0063] In some implementations, when the business layer needs to read a file in a read-only partition, a read operation for the read-only partition file can be initiated through an API provided by the operating system (such as system calls such as opening a file and reading). When the read operation initiated by the business layer reaches the file system layer, the file system can parse the request and determine the location of the data to be read on the storage device. Then, the file system layer can generate one or more block input and output requests (first bio) based on the amount and location of the read data, where the first bio can include detailed information about the data to be read, such as the starting address, data length, etc. The first bio generated by the file system layer can be sent down to the software driver layer for processing.

[0064] As an implementable method, for the read operation initiated by the business layer for the read-only partition file, the read operation request is first captured by the user state program and passed to the kernel state through the system call interface (such as SCI). The kernel state calls the file system's page read operation. In the kernel state, the file system can find the location of the corresponding file on the storage device according to the requested file path and offset. Then, the file system can call the page read operation to read data from the storage device. Among them, the page read operation is an underlying data reading mechanism executed by the file system in the kernel state, which is usually associated with the block size of the storage device and the page size of the operating system.

[0065] Step S220: Generate, through the software driver layer, a second bio for the underlying device layer running on the processor based on the parameters of the first bio, and send the second bio to the underlying device layer.

[0066] In this embodiment, when the software driver layer receives the first bio sent by the file system layer, it can generate a second bio for the underlying device based on the parameters of the first bio, and send the second bio to the underlying device layer.

[0067] Among them, the software driver layer may include a dm-verity device, which is a community-native design. It is a layer of virtual block device. The first bio it receives is originally for the upper file system. If the dm-verity device directly resends the first bio to the storage device recorded in the same bio without proper processing, then these requests will loop infinitely between the dm-verity device and the storage device, resulting in deadlock or system crash. Therefore, a second bio for the underlying device layer can be regenerated based on the parameters of the first bio. The second bio will be used to initiate an actual read request to the storage device to avoid the above problems.

[0068] In some implementations, when the software driver layer receives the first bio, it can first check whether the first bio is for the read-only partition configured by it. If the first bio is for the read-only partition protected by the software driver layer, the software driver layer can start processing the first bio. The software driver layer can regenerate a second bio for the underlying storage device based on the parameters of the first bio (such as the starting address, data length, etc.), and the second bio will be used to read the actual data block from the storage device.

[0069] In some embodiments, when generating the second bio, the software driver layer can set a flag to enable this solution. That is, when generating the second bio, the software driver layer can set a flag in its internal structure to indicate that the second bio needs to pass the data integrity verification process set by this solution. Optionally, the flag can be a Boolean value or a specific flag bit used to distinguish between bio requests that need to be verified and bio requests that do not need to be verified in subsequent processing.

[0070] See also Figure 3 , Figure 3 This application shows Figure 2 The following is a flow chart of step S220 of the data integrity verification method. Figure 3 The process shown is described in detail, and the method may specifically include the following steps:

[0071] Step S221: Generate the second bio based on the parameters of the first bio through the software driver layer, and allocate memory according to the data request length of the first bio to obtain the hash value buffer.

[0072] In some implementations, upon receiving the first bio sent by the file system layer, the software driver layer may generate a second bio based on the parameters of the first bio, allocate memory according to the data request length of the first bio, and use the generated memory as a hash value buffer.

[0073] As an implementable manner, when the software driver layer receives the first bio, it can calculate the required hash value storage space according to the request data length of the first bio, and use kmalloc, kzalloc or similar kernel memory allocation functions to allocate sufficient memory as a hash value buffer to store these hash values. It is understandable that the allocated memory should be equal to or greater than the calculated hash value storage space. Optionally, when the selected hash algorithm is sha256, the size of the allocated memory should not be less than 32 bytes corresponding to each 4kiB, that is, 256 bits; and when the selected hash algorithm is sha512, the size of the allocated memory should not be less than 64 bytes, that is, 512 bits, that is, the allocated memory size can be dynamically updated according to the selected hash algorithm, which is not limited here. .

[0074] Step S222: hosting the memory address corresponding to the hash value buffer in the auxiliary structure of the second bio through the software driver layer.

[0075] In some implementations, when allocating memory to obtain a hash value buffer, the software driver layer may determine a memory address corresponding to the hash value buffer, and host the memory address corresponding to the hash value buffer in an auxiliary structure of the second bio.

[0076] As an implementable method, the software driver layer can define an auxiliary structure, which contains at least one field to store the memory address of the hash value buffer. Of course, the auxiliary structure can also contain other fields related to the verification process, such as the expected hash value, the length of the verified data, etc. Then, the auxiliary structure is allocated and initialized for the second bio, the memory address of the allocated hash value buffer is assigned to the corresponding field in the auxiliary structure, and finally, the auxiliary structure is associated with the second bio. For example, the bi_private field of the bio or a similar mechanism can be used to associate the address of the auxiliary structure with the second bio. In this way, when processing the second bio, the auxiliary structure can be retrieved by accessing the bi_private field, and then the memory address of the hash value buffer can be accessed.

[0077] Step S223: Send the second BIO hosting the memory address to the underlying device layer through the software driver layer.

[0078] In some implementations, when the second bio is regenerated and the memory address of the hash value buffer is hosted in an attached structure of the second bio, the second bio hosting the memory address can be sent to the underlying device layer through the software driver layer.

[0079] Step S230: converting the second bio into the data request through the underlying device layer, and sending the data request to the storage controller.

[0080] In this embodiment, when the bottom device layer receives the second BIO sent by the software driver layer, it can convert the second BIO into a data request and send the data request to the storage controller.

[0081] Among them, in the bottom device layer of the Linux kernel, when the bottom device layer receives a bio, it usually converts the bio into a lower-level request structure (usually struct request) for processing in the device driver. In this embodiment, when the bottom device layer receives the second bio, it can convert the second bio into a data request request and send the data request request to the storage controller. It can be understood that the data structure of the data request is the data structure used when the bottom device layer interacts with the hardware, which can contain all the information required to perform I / O operations.

[0082] See also Figure 4 , Figure 4 This application shows Figure 2 The following is a flow chart of step S230 of the data integrity verification method. Figure 4 The process shown is described in detail, and the method may specifically include the following steps:

[0083] Step S231: convert the second bio into the data request through the underlying device layer, and host the memory address corresponding to the hash value buffer in the auxiliary structure of the data request.

[0084] In some embodiments, when the underlying device layer receives the second BIO sent by the software driver layer, it can convert the second BIO into a data request, and continue to host the memory address corresponding to the hash buffer hosted in the subsidiary structure of the second BIO in the subsidiary structure of the data request.

[0085] As an implementable method, the underlying device layer can define an auxiliary structure, which contains at least one field to store the memory address of the hash value buffer. Of course, the auxiliary structure can also contain other fields related to the verification process, such as the expected hash value, the length of the verified data, etc. Then, the auxiliary structure is allocated and initialized for the data request, the memory address of the hash value buffer is assigned to the corresponding field in the auxiliary structure, and finally, the auxiliary structure is associated with the data request. In this way, when processing the data request, the auxiliary structure can be retrieved by accessing the corresponding field, and then the memory address of the hash value buffer can be accessed.

[0086] In some implementations, when the bottom device layer receives the second bio sent by the software driver layer, it can detect whether a mark enabling the present solution is set in the second bio. If it is detected that a mark enabling the present solution is set in the second bio, it can be considered that the data integrity verification process set by the present solution needs to be used, and therefore, the memory address corresponding to the hash value buffer can be hosted in the attached structure of the data request; if it is detected that the mark enabling the present solution is not set in the second bio, it can be considered that the data integrity verification process set by the present solution does not need to be used, and therefore, the memory address corresponding to the hash value buffer can be not hosted in the attached structure of the data request.

[0087] Step S232: Sending the data request hosting the memory address to the storage controller through the underlying device layer.

[0088] In some implementations, when the second bio is converted into a data request and the memory address of the hash value buffer is hosted in an attached structure of the data request, the data request hosting the memory address can be sent to the storage controller through the underlying device layer.

[0089] Step S240: Sending the data request to the storage device through the storage controller.

[0090] Step S250: Feedback target data to the storage controller via the storage device in response to the data request.

[0091] Step S260: performing hash calculation on the target data through the storage controller to obtain an actual hash value corresponding to the target data.

[0092] For the detailed description of step S240 to step S260, please refer to step S120 to step S140, which will not be repeated here.

[0093] Step S270: Compare the actual hash value with the expected hash value corresponding to the target data through the software driver layer to obtain an integrity check result of the target data.

[0094] In this embodiment, when the actual hash value of the target data is obtained by calculation through the storage controller, the integrity check of the target data can be performed by the processor based on the actual hash value to obtain the integrity check result of the target data. Optionally, when the actual hash value of the target data is obtained by calculation through the storage controller, the integrity check of the target data can be performed by the software driver layer running on the processor based on the actual hash value to obtain the integrity check result of the target data.

[0095] In some embodiments, when the actual hash value of the target data is calculated by the storage controller, the actual hash value can be compared with the expected hash value corresponding to the target data through the software driver layer to obtain the integrity check result of the target data. Optionally, the expected hash value represents the original state of the target data, which can be the hash value of the expected correct content in the hash table, which can be calculated when the server makes the version image.

[0096] As an implementable method, when comparing the actual hash value with the expected hash value, if the comparison result indicates that the actual hash value matches the expected hash value, then it can be determined that the integrity check result of the target data is that the data is complete and has not been tampered with or damaged. If the comparison result indicates that the actual hash value does not match the expected hash value, then it can be determined that the integrity check result of the target data is that the data is incomplete and may have been tampered with or damaged.

[0097] See also Figure 5 , Figure 5 This application shows Figure 2 The data integrity verification method shown in FIG. Figure 5 The process shown is described in detail, and the method may specifically include the following steps:

[0098] Step S271: writing the actual hash value into a hash value buffer through the storage controller, wherein the hash value buffer is obtained by allocating memory by the software driver layer according to the data request length of the first bio.

[0099] Among them, based on the above description, the software driver layer allocates memory according to the data request length of the first bio, obtains the hash value buffer, and hosts the memory address corresponding to the hash value buffer in the auxiliary structure of the second bio and sends it down to the underlying device layer. Accordingly, the underlying device layer continues to host the memory address corresponding to the hash value buffer in the auxiliary structure of the data request and sends it down to the storage controller. Accordingly, the storage controller can know and access the memory address of the hash value buffer.

[0100] In this embodiment, when the storage controller obtains the actual hash value of the target data through calculation, the storage controller may write the actual hash value into the hash value buffer based on the memory address of the hash value buffer.

[0101] Step S272: Compare the actual hash value cached in the hash value buffer with the expected hash value through the software driver layer to obtain a first comparison result.

[0102] In this embodiment, when the storage controller writes the actual hash value into the hash value buffer, the software driver layer may compare the actual hash value cached in the hash value buffer with the expected hash value to obtain a first comparison result. Optionally, the first comparison result may include that the actual hash value matches the expected hash value, or that the actual hash value does not match the expected hash value.

[0103] In some implementations, the storage controller may trigger a CPU interrupt when writing the actual hash value into the hash value buffer. Accordingly, the software driver layer compares the actual hash value cached in the hash value buffer with the expected hash value to obtain a first comparison result.

[0104] As an implementable method, when the storage controller writes the actual hash value into the hash value buffer, the CPU interrupt can be triggered, and the storage driver can determine the request flag to determine whether a mark enabling the scheme is set. If it is detected that a mark enabling the scheme is set, the actual hash value cached in the hash value buffer and the expected hash value can be compared through the software driver layer to obtain a first comparison result; if it is detected that the mark enabling the scheme is not set, the actual hash value cached in the hash value buffer and the expected hash value can be compared without the driver layer.

[0105] Step S273: obtaining, through the software driver layer, an integrity check result of the target data based on the first comparison result.

[0106] In some implementations, when the first comparison result is obtained through the software driver layer, an integrity check result of the target data may be obtained based on the first comparison result.

[0107] Optionally, if the first comparison result is that the actual hash value matches the expected hash value, then the integrity check result of the target data is that the target data is complete and has not been tampered with or damaged, and the end request process of the file system can be directly called; if the first comparison result is that the actual hash value does not match the expected hash value, then the integrity check result of the target data is that the target data is incomplete and may have been tampered with or damaged, and error correction can be attempted. When the error correction fails or no error correction is performed, the request failure status mark can be set and the end request process of the file system can be called.

[0108] An embodiment of the present application provides a method for verifying data integrity. The file system layer running on the processor responds to a read operation on a read-only partition file initiated by the business layer running on the processor, generates a corresponding first bio, and sends the first bio to the software driver layer running on the processor. The software driver layer generates a second bio for the underlying device layer running on the processor based on the parameters of the first bio, and sends the second bio to the underlying device layer. The underlying device layer converts the second bio into a data request, and sends the data request to the storage controller. The storage controller sends the data request to the storage device. The storage device responds to the data request and feeds back the target data to the storage controller. The storage controller performs hash calculation on the target data to obtain the actual hash value corresponding to the target data. The software driver layer compares the actual hash value with the expected hash value corresponding to the target data to obtain the integrity verification result of the target data. Compared with Figure 1 The data integrity verification result shown in the figure, in this embodiment, the software driver layer of the processor also compares the actual hash value with the expected hash value to determine the data integrity verification result, thereby saving software overhead time and improving the reading efficiency of the read-only partition.

[0109] See also Figure 6 , Figure 6 A schematic diagram showing a specific implementation of an embodiment of the present application is shown in FIG. Figure 6 As shown, it may include the following steps:

[0110] 1. An application or system process initiates a read operation on a read-only partition file

[0111] 2. The read operation calls the file system's page read operation in kernel mode

[0112] 3. The file system's page read operation generates a bio and sends it to the dm-verity device

[0113] 4. After receiving the request, the Dm-verity device regenerates a bio for the underlying device based on the bio parameters and sets the flag to enable this solution; allocates memory for UFSHCI to store hash values ​​according to the request length, where when the selected hash algorithm is sha256, the allocated size is not less than 32 bytes per 4KiB, that is, 256 bits; when the selected hash algorithm is sha512, the allocated memory size should be not less than 64 bytes, that is, 512 bits, etc., which is not limited here. The memory address is hosted in the attached structure of bio

[0114] 5. The underlying device will convert the bio into a request. The request will decide whether to set the flag to enable this solution based on the bio tag. If this solution needs to be enabled, the memory address allocated in 4 will continue to be hosted in the subsidiary structure of the request.

[0115] 6. The underlying device sends the request to UFSHCI

[0116] 7. UFSHCI sends the read request to UFSDevice, and UFSDevice responds after obtaining the data

[0117] 8. UFSHCI determines that if the flag bit of this scheme is enabled, the hash value is calculated for the data content returned by UFSDevice. The hash algorithm uses the hash algorithm specified by the upper layer (such as sha256, sha512, etc.), and the hash value is written to the corresponding buffer

[0118] 9. UFSHCI triggers a CPU interrupt, and the storage driver determines the request flag bit. If this solution is enabled, a hash value comparison is performed. If a match is made, the end request process of the file system is directly called. If a match is made, error correction is attempted (optional). If error correction fails or is not performed, the request failure status flag is set and the end request process of the file system is called.

[0119] See also Figure 7 , Figure 7 The flowchart of the method for data integrity verification provided by an embodiment of the present application is shown. The method is applied to the above chip, which includes a processor, a storage controller and a storage device. Figure 7 The process shown is described in detail, and the method for data integrity verification may specifically include the following steps:

[0120] Step S310: In response to a read operation on a read-only partition file initiated by a business layer running on the processor, the file system layer running on the processor generates a corresponding first block input / output request bio, and sends the first bio to a software driver layer running on the processor.

[0121] The data integrity verification method can be applied to a chip, which may include a processor, a storage controller, and a storage device. In addition, the processor may run a business layer, a file system layer, a software driver layer, and an underlying device layer. Optionally, the software driver layer may include a dm-verity device. The underlying device layer may include a block device layer + a driver layer, the storage controller may include UFSHCI, and the storage device may include UFSDevice.

[0122] In this embodiment, when the business layer (such as an application or system process) needs to read data in a read-only partition, it can initiate a read operation on the read-only partition file. Accordingly, the file system layer can generate a corresponding first bio in response to the read operation on the read-only partition file initiated by the business layer, and send the first bio to the software driver layer.

[0123] In some implementations, when the business layer needs to read a file in a read-only partition, a read operation for the read-only partition file can be initiated through an API provided by the operating system (such as system calls such as opening a file and reading). When the read operation initiated by the business layer reaches the file system layer, the file system can parse the request and determine the location of the data to be read on the storage device. Then, the file system layer can generate one or more block input and output requests (first bio) based on the amount and location of the read data, where the first bio can include detailed information about the data to be read, such as the starting address, data length, etc. The first bio generated by the file system layer can be sent down to the software driver layer for processing.

[0124] As an implementable method, for the read operation initiated by the business layer for the read-only partition file, the read operation request is first captured by the user state program and passed to the kernel state through the system call interface (such as SCI). The kernel state calls the file system's page read operation. In the kernel state, the file system can find the location of the corresponding file on the storage device according to the requested file path and offset. Then, the file system can call the page read operation to read data from the storage device. Among them, the page read operation is an underlying data reading mechanism executed by the file system in the kernel state, which is usually associated with the block size of the storage device and the page size of the operating system.

[0125] Step S320: Generate, through the software driver layer, a second bio for the underlying device layer running on the processor based on the parameters of the first bio, and send the second bio to the underlying device layer.

[0126] In this embodiment, when the software driver layer receives the first bio sent by the file system layer, it can generate a second bio for the underlying device based on the parameters of the first bio, and send the second bio to the underlying device layer.

[0127] Among them, the software driver layer may include a dm-verity device, which is a community-native design. It is a layer of virtual block device. The first bio it receives is originally for the upper file system. If the dm-verity device directly resends the first bio to the storage device recorded in the same bio without proper processing, then these requests will loop infinitely between the dm-verity device and the storage device, resulting in deadlock or system crash. Therefore, a second bio for the underlying device layer can be regenerated based on the parameters of the first bio. The second bio will be used to initiate an actual read request to the storage device to avoid the above problems.

[0128] In some implementations, when the software driver layer receives the first bio, it can first check whether the first bio is for the read-only partition configured by it. If the first bio is for the read-only partition protected by the software driver layer, the software driver layer can start processing the first bio. The software driver layer can regenerate a second bio for the underlying storage device based on the parameters of the first bio (such as the starting address, data length, etc.), and the second bio will be used to read the actual data block from the storage device.

[0129] In some embodiments, when generating the second bio, the software driver layer can set a flag to enable this solution. That is, when generating the second bio, the software driver layer can set a flag in its internal structure to indicate that the second bio needs to pass the data integrity verification process set by this solution. Optionally, the flag can be a Boolean value or a specific flag bit used to distinguish between bio requests that need to be verified and bio requests that do not need to be verified in subsequent processing.

[0130] See also Figure 8 , Figure 8 This application shows Figure 7 The following is a flow chart of step S320 of the data integrity verification method shown in FIG. Figure 8 The process shown is described in detail, and the method may specifically include the following steps:

[0131] Step S321: Generate the second bio based on the parameters of the first bio through the software driver layer, and allocate memory according to the data request length of the first bio to obtain the hash value buffer.

[0132] In some implementations, upon receiving the first bio sent by the file system layer, the software driver layer may generate a second bio based on the parameters of the first bio, allocate memory according to the data request length of the first bio, and use the generated memory as a hash value buffer.

[0133] As an implementable manner, when the software driver layer receives the first bio, it can calculate the required hash value storage space according to the request data length of the first bio, and use kmalloc, kzalloc or similar kernel memory allocation functions to allocate sufficient memory as a hash value buffer to store these hash values. It is understandable that the allocated memory should be equal to or greater than the calculated hash value storage space. Optionally, when the selected hash algorithm is sha256, the size of the allocated memory should not be less than 32 bytes corresponding to each 4kiB, that is, 256 bits; when the selected hash algorithm is sha512, the size of the allocated memory should not be less than 64 bytes, that is, 512 bits, that is, the allocated memory size can be dynamically updated according to the selected hash algorithm, which is not limited here. .

[0134] Step S322: hosting the memory address corresponding to the hash value buffer in the auxiliary structure of the second bio through the software driver layer, and writing the expected hash value into the hash value buffer.

[0135] In some embodiments, when the software driver layer allocates memory to obtain a hash value buffer, it can determine the memory address corresponding to the hash value buffer, and host the memory address corresponding to the hash value buffer in an attached structure of the second bio, and write the expected hash value into the hash value buffer, and send it to the storage controller together with the request. Optionally, the expected hash value represents the original state of the target data, which can be the hash value of the expected correct content in the hash table, which can be calculated when the server makes a version image.

[0136] As an implementable method, the software driver layer can define an auxiliary structure, which contains at least one field to store the memory address of the hash value buffer. Of course, the auxiliary structure can also contain other fields related to the verification process, such as expected hash value, verified data length, etc. Then, the auxiliary structure is allocated and initialized for the second bio, the memory address of the allocated hash value buffer is assigned to the corresponding field in the auxiliary structure, and finally, the auxiliary structure is associated with the second bio. For example, the bi_private field of the bio or a similar mechanism can be used to associate the address of the auxiliary structure with the second bio. In this way, when processing the second bio, the auxiliary structure can be retrieved by accessing the bi_private field, and then the memory address of the hash value buffer and the expected hash value written in the memory can be accessed.

[0137] Step S323: Send the second BIO hosting the memory address to the underlying device layer through the software driver layer.

[0138] In some embodiments, when the second bio is regenerated, the memory address of the hash value buffer is hosted in an attached structure of the second bio, and the expected hash value is written into the hash value buffer, the second bio hosting the memory address can be sent to the underlying device layer through the software driver layer.

[0139] Step S330: converting the second bio into the data request through the underlying device layer, and sending the data request to the storage controller.

[0140] In this embodiment, when the bottom device layer receives the second BIO sent by the software driver layer, it can convert the second BIO into a data request and send the data request to the storage controller.

[0141] Among them, in the bottom device layer of the Linux kernel, when the bottom device layer receives a bio, it usually converts the bio into a lower-level request structure (usually struct request) for processing in the device driver. In this embodiment, when the bottom device layer receives the second bio, it can convert the second bio into a data request request and send the data request request to the storage controller. It can be understood that the data structure of the data request is the data structure used when the bottom device layer interacts with the hardware, which can contain all the information required to perform I / O operations.

[0142] See also Fig. 9 , Fig. 9 This application shows Figure 7The data integrity verification method shown in FIG. Fig. 9 The process shown is described in detail, and the method may specifically include the following steps:

[0143] Step S331: convert the second bio into the data request through the underlying device layer, and host the memory address corresponding to the hash value buffer in the auxiliary structure of the data request.

[0144] In some embodiments, when the underlying device layer receives the second BIO sent by the software driver layer, it can convert the second BIO into a data request, and continue to host the memory address corresponding to the hash buffer hosted in the subsidiary structure of the second BIO in the subsidiary structure of the data request.

[0145] As an implementable method, the underlying device layer can define an auxiliary structure, which contains at least one field to store the memory address of the hash value buffer. Of course, the auxiliary structure can also contain other fields related to the verification process, such as the expected hash value, the length of the verified data, etc. Then, the auxiliary structure is allocated and initialized for the data request, the memory address of the hash value buffer is assigned to the corresponding field in the auxiliary structure, and finally, the auxiliary structure is associated with the data request. In this way, when processing the data request, the auxiliary structure can be retrieved by accessing the corresponding field, and then the memory address of the hash value buffer can be accessed, and the expected hash value written in the hash value buffer can be obtained.

[0146] In some implementations, when the bottom device layer receives the second bio sent by the software driver layer, it can detect whether a mark enabling the present solution is set in the second bio. If it is detected that a mark enabling the present solution is set in the second bio, it can be considered that the data integrity verification process set by the present solution needs to be used, and therefore, the memory address corresponding to the hash value buffer can be hosted in the attached structure of the data request; if it is detected that the mark enabling the present solution is not set in the second bio, it can be considered that the data integrity verification process set by the present solution does not need to be used, and therefore, the memory address corresponding to the hash value buffer can be not hosted in the attached structure of the data request.

[0147] Step S332: Send the data request hosting the memory address to the storage controller through the underlying device layer.

[0148] In some implementations, when the second bio is converted into a data request and the memory address of the hash value buffer is hosted in an attached structure of the data request, the data request hosting the memory address can be sent to the storage controller through the underlying device layer.

[0149] Step S340: Send the data request to the storage device through the storage controller.

[0150] Step S350: Feedback target data to the storage controller via the storage device in response to the data request.

[0151] Step S360: performing hash calculation on the target data through the storage controller to obtain an actual hash value corresponding to the target data.

[0152] For the detailed description of step S240 to step S260, please refer to step S120 to step S140, which will not be repeated here.

[0153] Step S370: The storage controller compares the actual hash value with the expected hash value corresponding to the target data to obtain an integrity check result of the target data.

[0154] In this embodiment, when the actual hash value of the target data is obtained by calculation through the storage controller, the storage controller can perform integrity check on the target data based on the actual hash value to obtain an integrity check result of the target data.

[0155] In some implementations, when the actual hash value of the target data is calculated by the storage controller, the storage controller may compare the actual hash value with the expected hash value corresponding to the target data to obtain an integrity check result of the target data.

[0156] As an implementable method, when comparing the actual hash value with the expected hash value, if the comparison result indicates that the actual hash value matches the expected hash value, then it can be determined that the integrity check result of the target data is that the data is complete and has not been tampered with or damaged. If the comparison result indicates that the actual hash value does not match the expected hash value, then it can be determined that the integrity check result of the target data is that the data is incomplete and may have been tampered with or damaged.

[0157] See also Fig.10 , Fig.10 This application shows Figure 7 The following is a flow chart of step S370 of the data integrity verification method shown in FIG. Fig.10 The process shown is described in detail, and the method may specifically include the following steps:

[0158] Step S371: The storage controller compares the actual hash value with the expected hash value cached in the hash value buffer to obtain a second comparison result, wherein the hash value buffer is obtained by the software driver layer by allocating memory according to the data request length of the first bio, and the expected hash value is written into the hash value buffer by the software driver layer.

[0159] Among them, based on the above description, the software driver layer allocates memory according to the data request length of the first bio, obtains the hash value buffer, and hosts the memory address corresponding to the hash value buffer in the auxiliary structure of the second bio, and writes the expected hash value into the hash value buffer and sends it to the underlying device layer. Accordingly, the underlying device layer continues to host the memory address corresponding to the hash value buffer in the auxiliary structure of the data request and sends it to the storage controller. Accordingly, the storage controller can know and access the memory address of the hash value buffer. At this time, the storage controller can directly obtain the expected hash value of the target data.

[0160] In this embodiment, when the storage controller calculates and obtains the actual hash value of the target data, it can directly compare the expected hash value cached in the hash value buffer with the actual hash value of the target data to obtain a second comparison result. Optionally, the second comparison result may include that the actual hash value matches the expected hash value, or that the actual hash value does not match the expected hash value.

[0161] As an implementable method, when receiving the target data fed back by the storage device, the storage controller can judge the request flag to determine whether a mark enabling the scheme is set. If it is detected that a mark enabling the scheme is set, a hash value calculation can be performed on the target data to obtain the actual hash value of the target data, and the expected hash value cached in the hash value buffer and the actual hash value obtained by calculation can be compared to obtain a second comparison result; if it is detected that the mark enabling the scheme is not set, the hash value calculation and subsequent comparison can be omitted for the target data.

[0162] Step S372: obtaining, through the storage controller, an integrity check result of the target data based on the second comparison result.

[0163] In some implementations, when the second comparison result is obtained through the storage controller, an integrity check result of the target data may be obtained based on the second comparison result.

[0164] Optionally, if the second comparison result is that the actual hash value matches the expected hash value, then the integrity check result of the target data is that the target data is complete and has not been tampered with or damaged, and the end request process of the file system can be directly called; if the second comparison result is that the actual hash value does not match the expected hash value, then the integrity check result of the target data is that the target data is incomplete and may have been tampered with or damaged, and error correction can be attempted. When the error correction fails or no error correction is performed, the request failure status mark can be set and the end request process of the file system can be called.

[0165] As an implementable manner, when the second comparison result is obtained through the storage controller, the storage controller can trigger a CPU interrupt, mark whether the file system request is successful according to the second comparison result, and call the file system end request process.

[0166] An embodiment of the present application provides a method for verifying data integrity. The file system layer running on the processor responds to a read operation on a read-only partition file initiated by the business layer running on the processor, generates a corresponding first bio, and sends the first bio to the software driver layer running on the processor. The software driver layer generates a second bio for the underlying device layer running on the processor based on the parameters of the first bio, and sends the second bio to the underlying device layer. The underlying device layer converts the second bio into a data request, and sends the data request to the storage controller. The storage controller sends the data request to the storage device. The storage device feeds back the target data to the storage controller in response to the data request. The storage controller performs hash calculation on the target data to obtain the actual hash value corresponding to the target data. The storage controller compares the actual hash value with the expected hash value corresponding to the target data to obtain the integrity verification result of the target data. Compared with Figure 1 As shown in the data integrity verification result, in this embodiment, the storage controller also compares the actual hash value and the expected hash value to determine the data integrity verification result, thereby saving software overhead time and improving the reading efficiency of the read-only partition.

[0167] See also Fig.11 , Fig.11 A schematic diagram showing a specific implementation of another embodiment of the present application is shown as follows: Fig.11 As shown, it may include the following steps:

[0168] 1. An application or system process initiates a read operation on a read-only partition file

[0169] 2. The read operation calls the file system's page read operation in kernel mode

[0170] 3. The file system's page read operation generates a bio and sends it to the dm-verity device

[0171] 4. After receiving the request, the Dm-verity device regenerates a bio for the underlying device based on the bio parameters and sets the flag to enable this solution; allocates memory for UFSHCI to store hash values ​​according to the request length, where when the selected hash algorithm is sha256, the allocated size is not less than 32 bytes per 4KiB, that is, 256 bits; when the selected hash algorithm is sha512, the allocated memory size should be not less than 64 bytes, that is, 512 bits, etc., which are not limited here. The memory address is hosted in the attached structure of bio, and the expected hash value is written into these memories

[0172] 5. The underlying device will convert the bio into a request. The request will decide whether to set the flag to enable this solution based on the bio tag. If this solution needs to be enabled, the memory address allocated in 4 will continue to be hosted in the subsidiary structure of the request.

[0173] 6. The underlying device sends the request to UFSHCI

[0174] 7. UFSHCI sends the read request to UFSDevice, and UFSDevice responds after obtaining the data

[0175] 8. UFSHCI determines that if the flag bit of this solution is enabled, it will calculate the hash value of the data content returned by UFSDevice. The hash algorithm uses the hash algorithm specified by the upper layer (such as sha256, sha512, etc.) and compares it with the expected hash value. If it does not match, the read request is marked as failed. 9. UFSHCI triggers a CPU interrupt, marks whether the file system request is successful based on the result, and calls the end request process of the file system

[0176] See also Fig.12 , Fig.12 The flowchart of the data integrity verification method provided by an embodiment of the present application is shown. The method is used for integrity verification of read-only partitions. By solidifying the calculation of hash values ​​in the storage controller, software overhead time is saved, and the read efficiency of read-only partitions can be improved. In a specific embodiment, the data integrity verification method is applied to the storage controller of a chip, which also includes a processor and a storage device. Fig.12 The process shown is described in detail, and the data integrity verification method may specifically include the following steps:

[0177] Step S410: receiving a data request sent by the processor, wherein the data request is generated by the processor in response to a read operation on a read-only partition file.

[0178] Step S420: sending the data request to the storage device, and receiving the target data fed back by the storage device in response to the data request.

[0179] Step S430: performing hash calculation on the target data to obtain an actual hash value corresponding to the target data.

[0180] Step S440: Perform an integrity check on the target data based on the actual hash value to obtain an integrity check result of the target data, or perform an integrity check on the target data through the processor to obtain an integrity check result of the target data.

[0181] For the detailed description of step S410 to step S440 , please refer to step S110 to step S150 , which will not be repeated here.

[0182] An embodiment of the present application provides a method for verifying data integrity, wherein a storage controller receives a data request issued by a processor, wherein the data request is generated by the processor in response to a read operation on a read-only partition file, sends the data request to the storage device, and receives target data fed back by the storage device in response to the data request, performs hash calculation on the target data to obtain an actual hash value corresponding to the target data, performs integrity verification on the target data based on the actual hash value to obtain an integrity verification result of the target data, or performs integrity verification on the target data through the processor to obtain an integrity verification result of the target data, thereby performing integrity verification on the read-only partition and solidifying the calculation of the hash value in the storage controller to save software overhead time and improve the read efficiency of the read-only partition.

[0183] In some implementations, the present application also provides a data integrity verification device, which is applied to the storage controller of the above-mentioned chip, and the chip also includes a processor and a storage device. The following will describe the data integrity verification device, which may include: a data request receiving module, a data request sending module, a hash calculation module, and an integrity verification module, wherein:

[0184] The data request receiving module is used to receive a data request sent by the processor, wherein the data request is generated by the processor in response to a read operation on a read-only partition file.

[0185] The data request sending module is used to send the data request to the storage device and receive the target data fed back by the storage device in response to the data request.

[0186] The hash calculation module is used to perform hash calculation on the target data to obtain an actual hash value corresponding to the target data.

[0187] An integrity check module is used to perform an integrity check on the target data based on the actual hash value to obtain an integrity check result of the target data, or to perform an integrity check on the target data through the processor to obtain an integrity check result of the target data.

[0188] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0189] In several embodiments provided in the present application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0190] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0191] In some implementations, an embodiment of the present application further provides a chip, which may include a processor, a storage controller, and a storage device, and the chip may be used to execute the above-mentioned data integrity verification method.

[0192] In some implementations, the present application also provides an electronic device, which may include the above chip.

[0193] In summary, the data integrity verification method, chip and electronic device provided in the embodiments of the present application respond to the read operation on the read-only partition by the chip processor, send the corresponding data request to the chip storage controller through the storage controller, and feedback the target data to the storage controller through the storage device in response to the data request. The storage controller performs hash calculation on the target data to obtain the actual hash value corresponding to the target data, and performs integrity verification on the target data based on the actual hash value through the storage controller or the processor to obtain the integrity verification result of the target data, so as to improve the read efficiency of the read-only partition by saving software overhead time by solidifying the calculation of the hash value in the storage controller.

[0194] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A data integrity verification method, characterized in that: Applied to a chip, the chip includes a processor, a storage controller and a storage device, the method includes: In response to a read operation on a read-only partition file, the processor sends a corresponding data request to the storage controller; Sending the data request to the storage device through the storage controller; Feedback target data to the storage controller in response to the data request through the storage device; Performing hash calculation on the target data by the storage controller to obtain an actual hash value corresponding to the target data; The storage controller or the processor performs an integrity check on the target data based on the actual hash value to obtain an integrity check result of the target data.

2. The method according to claim 1, characterized in that The sending, by the processor, a corresponding data request to the storage controller in response to a read operation on the read-only partition file comprises: In response to a read operation on a read-only partition file initiated by a service layer running on the processor, the file system layer running on the processor generates a corresponding first block input / output request BIO, and sends the first BIO to a software driver layer running on the processor; Generate, by the software driver layer, a second BIO for an underlying device layer running on the processor based on parameters of the first BIO, and send the second BIO to the underlying device layer; The second bio is converted into the data request through the underlying device layer, and the data request is sent to the storage controller.

3. The method according to claim 2, characterized in that The performing integrity check on the target data based on the actual hash value by the storage controller or the processor to obtain an integrity check result of the target data includes: The actual hash value is compared with the expected hash value corresponding to the target data through the software driver layer to obtain an integrity check result of the target data.

4. The method according to claim 3, characterized in that The comparing the actual hash value with the expected hash value corresponding to the target data through the software driver layer to obtain the integrity check result of the target data includes: Writing the actual hash value into a hash value buffer through the storage controller, wherein the hash value buffer is obtained by allocating memory by the software driver layer according to the data request length of the first bio; Comparing the actual hash value cached in the hash value buffer with the expected hash value by the software driver layer to obtain a first comparison result; An integrity check result of the target data is obtained through the software driver layer based on the first comparison result.

5. The method according to claim 4, characterized in that The step of generating, by the software driver layer, a second bio for an underlying device layer running on the processor based on the parameters of the first bio, and sending the second bio to the underlying device layer includes: Generate the second bio based on the parameters of the first bio through the software driver layer, and allocate memory according to the data request length of the first bio to obtain the hash value buffer; Hosting the memory address corresponding to the hash value buffer in the subsidiary structure of the second bio through the software driver layer; The second BIO hosting the memory address is sent to the underlying device layer through the software driver layer.

6. The method according to claim 5, characterized in that The converting the second bio into a data request through the underlying device layer and sending the data request to the storage controller includes: Converting the second bio into the data request through the underlying device layer, and hosting the memory address corresponding to the hash value buffer in an attached structure of the data request; The data request hosting the memory address is sent to the storage controller through the underlying device layer.

7. The method according to claim 2, characterized in that: The performing integrity check on the target data based on the actual hash value by the storage controller or the processor to obtain an integrity check result of the target data includes: The storage controller compares the actual hash value with the expected hash value corresponding to the target data to obtain an integrity check result of the target data.

8. The method according to claim 7, characterized in that The comparing the actual hash value with the expected hash value corresponding to the target data by the storage controller to obtain the integrity check result of the target data includes: Comparing the actual hash value with the expected hash value cached in the hash value buffer by the storage controller to obtain a second comparison result, wherein the hash value buffer is obtained by the software driver layer allocating memory according to the data request length of the first bio, and the expected hash value is written into the hash value buffer by the software driver layer; An integrity check result of the target data is obtained by the storage controller based on the second comparison result.

9. The method according to claim 8, characterized in that The step of generating, by the software driver layer, a second bio for an underlying device layer running on the processor based on the parameters of the first bio, and sending the second bio to the underlying device layer includes: Generate the second bio based on the parameters of the first bio through the software driver layer, and allocate memory according to the data request length of the first bio to obtain the hash value buffer; Hosting the memory address corresponding to the hash value buffer in the auxiliary structure of the second bio through the software driver layer, and writing the expected hash value into the hash value buffer; The second BIO hosting the memory address is sent to the underlying device layer through the software driver layer.

10. The method according to claim 9, characterized in that The converting the second bio into a data request through the underlying device layer and sending the data request to the storage controller includes: Converting the second bio into the data request through the underlying device layer, and hosting the memory address corresponding to the hash value buffer in an attached structure of the data request; The data request hosting the memory address is sent to the storage controller through the underlying device layer.

11. A method for verifying data integrity, characterized in that: A storage controller applied to a chip, wherein the chip further includes a processor and a storage device, and the method includes: receiving a data request sent by the processor, wherein the data request is generated by the processor in response to a read operation on a read-only partition file; Sending the data request to the storage device, and receiving target data fed back by the storage device in response to the data request; Performing hash calculation on the target data to obtain an actual hash value corresponding to the target data; An integrity check is performed on the target data based on the actual hash value to obtain an integrity check result of the target data, or an integrity check is performed on the target data by the processor to obtain an integrity check result of the target data.

12. A chip, characterized in that: The chip comprises a processor, a storage controller and a storage device, and is used to execute the method according to any one of claims 1 to 10.

13. An electronic device, characterized in that: Comprising the chip as claimed in claim 12.

Images