A user-mode encryption / decryption file system offload system, method and medium supporting in-line mode

Abstract

This invention discloses a user-space encryption / decryption file system unloading system, method, and medium supporting in-line mode, relating to the field of data processing and storage technology. The system includes a host, an FPGA hardware module, and a TIPU. The host is configured with an fs-Client driver module, which intercepts file operation requests and encapsulates them into encrypted or pass-through requests according to a custom protocol before sending them to the FPGA hardware module. The FPGA hardware module integrates a data packet parsing and encryption / decryption module, extracting encryption / decryption parameters for pass-through requests and performing in-line real-time encryption / decryption on file data. The TIPU, through the SPDK framework and fs-Server service module running in user space, receives processed data or pass-through requests, manages encrypted meta information, and interacts with backend storage to complete read / write operations. This invention achieves deep integration of encryption / decryption and I / O paths, eliminating the overhead of multiple data copying, freeing up host CPU computing power, and significantly improving system throughput and data security.

Description

Technical Field

[0001] This invention relates to the field of data processing and storage technology, specifically to a user-space encryption and decryption file system unloading system, method, and medium that supports in-line mode, applicable to trusted data spaces and data center scenarios requiring high performance, high security, and storage-computation separation. Background Technology

[0002] The statements in this section are provided only as background information in relation to this disclosure and may not constitute prior art.

[0003] With the continuous increase in computing power and storage pressure in data centers, the demand for "host CPU load reduction," "storage-computing separation," and "data security encryption" in trusted data space scenarios is becoming increasingly urgent. In order to free up host CPU resources, some existing offloading solutions attempt to offload the core operations of the user-space file system to the data processing unit (such as TIPU), which then undertakes file access, protocol processing, and encryption / decryption tasks in order to ensure data storage security.

[0004] However, this offloading scheme using a side-by-side encryption / decryption engine has the following key shortcomings, limiting further improvements in system performance:

[0005] 1. Performance degradation due to data copying: In the above scheme, the data processing unit needs to receive the file data first, and then forward it to the external encryption / decryption engine for encryption or decryption. During this process, multiple data copies occur between the operating system and the encryption / decryption engine, consuming additional system resources and reducing data processing efficiency;

[0006] 2. Performance bottleneck of the side-mounted engine: The encryption / decryption engine is deployed side-mounted, separated from the input / output (I / O) path. Data needs to be transmitted back and forth between the I / O link and the engine, which not only increases data transmission latency but also limits the communication bandwidth between the engine and the data processing unit, thus failing to fully utilize the transmission potential of the I / O path;

[0007] 3. Insufficient coordination between encryption / decryption and I / O paths: In the above scheme, the data processing unit receives plaintext data, which needs to be encrypted by the engine before being written to the backend storage. This makes it impossible to achieve "synchronous completion of data transmission and encryption / decryption." Consequently, the I / O link and encryption / decryption operations are executed serially, severely impacting the overall system throughput.

[0008] Currently, traditional solutions either rely on the host CPU for encryption and decryption, thus consuming a large amount of computing power, or use the aforementioned side-by-side engines, which suffer from data copying and latency issues. There is no user-space file system offloading solution that integrates the encryption and decryption module into the I / O critical path to achieve in-line encryption and decryption. None of these solutions can simultaneously meet the core requirements of "low latency, high throughput, and data security". Summary of the Invention

[0009] The purpose of this invention is to address the problems in existing user-space file system unloading schemes, such as the multiple data copying overhead caused by using a side-mounted encryption / decryption engine, the performance bottleneck caused by the separation of input / output (IO) paths and encryption / decryption, and the inability to simultaneously achieve low latency, high throughput, and data security. This invention provides a user-space encryption / decryption file system unloading system, method, and medium that supports in-line mode. Based on a hardware architecture integrating encryption / decryption modules in a Field-Programmable Gate Array (FPGA), combined with host-side driver optimization and a custom data interaction protocol, it achieves deep integration of encryption / decryption operations and IO critical paths (i.e., in-line encryption / decryption). This invention, while retaining the data processing unit's file system unloading operation to free up host CPU computing power, completely eliminates the data copying overhead between the operating system and the side-mounted engine, achieving synchronous execution of encryption / decryption operations and data transmission, thereby significantly improving the overall system throughput and data processing efficiency.

[0010] The technical solution of the present invention is as follows:

[0011] A user-space encryption / decryption file system unloading system supporting in-line mode, comprising:

[0012] The host computer, FPGA hardware module, and TIPU terminal;

[0013] The host is equipped with an fs-Client driver module, which is used to receive file operation requests initiated by user applications, classify and process the file operation requests, and encapsulate the file operation requests into encrypted requests or pass-through requests according to a preset custom protocol, and send them to the FPGA hardware module using the direct memory access capability between the host and the FPGA hardware module.

[0014] The FPGA hardware module is connected to the host and the TIPU via a bus interface, and integrates a data packet parsing module and an encryption / decryption module. The data packet parsing module is used to identify the type of the received data packet: if it is a pass-through request, it is directly passed through to the TIPU; if it is an encryption request, it parses and extracts the encryption / decryption parameters and data in the encryption request, calls the encryption / decryption module to perform in-line encryption / decryption processing on the data according to the encryption / decryption parameters, and transmits the processed data to the TIPU or the host.

[0015] The TIPU terminal is configured with an SPDK framework running in user space, an fs-Server service module, and a backend storage access module. The SPDK framework directly accesses the memory area of ​​the FPGA hardware module through memory mapping. The fs-Server service module is used to receive encryption requests or encrypted / decrypted data from the FPGA hardware module, manage the encrypted meta information of the corresponding file, and call the backend storage access module to interact with the backend storage to complete file system operations and data reading and writing.

[0016] Furthermore, when the fs-Client driver module encapsulates the file operation request into the encrypted request or the pass-through request, it follows the following custom data interaction protocol:

[0017] The pass-through request is used to transmit operation-type instructions without file data content, and its data packet format includes: a request header, an operation header, and optional operation data;

