A high-performance cryptographic service system and method operating in kernel mode

Abstract

The application relates to a high-performance password service system and method running in a kernel state, and belongs to the technical field of information encryption, and solves the problems of huge performance overhead and high delay caused by the fact that a password service runs in a user state. The network module is used for creating multiple listening sockets and establishing connection sockets; after encapsulating a task and sending the task to a thread pool module, request data is copied to a data buffer area corresponding to a connection instance of the connection socket, and response data is taken out from the data buffer area; the connection management module is used for creating a connection instance of the connection socket, allocating a data buffer area, and calling a protocol analysis module when the request data is complete; the thread pool module is used for allocating a working thread to execute a task; and the protocol analysis module is used for analyzing request data, calling a kernel-state password card driver to execute password operation, encapsulating an operation result as response data, and writing the response data into the data buffer area. The performance of the password service is improved.

Description

Technical Field

[0001] This invention relates to the field of information encryption technology, and in particular to a high-performance cryptographic service system and method running in kernel mode. Background Technology

[0002] In recent years, with the rapid development of computer and network technologies, cyberspace information security has faced increasingly severe threats. To enhance information protection capabilities, more and more computer systems are adopting dedicated cryptographic technologies to ensure communication and data security. Cryptographic technologies, through key capabilities such as confidentiality, authentication, data integrity, and non-repudiation, build a fundamental security barrier for digital assets and communication processes.

[0003] Currently, integrating an HSM (Hardware Security Module) is a common solution for mainstream systems to acquire cryptographic security capabilities. In this architecture, the cryptographic service, as the core function of the HSM, is the main carrier for providing cryptographic computation capabilities. It operates in the form of network listening and responds to requests using a dedicated message interface. This type of service needs to efficiently handle a large number of concurrent network accesses, ensuring high throughput while achieving fast response times.

[0004] In HSM applications that rely on dedicated cryptographic computing hardware (a type of computer peripheral), this hardware typically connects to the host via a PCIe interface. The hardware is initially controlled and scheduled at the low level by a kernel-mode driver, and then further encapsulated into a user-mode driver, providing a unified driver interface for upper-layer applications. Therefore, in traditional user-mode cryptographic service implementations, the data processing flow usually involves multiple redundant copies across privilege boundaries, resulting in significant performance overhead. Specifically, the cryptographic service first calls the user-mode network interface, where the operating system kernel copies network data from the kernel-mode buffer to the user-mode buffer; then, protocol parsing and cryptographic calls are performed, further accessing the user-mode driver of the cryptographic hardware. This driver typically needs to copy the data from user mode back to kernel mode again, allowing the kernel-mode driver to perform cryptographic operations; after the operation is complete, the result needs to be copied from kernel mode back to user mode again, and then returned to the service layer via the user-mode driver. Finally, the cryptographic service also needs to encapsulate the operation result into a response message, and call the user-mode network interface, where the kernel copies the data from user mode to kernel mode, ultimately sending it through the network card driver. The frequent data copying between kernel mode and user mode in the above process not only increases data processing latency but also greatly increases CPU load, becoming the main bottleneck restricting the performance of cryptographic services. Summary of the Invention

[0005] Based on the above analysis, the present invention aims to provide a high-performance cryptographic service system and method running in kernel mode, in order to solve the problem of huge performance overhead and high latency caused by frequent data copying between kernel mode and user mode due to the cryptographic service running in user mode.

[0006] On one hand, embodiments of the present invention provide a high-performance cryptographic service system running in kernel mode. The system is deployed in the operating system kernel and includes:

[0007] The network module is used to create multiple listening sockets; when a new connection request is received, the corresponding listening socket accepts the connection and establishes a connection socket; when a password service request is received, the task is encapsulated and sent to the thread pool module, the request data is copied to the data buffer corresponding to the connection instance of the connection socket, and the response data is retrieved from the data buffer;

[0008] The connection management module is used to create connection instances of the connection socket and manage their state, allocate data buffers, and call the protocol parsing module when the completeness of the requested data is detected.

[0009] The thread pool module is used to allocate worker threads to execute tasks in the task queue and trigger the connection management module to check the data buffer.