[0018] The encryption request is used to transmit read / write instructions carrying file data content. Its data packet format includes: a request header, an operation header, extended data, and file data described in a hash-cluster list (SGL) format. The extended data contains parameters necessary for performing encryption and decryption, including the encryption algorithm type, block mode, initialization vector, and key.

[0019] Furthermore, the FPGA hardware module contains embedded data packet parsing logic and encryption / decryption logic:

[0020] When the data packet parsing module recognizes that the data packet is the encryption request, it extracts the encryption algorithm type, block mode, initialization vector and key from the extended data, and reads the corresponding memory data according to the SGL format;

[0021] The encryption / decryption module is invoked to perform real-time encryption / decryption calculations on the read memory data according to the extracted parameters, without the need for additional data copying between the host and TIPU.

[0022] Furthermore, the fs-Server service module is specifically used for:

[0023] Receive file operation requests for encrypted files, and manage the encrypted meta information of the files when creating or opening them. The encrypted meta information includes algorithm type, initialization vector, original content size, padding content, and block size.

[0024] When an encrypted request data transmitted via the FPGA hardware module is received, the padding content in the encrypted meta information is updated, and the write interface of the back-end storage access module is called to write the encrypted data to the back-end storage.

[0025] Furthermore, for write requests containing file data, the fs-Client driver module generates the request using the following alignment mechanism:

[0026] Query the encrypted meta information of the target file, obtain the preset block size, and determine whether the start and end addresses of the data to be written are aligned with the start and end addresses of the block corresponding to the block size.

[0027] If aligned, the write request is directly encapsulated as the encrypted request and placed in the sending queue;

[0028] If misaligned, a read request in encrypted request format is generated, and the original encrypted data corresponding to the block is read and decrypted by the FPGA hardware module and returned. The fs-Client driver module merges the decrypted original data with the data to be written this time according to the offset, so as to adjust the start address and end address of the written data to the alignment state.

[0029] If the adjusted starting address is still not aligned with the initial vector length, a request to obtain the initial vector is generated, i.e., a write-get-iv request, which reads encrypted data of the previous initial vector length as the initial vector for this encryption.

[0030] Furthermore, for read requests containing file data, the system's processing flow includes:

[0031] The fs-Client driver module queries the encrypted meta information of the target file, obtains the preset block size and the corresponding block start address. If it is determined that the start address of the request is still not aligned with the start address of the block after being aligned downwards according to the initial vector length, a request to read the encrypted data of the previous initial vector length is generated. After being decrypted by the FPGA hardware module, it is used as the initial vector of this read request.

[0032] The fs-Client driver module encapsulates the read operation, which includes the adjusted address and encryption / decryption parameters, into an encryption request and sends it to the TIPU terminal.

[0033] After obtaining the encrypted data in the corresponding range, the fs-Server service module encapsulates it together with the encryption / decryption parameters according to the encryption request format and sends it to the FPGA hardware module.

[0034] The FPGA hardware module parses the encryption request and calls the encryption / decryption module to decrypt it, then transmits the decrypted plaintext data to the fs-Client driver module.

[0035] This invention also proposes a user-space encryption / decryption file system unloading method supporting in-line mode, applied to the aforementioned system. The method includes the following steps:

[0036] Step S1: The host intercepts file operation requests initiated by the user application, and according to the operation type and the preset custom protocol, encapsulates the request into a pass-through request containing control instructions or a decryption request containing file data and encryption / decryption parameters, and sends it to the FPGA hardware module through direct memory access.

[0037] Step S2: The FPGA hardware module identifies the received data packet: if it is a pass-through request, it is directly passed through to the TIPU end; if it is an encryption request, it extracts the encryption and decryption parameters and performs in-line encryption and decryption on the file data on the bus transmission path, and then sends the processed data to the TIPU end or the host end.

[0038] Step S3: The TIPU receives the encryption request or the encrypted / decrypted data, updates the encrypted meta information of the file, and calls the backend storage access module to interact with the backend storage to complete the storage access operation of the target data.

[0039] Furthermore, the custom protocol mentioned in step S1 is specifically as follows:

[0040] The data packet size of the pass-through request is fixed and consists of a request header and an operation header;

[0041] The data packet size of the encryption request is variable, and it consists of a request header, an operation header, extended data carrying the encryption algorithm type and initial vector, and a data segment in Hash-Gathering List (SGL) format.

[0042] Furthermore, in step S1, when processing unaligned write request operations, the encrypted blocks for the target data, divided according to a preset block size, include the following compensation sub-steps:

[0043] The original encrypted data of the unaligned encrypted block is read from the backend storage and decrypted by the FPGA hardware module to the host.

[0044] The host end concatenates the plaintext data to be written with the decrypted original plaintext data in memory according to the offset, so that the boundary of the concatenated data is aligned with the boundary of the encrypted block.

[0045] The concatenated and aligned plaintext data, along with encryption parameters, are encapsulated into an encryption request, triggering the in-line encryption process of the FPGA hardware module.

[0046] The present invention also proposes a computer-readable storage medium for storing instructions that, when executed, cause the method described above to be implemented.

[0047] Compared with existing technologies, the advantages of this invention are:

[0048] 1. Eliminate data copying losses and improve system performance: The encryption and decryption module is integrated into the FPGA to realize in-line encryption and decryption through the IO path. Data is encrypted / decrypted synchronously during transmission, eliminating the need for data copying between TIPU OS and the side engine, reducing resource consumption and lowering data processing latency.

[0049] 2. Break through the bottleneck of the side-by-side engine and improve throughput: Encryption and decryption operations are executed synchronously with IO transmission. Data does not need to travel back and forth between the IO link and the engine. Fully utilize the hardware acceleration capability of FPGA to improve the coordination efficiency of encryption and decryption and storage access, and significantly improve system throughput.

[0050] 3. Protocol optimization to adapt to different request types: Custom encrypted requests and pass-through requests are used for two types of data packets. Operation requests are efficiently transmitted through fixed format packets, while data requests are encrypted and decrypted and transmitted synchronously through dynamic packets with parameters, balancing request processing efficiency and flexibility.

[0051] 4. Compatibility with existing applications and storage systems: The host side still provides file access interfaces through the native Linux VFS, and user applications can use it without modification; the TIPU side supports multiple storage protocols such as CephFS and NFS, and is compatible with existing backend storage devices, reducing user migration costs.

[0052] 5. Ensure data security and integrity: Inheriting the encrypted file format and meta information management mechanism of previous patents, end-to-end encryption is achieved through the encryption and decryption module integrated into the FPGA. The host does not cache file content, reducing the risk of data leakage. Meta verification when opening files and checksum verification during data transmission ensure data integrity.

[0053] 6. Excellent scalability: The FPGA-integrated encryption and decryption module supports multiple algorithms and block modes, and new encryption algorithms can be added through firmware upgrades; the TIPU end features a modular design, the back-end storage access module can adapt to new storage protocols, and the number of virtual queues can be dynamically adjusted to adapt to different system loads.

[0054] 7. Optimize alignment processing and IV vector management: Through the pre-alignment processing of fs-Client and the write-get-iv request mechanism, the contradiction between the alignment requirements of the encryption algorithm and the random access of users is resolved, ensuring the correctness of data encryption and decryption.

[0055] 8. Improve system stability and controllability: All operations on the TIPU side still run in user mode, avoiding the complexity of switching between kernel mode and user mode; the FPGA embeds the data packet parsing and encryption / decryption logic, reducing software-level uncertainty and facilitating precise control and optimization of the IO path. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in the embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0057] Figure 1 An architecture diagram for implementing in-line mode. Detailed Implementation

[0058] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0059] The features and performance of the present invention will be further described in detail below with reference to embodiments.

[0060] Example 1

[0061] This embodiment proposes a user-space encryption / decryption file system unloading system that supports in-line mode, specifically including the following modules:

[0062] The host computer, FPGA hardware module, and TIPU terminal;

[0063] The host is equipped with an fs-Client driver module, which is used to receive file operation requests initiated by user applications, classify and process the file operation requests, and encapsulate the file operation requests into encrypted requests or pass-through requests according to a preset custom protocol, and send them to the FPGA hardware module using the direct memory access capability between the host and the FPGA hardware module.

[0064] The FPGA hardware module is connected to the host and the TIPU via a bus interface, and integrates a data packet parsing module and an encryption / decryption module. The data packet parsing module is used to identify the type of the received data packet: if it is a pass-through request, it is directly passed through to the TIPU; if it is an encryption request, it parses and extracts the encryption / decryption parameters and data in the encryption request, calls the encryption / decryption module to perform in-line encryption / decryption processing on the data according to the encryption / decryption parameters, and transmits the processed data to the TIPU or the host.

[0065] The TIPU terminal is configured with an SPDK framework running in user space, an fs-Server service module, and a backend storage access module. The SPDK framework directly accesses the memory area of ​​the FPGA hardware module through memory mapping. The fs-Server service module is used to receive encryption requests or encrypted / decrypted data from the FPGA hardware module, manage the encrypted meta information of the corresponding file, and call the backend storage access module to interact with the backend storage to complete file system operations and data reading and writing.

[0066] In this embodiment, specifically, when the fs-Client driver module encapsulates the file operation request into the encrypted request or the pass-through request, it follows the following custom data interaction protocol:

[0067] The pass-through request is used to transmit operation-type instructions without file data content, and its data packet format includes: a request header, an operation header, and optional operation data;

[0068] The encryption request is used to transmit read / write instructions carrying file data content. Its data packet format includes: a request header, an operation header, extended data, and file data described in a hash-cluster list (SGL) format. The extended data contains parameters necessary for performing encryption and decryption, including the encryption algorithm type, block mode, initialization vector, and key.

[0069] In this embodiment, specifically, the FPGA hardware module contains data packet parsing logic and encryption / decryption logic:

[0070] When the data packet parsing module recognizes that the data packet is the encryption request, it extracts the encryption algorithm type, block mode, initialization vector and key from the extended data, and reads the corresponding memory data according to the SGL format;

[0071] The encryption / decryption module is invoked to perform real-time encryption / decryption calculations on the read memory data according to the extracted parameters, without the need for additional data copying between the host and TIPU.

[0072] In this embodiment, specifically, the fs-Server service module is used for:

[0073] Receive file operation requests for encrypted files, and manage the encrypted meta information of the files when creating or opening them. The encrypted meta information includes algorithm type, initialization vector, original content size, padding content, and block size.

[0074] When an encrypted request data transmitted via the FPGA hardware module is received, the padding content in the encrypted meta information is updated, and the write interface of the back-end storage access module is called to write the encrypted data to the back-end storage.

[0075] In this embodiment, specifically, for write requests containing file data, the fs-Client driver module generates the request through the following alignment mechanism:

[0076] Query the encrypted meta information of the target file, obtain the preset block size, and determine whether the start and end addresses of the data to be written are aligned with the start and end addresses of the block corresponding to the block size.

[0077] If aligned, the write request is directly encapsulated as the encrypted request and placed in the sending queue;

[0078] If misaligned, a read request in encrypted request format is generated, and the original encrypted data corresponding to the block is read and decrypted by the FPGA hardware module and returned. The fs-Client driver module merges the decrypted original data with the data to be written this time according to the offset, so as to adjust the start address and end address of the written data to the alignment state.

[0079] If the adjusted starting address is still not aligned with the initial vector length, a request to obtain the initial vector is generated, i.e., a write-get-iv request, which reads encrypted data of the previous initial vector length as the initial vector for this encryption.

[0080] In this embodiment, specifically, for a read request containing file data, the system's processing flow includes:

[0081] The fs-Client driver module queries the encrypted meta information of the target file, obtains the preset block size and the corresponding block start address. If it is determined that the start address of the request is still not aligned with the start address of the block after being aligned downwards according to the initial vector length, a request to read the encrypted data of the previous initial vector length is generated. After being decrypted by the FPGA hardware module, it is used as the initial vector of this read request.

[0082] The fs-Client driver module encapsulates the read operation, which includes the adjusted address and encryption / decryption parameters, into an encryption request and sends it to the TIPU terminal.

[0083] After obtaining the encrypted data in the corresponding range, the fs-Server service module encapsulates it together with the encryption / decryption parameters according to the encryption request format and sends it to the FPGA hardware module.