[0010] The protocol parsing module is used to parse the request data in the data buffer, call the kernel-mode cryptographic card driver to perform cryptographic operations, and encapsulate the operation results into response data and write them into the data buffer.

[0011] Based on further improvements to the above system, the network module also includes an I / O multiplexing component, which includes: an interest red-black tree, a timer red-black tree, and a ready queue. The interest red-black tree is used to store and index all interest instances. Interest instances include: socket instances and network events of interest. The timer red-black tree is used to store and manage timeout timers associated with all connection instances. The ready queue is used to temporarily store socket instances that are ready due to network events of interest and are waiting for the main event loop to process.

[0012] Based on the further improvements to the above system, the network module calls the connection management module to generate a listening instance for the listening socket;

[0013] When a listener instance or connection instance is created, the I / O multiplexing component performs the following operations:

[0014] Encapsulate the listening instance or connection instance into a socket instance, set the corresponding network events of interest, create an interest instance, and register the interest instance into the interest red-black tree;

[0015] The created interest instances and I / O multiplexing component callback functions are encapsulated as wait items and registered to the wait queue of the corresponding listening Socket or connection Socket.

[0016] Based on further improvements to the above system, when the network module receives a new connection request, it performs the following steps:

[0017] The operating system kernel selects the corresponding listening socket, triggers the wait item registered by the I / O multiplexing component in its wait queue, and executes the I / O multiplexing component callback function in the wait item; the I / O multiplexing component callback function identifies that the new connection request exists in the network event of interest in the corresponding interest instance, adds the socket instance in the interest instance to the ready queue, and wakes up the event main loop;

[0018] The main event loop retrieves a socket instance from the ready queue and converts it into a listening instance, then calls the operating system kernel's connection acceptance interface to establish a connection socket;

[0019] Call the connection management module to create a connection instance for the connection socket.

[0020] Based on further improvements to the above system, when the network module receives a cryptographic service request, it performs the following steps:

[0021] The operating system kernel selects the corresponding connection socket, triggers the wait item registered by the I / O multiplexing component in its wait queue, and executes the I / O multiplexing component callback function in the wait item; the I / O multiplexing component callback function identifies that the password service request exists in the network event of interest in the corresponding interest instance, adds the socket instance in the interest instance to the ready queue, and wakes up the event main loop;

[0022] The main event loop retrieves socket instances from the ready queue, converts them into connection instances, and encapsulates the tasks into the task queue of the thread pool module.

[0023] Based on the further improvements to the above system, when the connection management module creates a connection instance for the connection socket, it initializes the status of the connection instance to "connected", creates a corresponding timer according to the timeout of the connection instance, and registers the timer to the timer red-black tree of the I / O multiplexing component. The timeout of the timer is updated after the network module copies the request data to the data buffer, or after the response data is retrieved from the data buffer and written to the kernel send buffer, based on the new timeout calculated according to the current time.

[0024] Based on further improvements to the above system, the network module also performs connection timeout processing through the I / O multiplexing component, including:

[0025] Before each blocking wait in the main event loop, the timer closest to the current time is retrieved from the timer red-black tree, and its timeout is set as the maximum waiting time for this event blocking.

[0026] When the main event loop is woken up due to timer timeout, all timers that have expired are retrieved from the timer red-black tree and removed, their associated connection sockets are closed, their associated interest instances are removed from the interest red-black tree and released, and the connection management module is notified to destroy the corresponding connection instances.

[0027] Based on the further improvements to the above system, the connection management module checks whether the requested data in the data buffer is complete. If the requested data is incomplete, the status of the connection instance is updated to "waiting for data"; if the requested data is complete, the status of the connection instance is updated to "ready to receive".

[0028] Based on further improvements to the above system, after the protocol parsing module writes the response data into the data buffer, it updates the status of the connection instance to "ready to send". When the network module detects that the status of the connection instance is "ready to send", it retrieves the response data from the data buffer and writes it into the kernel send buffer.

[0029] On the other hand, embodiments of the present invention provide a high-performance cryptographic service method running in kernel mode, comprising the following steps:

[0030] Create multiple listening sockets in the operating system kernel;