[0084] The FPGA hardware module parses the encryption request and calls the encryption / decryption module to decrypt it, then transmits the decrypted plaintext data to the fs-Client driver module.

[0085] Based on the same inventive concept, this invention also provides a user-space encryption / decryption file system unloading method supporting in-line mode, applied to the aforementioned system, the method comprising the following steps:

[0086] Step S1: The host intercepts file operation requests initiated by the user application, and according to the operation type and the preset custom protocol, encapsulates the request into a pass-through request containing control instructions or a decryption request containing file data and encryption / decryption parameters, and sends it to the FPGA hardware module through direct memory access.

[0087] Step S2: The FPGA hardware module identifies the received data packet: if it is a pass-through request, it is directly passed through to the TIPU end; if it is an encryption request, it extracts the encryption and decryption parameters and performs in-line encryption and decryption on the file data on the bus transmission path, and then sends the processed data to the TIPU end or the host end.

[0088] Step S3: The TIPU receives the encryption request or the encrypted / decrypted data, updates the encrypted meta information of the file, and calls the backend storage access module to interact with the backend storage to complete the storage access operation of the target data.

[0089] In this embodiment, specifically, the custom protocol mentioned in step S1 is as follows:

[0090] The data packet size of the pass-through request is fixed and consists of a request header and an operation header;

[0091] The data packet size of the encryption request is variable, and it consists of a request header, an operation header, extended data carrying the encryption algorithm type and initial vector, and a data segment in Hash-Gathering List (SGL) format.

[0092] In this embodiment, specifically, in step S1, when processing an unaligned write request operation, the encrypted blocks divided according to a preset block size for the target data include the following compensation sub-steps:

[0093] The original encrypted data of the unaligned encrypted block is read from the backend storage and decrypted by the FPGA hardware module to the host.

[0094] The host end concatenates the plaintext data to be written with the decrypted original plaintext data in memory according to the offset, so that the boundary of the concatenated data is aligned with the boundary of the encrypted block.

[0095] The concatenated and aligned plaintext data, along with encryption parameters, are encapsulated into an encryption request, triggering the in-line encryption process of the FPGA hardware module.

[0096] Based on the same inventive concept, embodiments of the present invention also provide a storage medium storing computer instructions that, when executed on a computer, cause the computer to perform a user-mode encryption / decryption file system unloading method supporting in-line mode as described above.

[0097] In some alternative embodiments, the present invention also provides that various aspects of the user-space encryption and decryption file system unloading method supporting in-line mode can also be implemented as a program product comprising program code, which, when the program product is run on a device, causes the control device to perform the steps in the user-space encryption and decryption file system unloading method supporting in-line mode according to various exemplary embodiments of the present invention as described above.

[0098] It should be noted that although several units or sub-units of the apparatus have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the invention, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units. Furthermore, although the operation of the method of the invention is described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0099] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media containing computer-usable program code.

[0100] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a server, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0101] Program code for performing the operations of this invention can be written using any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0102] In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0103] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0104] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0105] Example 2

[0106] This embodiment provides an in-line user-space encryption / decryption file system unloading system based on an FPGA-integrated encryption / decryption module. The system includes a host terminal, an FPGA hardware module, and a TIPU terminal. Through hardware integration, driver optimization, and protocol customization, it achieves in-line encryption / decryption and file system unloading. The specific structure and process are as follows:

[0107] 1. Overall Architecture Composition

[0108] (1) Host side

[0109] The fs-Client driver module is an improvement on the traditional FUSE kernel module, possessing the following core capabilities:

[0110] ① Parse the encrypted file metadata format defined in the preceding patent;

[0111] ② Classify and process file operation requests (operation type / read / write);

[0112] ③ Encapsulate data packets according to a custom protocol (encrypted request / pass-through request);

[0113] ④ Utilize the PCIe interface and direct memory access (DMA) capabilities provided by the FPGA to achieve efficient data transmission.

[0114] (2) FPGA hardware module

[0115] Communication bridge function: soldered to TIPU, it enables memory access between the host and TIPU through the PCIe interface, and solidifies the PCIe protocol adaptation logic to ensure data transmission stability;

[0116] Encryption / decryption module (integrated): Built-in encryption / decryption module, supports multiple encryption algorithms and block modes such as SM3 and AES-CBC, and can directly perform in-line encryption and decryption on data in the IO path;

[0117] Packet parsing capabilities: ① Supports the identification and parsing of encrypted and pass-through requests, extracting key fields such as request headers, operation headers, extended data, and data; ② For encrypted requests, it can parse the encryption parameters (algorithm type, block mode, initialization vector, key, etc.) in the extended data and read the data fields (supporting hash-cluster list SGL format description) for encryption and decryption processing; ③ For pass-through requests, it directly transmits to the TIPU end without encryption and decryption operations.

[0118] (3) TIPU end

[0119] Memory mapping processing: The FPGA's memory space is mapped to user space through igb_uio, allowing the SPDK framework to directly access the PCIe-mapped memory region and avoid switching between kernel mode and user mode;

[0120] SPDK Framework and fs-Server Service Module: The SPDK framework runs in user space and integrates the fs-Server service module (interfacing with the host-side fs-Client), possessing the following capabilities: ① Receiving pass-through requests from the FPGA, parsing them, and then calling the backend storage access module to perform file operations (such as lookup, mkdir, getattr, etc.); ② Receiving encrypted request data transmitted from the FPGA and directly writing it to the backend storage; ③ For read requests, reading encrypted data from the backend storage, encapsulating it according to the protocol, and sending it to the FPGA for decryption; ④ Managing the encrypted meta information of encrypted files (including algorithm type, initialization vector, original content size, padding content, etc.), realizing the reading, updating, and storage of encrypted meta information;

[0121] Backend storage access module: It interfaces with the fs-Server service module and supports multiple remote / local storage protocols such as CephFS and NFS to achieve efficient reading and writing of encrypted data without the user's awareness.

[0122] 2. Custom data interaction protocol

[0123] The data transmitted between the host-side fs-Client driver module and the TIPU-side fs-Server service module through the FPGA hardware module is divided into two types of data packets, with the following protocol format and purpose:

[0124] (1) Straight-through request

[0125] Features: Fixed packet size, no file data content, only transmission of operation instructions and related parameters;

[0126] Format: Request header + Operation header + [Operation data];

[0127] Request headers: Describe basic information such as packet type (marked as pass-through request), total packet size, and checksum;

[0128] Operation header: Describes the specific file operation type, such as create (including flags / mode / mask fields), open (including access permission fields), lookup (including path fields), etc.

[0129] Operation data: Optional field, carrying necessary parameters for specific operations (e.g., filename for create operation, maximum length 256 bytes, adapted to Linux system filename restrictions);

[0130] Applicable scenarios: File operation requests, including lookup, readdir, mkdir, create, opendir, closedir, getattr, setattr, symlink, unlink, write-get-iv, etc.

[0131] (2) Encryption request

[0132] Features: Packet size is variable; it carries file data content and necessary encryption / decryption parameters.

[0133] Format: Request header + Operation header + Extended data + Data (SGL format);

[0134] Request headers: describe the data packet type (marked as encrypted request), total packet size, checksum, etc.

[0135] Operation header: describes the operation type (e.g., read, write), starting address of data, data length, etc.

[0136] Extended data: Stores the necessary parameters for encryption and decryption, including encryption algorithm type, block mode (such as CBC), initialization vector, key, etc.

[0137] Data: The file data content uses the Scatter-Gather List (SGL) format to describe memory addresses, supporting efficient data transfer;

[0138] Applicable scenarios: Requests involving file data, including read, write, etc.

[0139] 3. Core Request Processing Flow

[0140] 3.1 Operation-type request processing flow (based on encrypted requests)

[0141] Operation-type requests include lookup, mkdir, create, opendir, closedir, getattr, etc. Taking the create request as an example:

[0142] User applications initiate a create request through the host-side VFS;

[0143] After receiving the request, the fs-Client driver module parses the request parameters (filename, permissions, creation mode, etc.), encapsulates them according to the encrypted request format (request header + operation header + operation data (including filename)), and generates WQE (work queue element).

[0144] The fs-Client driver module uses the DMA capability provided by the FPGA to send WQE directly to the TIPU side;

[0145] The TIPU-side SPDK framework directly reads the encrypted request through the UIO device, and the fs-Server service module parses the parameters in the packet.

[0146] The fs-Server service module calls the backend storage access module to perform a create operation, create a file and initialize encrypted meta information (default algorithm, block mode, etc.).

[0147] The fs-Server service module encapsulates the operation results in an encrypted request format and sends them back to the fs-Client driver module via the FPGA.

[0148] After parsing the response, the fs-Client driver module sends it back to the user application via VFS to complete the request processing.

[0149] 3.2 Write Request Processing Flow (Based on Encrypted Requests, Taking CBC Block Mode as an Example)

[0150] User applications initiate write requests through VFS, carrying data and information such as the target file path and offset;

[0151] After receiving the request, the fs-Client driver module queries the encryption meta information of the file (algorithm, block mode, block size, etc.) and determines whether the start and end addresses of the request are aligned with the start and end addresses of the block.

[0152] If aligned: the fs-Client driver module will encapsulate the request into an encrypted request (request header + operation header + extended data (including algorithm, CBC mode, initialization vector, key) + data (SGL format)), generate a WQE, and put it into the send queue (SQ);

[0153] If not aligned:

[0154] 3.2.1 The fs-Client driver module generates a read request in an encrypted request format, reads the original encrypted data of the corresponding block of the file through FPGA→SPDK→back-end storage, decrypts it through the FPGA, and returns it to the fs-Client driver module;

[0155] 3.2.2 The fs-Client driver module merges the decrypted raw data with the data of this write request by offset, and adjusts the start and end addresses of the write request to align it with the block.

[0156] 3.2.3 If the adjusted starting address is still not aligned with the initial vector length, the fs-Client driver module generates a write-get-iv request in the encryption request format, and reads the encrypted data of the previous initial vector length through FPGA→SPDK→back-end storage as the initial vector for this encryption.

[0157] 3.2.4 Encapsulate the encryption request according to the format in step 3 and put it into SQ;

[0158] 3.2.5 The FPGA reads WQE from SQ, parses it and finds that it is an encryption request. It extracts the encryption parameters (algorithm, CBC mode, initialization vector, key) from the extended data and reads the memory data corresponding to the data SGL.

[0159] 3.2.6 The FPGA calls the integrated encryption / decryption module to encrypt the data according to the extracted parameters;

[0160] 3.2.7 The FPGA transmits the encrypted data to the SPDK framework on the TIPU side;

[0161] 3.2.8 The TIPU-side fs-Server service module receives encrypted data and updates the padding content in the encrypted meta information (if the request end address is not aligned with the initial vector length, the ciphertext content within the aligned range is recorded).

[0162] 3.2.9 The fs-Server service module calls the write interface of the backend storage access module to write encrypted data to the backend storage;

[0163] 3.2.10 After the backend storage completes the write, it encapsulates the response result and the updated encrypted meta information in the encrypted request format and sends them back to the fs-Client driver module via FPGA;

[0164] 3.2.11 After parsing the response, the fs-Client driver module sends it back to the user application to complete the write request.

[0165] 3.3 Read Request Processing Flow (Based on Encrypted Requests, Taking CBC Block Mode as an Example)

[0166] User applications initiate read requests through VFS, carrying information such as the target file path, starting address, and read length;

[0167] After receiving the request, the fs-Client driver module queries the encrypted meta information of the file and determines whether the start and end addresses of the request are aligned with the length of the initial vector.

[0168] If the starting address is still not aligned with the block starting address after being aligned downwards according to the initial vector length:

[0169] 3.3.1 The fs-Client driver module generates a read initial vector request in encrypted request format, and reads encrypted data of the previous initial vector length through FPGA→SPDK→back-end storage;

[0170] 3.3.2 The encrypted data is decrypted by the FPGA and returned to the fs-Client driver module as the initial vector for this read request;