[0031] When a new connection request is received, the corresponding listening socket accepts the connection and establishes a connection socket; it creates a connection instance of the connection socket, manages its state, and allocates a data buffer.

[0032] When a password service request is received, the task is encapsulated and added to the task queue;

[0033] When executing a task in the task queue, the request data is copied from the kernel receive buffer to the data buffer corresponding to the connection instance of the connected socket. If the request data in the data buffer is found to be complete, the request data is parsed, the kernel-mode cryptographic card driver is called to perform cryptographic operations, and the operation result is encapsulated as response data and written to the data buffer.

[0034] The response data is retrieved from the data buffer and written to the kernel send buffer. The operating system kernel then sends the response data to the client via the network card.

[0035] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0036] 1. By placing the entire cryptographic service protocol stack (network communication, protocol parsing, driver invocation) in kernel space and pre-allocating physically contiguous DMA buffers for each connection, a highly efficient path between network data processing and cryptographic operations within kernel space is established. This reconstructs the implementation location and data processing flow of traditional cryptographic services, enabling application-layer data to be copied only twice within kernel space during the entire processing flow. This achieves the shortest data path from network reception to hardware driver invocation. It fundamentally eliminates the performance bottleneck of multiple copies across privilege boundaries in traditional architectures, significantly reduces data processing latency, and substantially improves system throughput and CPU efficiency.

[0037] 2. Employs event-driven I / O multiplexing components, utilizing dual red-black trees to achieve efficient and stable management of massive connections and precise timeout control.

[0038] 3. The collaborative design of kernel thread pool and connection instance state realizes connection reuse and asynchronous task processing, effectively balancing computing and I / O resources, and ensuring high availability and stability of the system in high-concurrency scenarios.

[0039] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0040] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0041] Figure 1 This is a schematic diagram of the structure of a high-performance cryptographic service system running in kernel mode according to Embodiment 1 of the present invention;

[0042] Figure 2 This is a flowchart of a high-performance cryptographic service method running in kernel mode according to Embodiment 2 of the present invention. Detailed Implementation

[0043] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0044] Example 1

[0045] One specific embodiment of the present invention discloses a high-performance cryptographic service system running in kernel mode, deployed within the operating system kernel, such as... Figure 1 As shown, the system includes: a network module, a connection management module, a thread pool module, and a protocol parsing module; among which,

[0046] The network module is used to create multiple listening sockets. When a new connection request is received, the corresponding listening socket accepts the connection and establishes a connection socket. When a password service request is received, the task is encapsulated and sent to the thread pool module. The request data is copied to the data buffer corresponding to the connection instance of the connection socket, and the response data is retrieved from the data buffer.

[0047] The connection management module is used to create connection instances of the connection socket and manage their state, allocate data buffers, and call the protocol parsing module when the completeness of the requested data is detected.

[0048] The thread pool module is used to allocate worker threads to execute tasks in the task queue and trigger the connection management module to check the data buffer.

[0049] The protocol parsing module is used to parse the request data in the data buffer, call the kernel-mode cryptographic card driver to perform cryptographic operations, and encapsulate the operation results into response data and write them into the data buffer.

[0050] In implementation, the system of this embodiment is compiled into a kernel module file. During operating system runtime, this file is loaded into the operating system's kernel space. After initialization, each module works collaboratively to form a high-performance cryptographic service protocol stack located in the kernel space. This stack calls network interfaces in the operating system kernel and listens on designated TCP ports to send and receive cryptographic service messages. The protocol stack can parse and distribute received messages and call kernel-mode cryptographic card drivers to provide corresponding functional interfaces based on different request types. After processing, the system sends the response data to the operating system's kernel network buffer. The operating system reassembles the response data from the kernel network buffer and sends it to the network card through the operating system kernel.

[0051] The following describes in detail the processing steps performed by each module based on the system operation process of this embodiment.

[0052] During the initialization phase, the system in this embodiment configures parameters through a configuration file named crypto_server.json, including: the listening address (IP and port), the number of listening sockets corresponding to each listening address, the number of threads in the thread pool, and the connection timeout. The listening address determines which addresses the server's cryptographic machine uses to provide cryptographic services. The number of listening sockets for a single listening address is determined based on the server's processor capabilities and the predicted number of concurrent client connections. To account for blocking factors such as network I / O wait times and cryptographic card driver DMA synchronization wait times, and based on actual performance tuning results, the optimal number of threads in the thread pool is 2 to 4 times the number of CPU physical cores.

[0053] Upon system startup, the configuration file is read first, and each module is dynamically initialized based on the parameters configured therein. This enables dynamic configuration of kernel service parameters, allowing the system to adapt to different deployment environments and performance requirements without recompiling kernel modules, greatly improving the system's usability and operability.

[0054] It should be noted that the sockets within the network module include two types: listening sockets and connection sockets; these two types of sockets coordinate through the kernel I / O multiplexing component. The I / O multiplexing component includes: an interest-based red-black tree, a timer-based red-black tree, and a ready queue.

[0055] Specifically, the interest red-black tree is used to store and index all interest instances, which include socket instances and network events of interest; the key of the interest red-black tree is the file descriptor of the socket; the timer red-black tree is used to store and manage the timeout timers associated with all connection instances, and its key is the timeout timestamp of the timer; the ready queue is used to temporarily store socket instances that are ready due to network events of interest and are waiting for the main event loop to process.

[0056] It should be noted that the system in this embodiment will receive a variety of network events, but only some of them will be processed. These network events are collectively referred to as network events of interest, specifically including: new connection requests, password service requests, and disconnection notifications.

[0057] It should be noted that this embodiment chooses a red-black tree as the core data structure based on its comprehensive high performance and stability under frequent dynamic insertion, deletion, and search operations. In high-concurrency server environments, connection establishment and disconnection are extremely frequent, corresponding to dynamic operations on a large number of nodes; at the same time, the event distribution of massive connections requires extremely fast search speeds. The self-balancing characteristic of red-black trees ensures that even in the worst case, it can maintain an operation performance of O(log n) time complexity, avoiding the risk that ordinary binary search trees may degenerate into linked lists. Compared to hash tables, it avoids performance instability and hash collision problems in the worst case; compared to AVL trees, red-black trees have lower balancing maintenance overhead in frequent write scenarios, thus making red-black trees more advantageous in this embodiment.

[0058] During the network listening phase, the network module, based on the configuration file, calls the kernel function sock_create_kern() to create multiple TCP-type listening sockets and sets the SO_REUSEPORT option for each listening socket so that multiple listening sockets can bind to the same listening address simultaneously. The operating system kernel's built-in load balancer then distributes the new connection requests from the incoming clients evenly to the different listening sockets, thereby achieving horizontal scaling capabilities at the software level and effectively overcoming the bottleneck of a single thread handling new connection requests.

[0059] Furthermore, the network module calls the connection management module to generate a listening instance for the listening Socket, and the I / O multiplexing component performs the following operations:

[0060] The listening instance is encapsulated as a socket instance, and the corresponding network event of interest is set. An interest instance is created and registered in the interest red-black tree. The interest event corresponding to the listening instance is a new connection request.

[0061] The created interest instances and I / O multiplexing component callback functions are encapsulated as wait items and registered in the wait queue of the corresponding listening Socket.

[0062] It should be noted that the callback function of the I / O multiplexing component is used to identify whether the current network event exists in the network events of interest instance. If it does not exist, the current operation ends; if it exists, the socket instance in interest instance is added to the ready queue, and the event main loop is woken up, that is, the event main loop is unblocked.

[0063] Furthermore, the network module creates a dedicated kernel thread for each listening socket. In each thread, kernel_bind() is called sequentially to bind to the listening address specified in the configuration file, and kernel_listen() is used to start listening. The system then waits for the main event loop to process the logic, thus putting the system into a state of continuous listening and processing of network requests.

[0064] It should be noted that the main event loop is an infinite loop that runs in a dedicated thread for listening to the Socket, blocking on the waiting interface of the I / O multiplexing component, waiting for the event to occur.