[0171] 3.3.3 The fs-Client driver module encapsulates the adjusted start address, end address, initialization vector, encryption algorithm, block mode, and key as operation data into an encryption request and sends it to the TIPU-side SPDK framework.

[0172] 3.3.4 The TIPU-side fs-Server service module parses the encryption request and calls the backend storage access module to obtain the encrypted data for the corresponding range;

[0173] 3.3.5 The fs-Server service module encapsulates the encrypted data and extended data (including initialization vector, algorithm, block pattern, etc.) according to the encryption request format and sends them to the FPGA;

[0174] 3.3.6 The FPGA parses the encryption request and calls the encryption / decryption module to decrypt the data according to the parameters in the extended data;

[0175] 3.3.7 The FPGA transmits the decrypted plaintext data to the host-side fs-Client driver module;

[0176] 3.3.8 The fs-Client driver module extracts the corresponding data according to the starting address and length of the user's original request, and feeds it back to the user application through VFS to complete the read request.

[0177] 3.4 Open Request Processing Flow

[0178] User applications initiate open requests through VFS, carrying information such as file path and access mode;

[0179] The fs-Client driver module encapsulates the request into a pass-through request (including parameters such as file path and access mode) and sends it to the SPDK framework on the TIPU side via the FPGA.

[0180] The TIPU-side fs-Server service module parses the pass-through request and calls the open interface of the backend storage access module to open the file;

[0181] The fs-Server service module calls the read interface of the backend storage access module to read the encrypted meta information (algorithm type, initialization vector, original content size, etc.) at the beginning of the file.

[0182] The fs-Server service module merges file metadata (size, permissions, creation time, etc.) with encrypted metadata, encapsulates the response according to the encrypted request format, and sends it back to the fs-Client driver module via FPGA;

[0183] After parsing the response, the fs-Client driver module sends the file information back to the user application, completing the open request.

[0184] 3.5 Release (Close) Request Processing Flow

[0185] User applications initiate release requests through VFS, carrying information such as file handles;

[0186] The fs-Client driver module collects the encrypted meta update information of the file (such as the content to be filled, changes in the original content size, etc.), merges it with the release request information, encapsulates it into an encrypted request, and sends it to the SPDK framework on the TIPU side through the FPGA.

[0187] The TIPU-side fs-Server service module parses the pass-through request and extracts encrypted meta update information.

[0188] The fs-Server service module calls the backend storage interface to write the updated encrypted meta information to the encrypted meta storage area at the beginning of the file;

[0189] The fs-Server service module performs file closing operations, releases related resources, generates response information and encapsulates it into an encrypted request, and sends it back to the fs-Client driver module via the FPGA;

[0190] After parsing the response, the fs-Client driver module sends it back to the user application, completing the release request.

[0191] 4. Initialization process

[0192] Upon system startup, the improved virtiofs driver module on the host side and the fs-Server service module on the TIPU side establish a connection via the PCIe bus. Based on the virtio protocol, they negotiate and establish a request queue (SQ), a response queue (RQ), and a completion queue (CQ) for asynchronously notifying processing results. During this process, the emulator configured at the system's underlying level is responsible for simulating standard device interfaces to the host side to ensure transparent data transmission based on the virtio protocol. In subsequent request processing, after the FPGA or TIPU side completes the operation on the work queue element (WQE) obtained from the SQ, it generates a corresponding completion queue entry (CQE) and places it in the CQ, thereby achieving asynchronous result notification to the host side.

[0193] The FPGA initializes the integrated encryption / decryption module, loads the supported encryption algorithms and block modes, and completes communication adaptation with the host and TIPU.

[0194] The host-side fs-Client driver module is initialized, completing the logic for parsing encrypted file metadata format and loading data packet encapsulation rules;

[0195] The TIPU-side SPDK framework is initialized, the fs-Server service module loads file operation logic and encrypted meta information management rules, the cache management module initializes the cache space, and the backend storage access module establishes connections with backend storage such as CephFS and NFS.

[0196] After initialization is complete, the system enters a ready state, waiting to receive user file operation requests.

[0197] 5. Abnormal Handling Process

[0198] When an exception occurs during file operation request processing (such as file not existing, insufficient permissions, remote storage connection failure, incorrect encryption / decryption parameters, packet parsing failure, corrupted encrypted meta information, etc.), the following procedure shall be followed:

[0199] The exception triggering module (fs-Client driver module, FPGA, fs-Server service module) records the exception type, error code, and related context information;

[0200] Error information is encapsulated into a response message according to the corresponding data packet type (encrypted request / pass-through request) and sent back to the request initiator through the response queue;

[0201] The host-side fs-Client driver module parses the exception response message and sends specific error information (such as "file does not exist" or "invalid encryption key") to the user application through VFS, prompting the user to take appropriate action.

[0202] Example 3

[0203] Please see Figure 1 Based on the above system and method, this embodiment further provides the specific hardware and software deployment environment of the user-space encryption and decryption file system unloading system that supports in-line mode, as well as a demonstration of the specific execution process for typical scenarios.

[0204] 1. Hardware Environment Description

[0205] FPGA hardware module: adopts Xilinx Alveo U280 or equivalent performance FPGA, integrates AES and SM3 hardware acceleration cores (i.e. the encryption and decryption module), supports hash-cluster list SGL data format parsing, and PCIe interface speed ≥16GT / s;

[0206] TIPU side: Uses a processor with user-mode I / O access capabilities (such as Intel Xeon series), supports igb_uio driver and SPDK framework (version ≥22.01), and has a memory capacity ≥32GB;

[0207] Backend storage: Supports distributed storage clusters or local storage arrays with CephFS 16.2.10, NFS 4.2 and above protocols, with storage bandwidth ≥10GB / s.

[0208] 2. Software Environment Description

[0209] 1. Host side: Linux kernel 5.4 or above, fs-Client driver module (modified based on FUSE 3.10.5);

[0210] 2. FPGA Firmware: Custom firmware, integrating data packet parsing logic and encryption / decryption module drivers (supporting algorithms such as AES-CBC and SM3);

[0211] 3. TIPU side: SPDK 22.01 and above, fs-Server service module (developed based on SPDK), backend storage access module (supports CephFS and NFS protocols).