[0065] When a client initiates a new connection request, the network module receives the request. The operating system kernel's built-in load balancer selects a listening socket, triggers the wait entries registered by the I / O multiplexing component in the waiting queue of that listening socket, and executes the I / O multiplexing component callback function in that wait entry. The I / O multiplexing component callback function identifies that the new connection request exists in the network events of interest in the interest instance corresponding to the wait entry, adds the socket instance in the interest instance to the ready queue, and wakes up the event main loop.

[0066] After the main event loop is awakened, a socket instance is retrieved from the ready queue and converted into a listening instance. The kernel function `kernel_accept()` is then called to accept the connection. Upon successful execution, the kernel returns a new connection socket corresponding to the client. This step is completed directly in kernel mode, completely avoiding the overhead of switching to user mode.

[0067] After successfully creating a connection socket, the network module calls the connection management module, which then performs the following steps:

[0068] A separate data buffer is allocated for the connection socket; the data buffer includes a data receive buffer and a data send buffer; these buffers are physically contiguous blocks of memory, specifically designed to meet the requirements of the cryptographic card driver for DMA (Direct Memory Access) operations. The operating system's kernel network buffers, including the kernel send buffer and the kernel receive buffer, are not contiguous blocks of memory and cannot be directly used by the cryptographic card driver.

[0069] A connection instance is created for the connection socket, and the file descriptor of the connection socket, the pointer to the data receive buffer, the pointer to the data send buffer, the connection status, and the timeout are written into the structure of the connection instance. The connection status includes four types: connected, waiting for data, ready to receive, and ready to send, which is set to "connected" in this case.

[0070] The connection instance is encapsulated as a socket instance, and the corresponding network events of interest are set. An interest instance is created and registered in the interest red-black tree. The interest events corresponding to the connection instance are password service request and disconnection notification.

[0071] The created interest instances and I / O multiplexing component callback functions are encapsulated as wait items and registered in the wait queue of the corresponding connection Socket.

[0072] Simultaneously, a corresponding timer is created based on the timeout period of the connection instance, and the timer is registered in the timer red-black tree of the I / O multiplexing component. The timeout period ensures that any idle connections are automatically cleaned up after a specified time, effectively preventing idle connections from exhausting system resources and guaranteeing the long-term stability of the system.

[0073] It should be noted that before each blocking wait in the main event loop, the timer closest to the current time is retrieved from the timer red-black tree, and its timeout is set as the maximum waiting time for this event blocking. This method cleverly utilizes the ordered nature of the red-black tree to achieve precise timeout control, while merging timeout waiting and I / O event waiting into a single system call, greatly improving CPU efficiency.

[0074] If the main event loop is woken up due to a timer timeout, it indicates that the corresponding connection has been inactive for a long time. All timers that have expired are retrieved from the timer red-black tree and removed, their associated connection sockets are closed, their associated interest instances are removed from the interest red-black tree and released, and the connection management module is notified to destroy the connection instance bound to the timer and release all resources it occupies, including the socket file descriptor and data buffer. This realizes the automatic release mechanism for connection timeout, ensuring the stability and reliability of the system under long-term operation.

[0075] When an established client sends a password service request, the request data (network data packet) is placed into the kernel receive buffer of the corresponding connection socket via the network card and kernel protocol stack. The operating system kernel selects the corresponding connection socket, triggers the wait entry registered by the I / O multiplexing component in its wait queue, and executes the I / O multiplexing component callback function in the wait entry. The I / O multiplexing component callback function identifies that the password service request exists in the network event of interest in the corresponding interest instance, adds the socket instance in the interest instance to the ready queue, and wakes up the event main loop.

[0076] The main event loop retrieves socket instances from the ready queue and converts them into connection instances. It then encapsulates the connection instances and their associated connection handling functions into tasks and sends them to the task queue of the thread pool module. The main event loop thread then returns quickly to continue processing new network events. Meanwhile, computationally intensive cryptographic operations are handled asynchronously by worker threads in the thread pool module. This decouples network I / O from business computation, greatly improving the overall concurrency throughput of the system.

[0077] It should be noted that the sleeping worker threads are kernel worker threads pre-created by the thread pool module at system startup based on the number of threads in the thread pool specified in the configuration file. These threads are initially in a sleeping state and are awakened when tasks appear in the task queue. This embodiment implements the thread pool directly in kernel mode, avoiding the interaction overhead between user-mode threads and the kernel-mode scheduler, thus laying a solid foundation for high-performance concurrent processing.

[0078] The worker threads awakened in the thread pool module extract tasks from the task queue and asynchronously drive the network module to copy the request data from the kernel receive buffer to the data receive buffer in the data buffer corresponding to the connection instance of the connected socket. This step is the first copy in the entire data processing flow, and its purpose is to transfer the data from the general network buffer to the physical contiguous memory designed specifically for the cryptographic card driver. The worker threads identify the connection processing function in the task and call the processing logic of the connection management module.

[0079] Specifically, the connection management module first checks whether the request data in the data receive buffer of the connection instance is complete.

[0080] The predefined message format for request data in this embodiment is as follows: the first two bytes of each complete message are used to identify the total message length. The connection management module compares the length of the request data already received in the data receiving buffer with the total message length based on the message format of the request data.

[0081] If the requested data is incomplete, the connection instance status is set to "Waiting for Data," and the current task is terminated. When the connection socket receives requested data again, the network module appends the new requested data to the end of the connection instance's data receive buffer and triggers the connection management module to perform a data integrity check again by executing a new task. This process repeats until the requested data in the data receive buffer constitutes a complete message, at which point the connection management module updates the connection instance status to "Ready to Receive."

[0082] If the requested data is complete, the connection instance status will be updated to "Receive Ready".

[0083] Once the connection instance's status is updated to "Ready to Receive," the protocol parsing module is invoked. This module parses and processes the complete request data, including: protocol verification, byte order conversion, semantic parsing, and cryptographic card driver invocation.

[0084] Specifically, protocol verification verifies the legitimacy of data; for example, it calculates a checksum or digest for a data packet and compares it with the checksum field in the data packet to ensure that the data has not been tampered with.

[0085] Byte order conversion is the process of converting necessary fields in data (such as length and operation type) from network byte order to host byte order.

[0086] Semantic parsing is the process of resolving the type of cryptographic operation requested by the client (such as encryption, decryption, signature), the key handle used, and the plaintext or ciphertext data to be processed.

[0087] The cryptographic card driver call invokes the corresponding interface of the kernel-mode cryptographic card driver based on the parsed parameters, driving the cryptographic card hardware to perform the actual cryptographic operations. At this point, since the data is already in the DMA-supported buffer, the hardware operations are performed without any additional data copying.

[0088] After the cryptographic operation is completed, the protocol parsing module encapsulates the operation result into complete response data according to the predefined message format of the response data, writes the result into the data sending buffer of the connection instance, and notifies the connection management module.

[0089] The connection management module updates the status of the corresponding connection instance to "send ready".

[0090] After the connection management module finishes processing, the network module checks the status of all connection instances. When it detects that a connection instance is in the "ready to send" state, it retrieves the response data from the connection instance's data send buffer and copies it to the kernel send buffer. This step is the second copy in the entire data processing flow.

[0091] Furthermore, the operating system kernel sends the response data to the client via the network card.

[0092] It's important to note that after data is successfully sent, the connection management module restores the connection instance's state to "waiting for data." This means that the same TCP connection can be reused in multiple consecutive request-response cycles until the connection times out or is actively closed by the client (by sending a disconnect notification). This connection reuse mechanism significantly reduces the system overhead caused by frequently establishing and destroying TCP connections, and is a key method for supporting high concurrency performance.

[0093] It's important to note that the timeout management mechanism of the red-black tree timer is constantly running throughout the entire connection's lifecycle. The timeout period for each connection instance is updated after the network module copies the request data to the data buffer, or after the response data is retrieved from the data buffer and written to the kernel send buffer, based on the current time, thus delaying its expiration. This ensures that only idle connections with no data interaction for extended periods will trigger timer timeouts.

[0094] It should be noted that when the network module receives a disconnection notification, the process is similar to that of receiving a password service request. The task is also encapsulated in the thread pool module's task queue, which will not be elaborated further here. The awakened worker threads in the thread pool module retrieve the task from the task queue. If the task is identified as a disconnection, the network module and connection management module are invoked to remove and destroy related content, including: closing the connection socket, removing and releasing its associated interest instances from the interest red-black tree, destroying the connection instance, and releasing all resources it occupies.