[0212] 3. Typical scenario demonstration (taking file write-read-close as an example)

[0213] 3.1 Scene Preparation

[0214] Users need to write a 10MB file (test.txt) to remote CephFS storage, subsequently read the file, and finally close the file. The entire process must be encrypted, and the host CPU must not participate in the encryption or decryption operations.

[0215] 3.2 Write Operation Execution Flow

[0216] 1. When a user calls the write function through the application to write 10MB of data to / test.txt, VFS forwards the request to the fs-Client driver module;

[0217] 2. The fs-Client driver module queries the encrypted meta information of test.txt (algorithm: AES-CBC, initial vector length: 16 bytes, block size: 4MB), and determines whether the start address (0) and end address (10485760 bytes) of the written data are aligned with the block size (0-4MB, 4MB-8MB, 8MB-12MB). It finds that the end address (10MB) is not aligned with the end address of the 12MB block.

[0218] 3. The fs-Client driver module generates a read request in pass-through request format to read the original encrypted data in 8MB-12MB blocks. After the fs-Server generates a reverse encryption request to the FPGA, the FPGA decrypts the 8MB-12MB data and responds to the fs-Client.

[0219] 4. The fs-Client driver module merges the decrypted 8MB-10MB data with the 8MB-10MB data written this time, and adjusts the end address to 12MB (aligned with the block).

[0220] 5. The fs-Client driver module encapsulates the encrypted request: request header (marks a pass-through request) + operation header (write, starting with 0, length 12MB) + extended data (AES-CBC, initialization vector = 0x123456..., key = 0xabcdef...) + data (SGL describes 12MB data address), generating WQE and putting it into SQ;

[0221] 6. The FPGA hardware module reads the WQE in SQ, parses the extended data to obtain encryption parameters, reads the 12MB data corresponding to SGL, and calls the AES-CBC module (i.e., encryption / decryption module) to encrypt;

[0222] 7. The FPGA hardware module transmits the encrypted 12MB data to the SPDK framework on the TIPU side;

[0223] 8. The TIPU-side fs-Server service module receives encrypted data, updates the padding content in the encrypted meta information (10MB-12MB of ciphertext), and calls the CephFS write interface to write the encrypted data to the backend storage.

[0224] 9. After CephFS completes the write, it returns a success response. The fs-Server service module encapsulates the response into a pass-through request and sends it back to the fs-Client driver module through the FPGA hardware module.

[0225] 10. After parsing the response, the fs-Client driver module returns a success message to the application, indicating that the write operation is complete.

[0226] 3.3 Read Operation Execution Flow

[0227] 1. When a user calls the read function through the application to read 0-10MB of data from test.txt, VFS forwards the request to the fs-Client driver module;

[0228] 2. The fs-Client driver module queries the encrypted meta information and determines the starting address 0 (aligned with the initial vector length of 16 bytes) and the ending address 10MB (aligned with the initial vector length), without needing to read the initial vector separately;

[0229] 3. The fs-Client driver module encapsulates the pass-through request: request header (marking the encrypted request) + operation header (read, starting with 0, length 10MB) + operation data (initial vector = 0x123456..., algorithm AES-CBC, key = 0xabcdef...), and sends it to the TIPU-side SPDK framework;

[0230] 4. The TIPU-side fs-Server service module parses the pass-through request and calls the CephFS read interface to read 0-12MB of encrypted data;

[0231] 5. The fs-Server service module encapsulates the encryption request: request header (marking the encryption request) + operation header (read response) + extended data (same as request parameters) + data (SGL describes the address of 12MB encrypted data), and sends it to the FPGA hardware module;

[0232] 6. The FPGA hardware module parses the pass-through request, calls the AES-CBC module to decrypt 12MB of data, and extracts 0-10MB of plaintext data;

[0233] 7. The FPGA hardware module transmits 0-10MB of plaintext data to the fs-Client driver module;

[0234] 8. The fs-Client driver module sends the data back to the application, and the read operation is complete.

[0235] 3.4 Shutdown Operation Execution Process

[0236] 1. When a user calls the close function through the application, VFS forwards the request to the fs-Client driver module;

[0237] 2. The fs-Client driver module collects encrypted meta update information (filled content length 2MB, original content size=10MB), encapsulates it into an encrypted request, and sends it to the TIPU-side SPDK framework;

[0238] 3. The TIPU-side fs-Server service module parses the packet and writes the updated encrypted meta information to the meta storage area of ​​test.txt;

[0239] 4. The fs-Server service module performs a file closing operation, releases resources, and generates a response packet which is then sent back to the fs-Client driver module via the FPGA hardware module;

[0240] 5. After parsing the response, the fs-Client driver module sends it back to the application, and the closing operation is complete.

[0241] As can be seen from the above implementation process, this embodiment achieves deep integration of encryption / decryption operations and IO paths, eliminating data copying losses. The TIPU side receives encrypted data, and the host CPU is only responsible for forwarding requests, fully releasing computing power while ensuring data security and operational efficiency.

[0242] The embodiments described above merely illustrate specific implementation methods of this application, and while the descriptions are detailed and specific, they should not be construed as limiting the scope of protection of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the technical solution of this application, and these modifications and improvements all fall within the scope of protection of this application.

Claims

1. A user-space encryption / decryption file system unloading system supporting in-line mode, characterized in that, include: The host computer, FPGA hardware module, and TIPU terminal; The host is equipped with an fs-Client driver module, which is used to receive file operation requests initiated by user applications, classify and process the file operation requests, and encapsulate the file operation requests into encrypted requests or pass-through requests according to a preset custom protocol, and send them to the FPGA hardware module using the direct memory access capability between the host and the FPGA hardware module. The FPGA hardware module is connected to the host and the TIPU via a bus interface, and integrates a data packet parsing module and an encryption / decryption module. The data packet parsing module is used to identify the type of the received data packet: if it is a pass-through request, it is directly passed through to the TIPU; if it is an encryption request, it parses and extracts the encryption / decryption parameters and data in the encryption request, calls the encryption / decryption module to perform in-line encryption / decryption processing on the data according to the encryption / decryption parameters, and transmits the processed data to the TIPU or the host. The TIPU terminal is configured with an SPDK framework running in user space, an fs-Server service module, and a backend storage access module. The SPDK framework directly accesses the memory area of ​​the FPGA hardware module through memory mapping. The fs-Server service module is used to receive encryption requests or encrypted / decrypted data from the FPGA hardware module, manage the encrypted meta information of the corresponding file, and call the backend storage access module to interact with the backend storage to complete file system operations and data reading and writing.