[0095] Compared to existing technologies, this embodiment provides a high-performance cryptographic service system running in kernel space. By placing the entire cryptographic service protocol stack (network communication, protocol parsing, driver invocation) in kernel space and combining it with pre-allocating physically contiguous DMA buffers for each connection, it establishes an efficient path between network data processing and cryptographic operations within kernel space. This reconstructs the implementation location and data processing flow of traditional cryptographic services, requiring only two data copies within kernel space throughout the entire processing flow. This achieves the shortest data path from network reception to hardware driver invocation. It fundamentally eliminates the performance bottleneck of multiple copies across privilege boundaries in traditional architectures, significantly reducing data processing latency and greatly improving system throughput and CPU efficiency. An event-driven I / O multiplexing component is employed, utilizing dual red-black trees to achieve efficient and stable management and precise timeout control for massive connections. The collaborative design of the kernel thread pool and connection instance states enables connection reuse and asynchronous task processing, effectively balancing computational and I / O resources and ensuring high availability and stability of the system in high-concurrency scenarios.

[0096] Example 2

[0097] Another embodiment of the present invention discloses a high-performance cryptographic service method running in kernel mode, thereby implementing the functionality of a high-performance cryptographic service system running in kernel mode as described in Embodiment 1. The specific implementation of each step is described in the corresponding module descriptions of Embodiment 1. Figure 2 As shown, the method includes the following steps:

[0098] S1. Create multiple listening sockets in the operating system kernel;

[0099] S2. When a new connection request is received, the corresponding listening Socket accepts the connection and establishes a connection Socket; it creates a connection instance of the connection Socket, manages its state, and allocates a data buffer;

[0100] S3. When a password service request is received, encapsulate the task into the task queue;

[0101] S4. When executing a task in the task queue, the request data is copied from the kernel receive buffer to the data buffer corresponding to the connection instance of the connected socket. If the request data in the data buffer is found to be complete, the request data is parsed, the kernel-mode cryptographic card driver is called to perform cryptographic operations, and the operation result is encapsulated as response data and written to the data buffer.

[0102] S5. Retrieve the response data from the data buffer and write it to the kernel send buffer. The operating system kernel then sends the response data to the client via the network card.

[0103] Since the high-performance cryptographic service method running in kernel mode in this embodiment and the aforementioned high-performance cryptographic service system running in kernel mode can be mutually referenced, this description is redundant and will not be repeated here. Because this method embodiment shares the same principle as the aforementioned system embodiment, it also possesses the corresponding technical effects of the aforementioned system embodiment.

[0104] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0105] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A high-performance cryptographic service system running in kernel mode, characterized in that, The system is deployed in the operating system kernel and includes: The network module is used to create multiple listening sockets; when a new connection request is received, the corresponding listening socket accepts the connection and establishes a connection socket; when a password service request is received, the task is encapsulated and sent to the thread pool module, the request data is copied to the data buffer corresponding to the connection instance of the connection socket, and the response data is retrieved from the data buffer; The connection management module is used to create connection instances of the connection socket and manage their state, allocate data buffers, and call the protocol parsing module when the completeness of the requested data is detected. The thread pool module is used to allocate worker threads to execute tasks in the task queue and trigger the connection management module to check the data buffer. The protocol parsing module is used to parse the request data in the data buffer, call the kernel-mode cryptographic card driver to perform cryptographic operations, and encapsulate the operation results into response data and write them into the data buffer.

2. The high-performance cryptographic service system running in kernel mode according to claim 1, characterized in that, The network module also includes an I / O multiplexing component, which includes an interest red-black tree, a timer red-black tree, and a ready queue. The interest red-black tree stores and indexes all interest instances. Each interest instance includes a socket instance and an interest network event. The timer red-black tree stores and manages timeout timers associated with all connection instances. The ready queue temporarily stores socket instances that are ready due to interest network events and are waiting for the main event loop to process.