2. The user-space encryption / decryption file system unloading system supporting in-line mode according to claim 1, characterized in that, When the fs-Client driver module encapsulates the file operation request into an encrypted request or a pass-through request, it follows the following custom data interaction protocol: The pass-through request is used to transmit operation-type instructions without file data content, and its data packet format includes: a request header, an operation header, and optional operation data; The encryption request is used to transmit read / write instructions carrying file data content. Its data packet format includes: a request header, an operation header, extended data, and file data described in a hash-cluster list (SGL) format. The extended data contains parameters necessary for performing encryption and decryption, including the encryption algorithm type, block mode, initialization vector, and key.

3. A user-space encryption / decryption file system unloading system supporting in-line mode according to claim 2, characterized in that, The FPGA hardware module contains embedded data packet parsing and encryption / decryption logic. When the data packet parsing module recognizes that the data packet is the encryption request, it extracts the encryption algorithm type, block mode, initialization vector and key from the extended data, and reads the corresponding memory data according to the SGL format; The encryption / decryption module is invoked to perform real-time encryption / decryption calculations on the read memory data according to the extracted parameters, without the need for additional data copying between the host and TIPU.

4. A user-space encryption / decryption file system unloading system supporting in-line mode according to claim 1, characterized in that, The fs-Server service module is specifically used for: Receive file operation requests for encrypted files, and manage the encrypted meta information of the files when creating or opening them. The encrypted meta information includes algorithm type, initialization vector, original content size, padding content, and block size. When an encrypted request data transmitted via the FPGA hardware module is received, the padding content in the encrypted meta information is updated, and the write interface of the back-end storage access module is called to write the encrypted data to the back-end storage.

5. A user-space encryption / decryption file system unloading system supporting in-line mode according to claim 2, characterized in that, For write requests containing file data, the fs-Client driver module generates the request using the following alignment mechanism: Query the encrypted meta information of the target file, obtain the preset block size, and determine whether the start and end addresses of the data to be written are aligned with the start and end addresses of the block corresponding to the block size. If aligned, the write request is directly encapsulated as the encrypted request and placed in the sending queue; If misaligned, a read request in encrypted request format is generated, and the original encrypted data corresponding to the block is read and decrypted by the FPGA hardware module and returned. The fs-Client driver module merges the decrypted original data with the data to be written this time according to the offset, so as to adjust the start address and end address of the written data to the alignment state. If the adjusted starting address is still not aligned with the initial vector length, a request to obtain the initial vector is generated, i.e., a write-get-iv request, which reads encrypted data of the previous initial vector length as the initial vector for this encryption.

6. A user-space encryption / decryption file system unloading system supporting in-line mode according to claim 2, characterized in that, For read requests containing file data, the system's processing flow includes: The fs-Client driver module queries the encrypted meta information of the target file, obtains the preset block size and the corresponding block start address. If it is determined that the start address of the request is still not aligned with the start address of the block after being aligned downwards according to the initial vector length, a request to read the encrypted data of the previous initial vector length is generated. After being decrypted by the FPGA hardware module, it is used as the initial vector of this read request. The fs-Client driver module encapsulates the read operation, which includes the adjusted address and encryption / decryption parameters, into an encryption request and sends it to the TIPU terminal. After obtaining the encrypted data in the corresponding range, the fs-Server service module encapsulates it together with the encryption / decryption parameters according to the encryption request format and sends it to the FPGA hardware module. The FPGA hardware module parses the encryption request and calls the encryption / decryption module to decrypt it, then transmits the decrypted plaintext data to the fs-Client driver module.

7. A user-space encryption / decryption file system unloading method supporting in-line mode, applied to the system as described in any one of claims 1 to 6, characterized in that, The method includes the following steps: Step S1: The host intercepts file operation requests initiated by the user application, and according to the operation type and the preset custom protocol, encapsulates the request into a pass-through request containing control instructions or a decryption request containing file data and encryption / decryption parameters, and sends it to the FPGA hardware module through direct memory access. Step S2: The FPGA hardware module identifies the received data packet: if it is a pass-through request, it is directly passed through to the TIPU end; if it is an encryption request, it extracts the encryption and decryption parameters and performs in-line encryption and decryption on the file data on the bus transmission path, and then sends the processed data to the TIPU end or the host end. Step S3: The TIPU receives the encryption request or the encrypted / decrypted data, updates the encrypted meta information of the file, and calls the backend storage access module to interact with the backend storage to complete the storage access operation of the target data.

8. A method for unloading a user-space encryption / decryption file system supporting in-line mode according to claim 7, characterized in that, The custom protocol mentioned in step S1 is specifically as follows: The data packet size of the pass-through request is fixed and consists of a request header and an operation header; The data packet size of the encryption request is variable, and it consists of a request header, an operation header, extended data carrying the encryption algorithm type and initial vector, and a data segment in Hash-Gathering List (SGL) format.

9. A method for unloading a user-space encryption / decryption file system supporting in-line mode according to claim 7, characterized in that, In step S1, when processing unaligned write request operations, the encrypted blocks for the target data, divided according to a preset block size, include the following compensation sub-steps: The original encrypted data of the unaligned encrypted block is read from the backend storage and decrypted by the FPGA hardware module to the host. The host end concatenates the plaintext data to be written with the decrypted original plaintext data in memory according to the offset, so that the boundary of the concatenated data is aligned with the boundary of the encrypted block. The concatenated and aligned plaintext data, along with encryption parameters, are encapsulated into an encryption request, triggering the in-line encryption process of the FPGA hardware module.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store instructions that, when executed, cause the method as described in any one of claims 7-9 to be implemented.

Images