3. The high-performance cryptographic service system running in kernel mode according to claim 2, characterized in that, The network module calls the connection management module to generate a listening instance for the listening socket; When a listener instance or connection instance is created, the I / O multiplexing component performs the following operations: Encapsulate the listening instance or connection instance into a socket instance, set the corresponding network events of interest, create an interest instance, and register the interest instance into the interest red-black tree; The created interest instances and I / O multiplexing component callback functions are encapsulated as wait items and registered to the wait queue of the corresponding listening Socket or connection Socket.

4. The high-performance cryptographic service system running in kernel mode according to claim 3, characterized in that, When the network module receives a new connection request, it performs the following steps: The operating system kernel selects the corresponding listening socket, triggers the wait item registered by the I / O multiplexing component in its wait queue, and executes the I / O multiplexing component callback function in the wait item; the I / O multiplexing component callback function identifies that the new connection request exists in the network event of interest in the corresponding interest instance, adds the socket instance in the interest instance to the ready queue, and wakes up the event main loop; The main event loop retrieves a socket instance from the ready queue and converts it into a listening instance, then calls the operating system kernel's connection acceptance interface to establish a connection socket. The connection management module is invoked to create a connection instance for the connection socket.

5. The high-performance cryptographic service system running in kernel mode according to claim 2, characterized in that, When the network module receives a cryptographic service request, it performs the following steps: The operating system kernel selects the corresponding connection socket, triggers the wait item registered by the I / O multiplexing component in its wait queue, and executes the I / O multiplexing component callback function in the wait item; the I / O multiplexing component callback function identifies that the password service request exists in the network event of interest in the corresponding interest instance, adds the socket instance in the interest instance to the ready queue, and wakes up the event main loop; The main event loop retrieves socket instances from the ready queue, converts them into connection instances, and encapsulates the tasks into the task queue of the thread pool module.

6. The high-performance cryptographic service system running in kernel mode according to claim 4, characterized in that, When the connection management module creates a connection instance for the connection socket, it initializes the status of the connection instance to "connected", creates a corresponding timer based on the timeout of the connection instance, and registers the timer in the timer red-black tree of the I / O multiplexing component. The timeout of the timer is updated after the network module copies the request data to the data buffer, or after the response data is retrieved from the data buffer and written to the kernel send buffer, based on the new timeout calculated from the current time.

7. The high-performance cryptographic service system running in kernel mode according to claim 2, characterized in that, The network module also performs connection timeout processing through the I / O multiplexing component, including: Before each blocking wait in the main event loop, the timer closest to the current time is obtained from the timer red-black tree, and its timeout is set as the maximum waiting time for this event blocking. When the main event loop is woken up due to timer timeout, all timers that have expired are retrieved from the timer red-black tree and removed, their associated connection sockets are closed, their associated interest instances are removed from the interest red-black tree and released, and the connection management module is notified to destroy the corresponding connection instance.

8. The high-performance cryptographic service system running in kernel mode according to claim 1, characterized in that, The connection management module checks whether the requested data in the data buffer is complete. If the requested data is incomplete, the status of the connection instance is updated to "waiting for data"; if the requested data is complete, the status of the connection instance is updated to "ready to receive".

9. The high-performance cryptographic service system running in kernel mode according to claim 8, characterized in that, After the protocol parsing module writes the response data into the data buffer, it updates the status of the connection instance to "ready to send". When the network module detects that the status of the connection instance is "ready to send", it retrieves the response data from the data buffer and writes it into the kernel send buffer.

10. A high-performance cryptographic service method running in kernel mode, characterized in that, Includes the following steps: Create multiple listening sockets in the operating system kernel; When a new connection request is received, the corresponding listening socket accepts the connection and establishes a connection socket; a connection instance of the connection socket is created and its state is managed, and a data buffer is allocated; When a password service request is received, the task is encapsulated and added to the task queue; When executing a task in the task queue, the request data is copied from the kernel receive buffer to the data buffer corresponding to the connection instance of the connected socket. If the request data in the data buffer is found to be complete, the request data is parsed, the kernel-mode cryptographic card driver is called to perform cryptographic operations, and the operation result is encapsulated as response data and written to the data buffer. The response data is retrieved from the data buffer and written to the kernel send buffer. The operating system kernel then sends the response data to the client via the network card.

Images