A Linux kernel cryptography subsystem algorithm proxy method and related apparatus

Abstract

The application provides a Linux kernel cryptography subsystem algorithm proxy method and related devices, and relates to the technical field of information security. The kernel state is used to build a KNC proxy framework to realize algorithm-independent abstraction, and a three-stage asynchronous pipeline and a seqno sequence number mechanism are combined to complete accurate matching and transparent forwarding of requests, effectively solving the technical bottleneck that kernel cryptography requests cannot be seamlessly proxied to remote devices in the prior art, and having the advantages that the kernel cryptography request can be transparently proxied to a remote cryptography device for execution, and the upper calling party is not aware.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a method and apparatus for proxying algorithms in a Linux kernel cryptographic subsystem. Background Technology

[0002] The Linux kernel's crypto subsystem, serving as the core abstraction layer for kernel-level cryptography capabilities, provides a unified interface for calling cryptographic algorithms to upper-level modules such as IPsec, dm-crypt, and AF_ALG. This subsystem covers five major algorithm types: symmetric encryption (skcipher), authentication encryption (aead), asynchronous hashing (ahash), asymmetric encryption (akcipher), and key agreement protocol (kpp). It allocates algorithm handles through interfaces such as `crypto_alloc_skcipher` and submits asynchronous cryptographic requests using standard interfaces like `crypto_s'k'cipher_encrypt`. These requests are executed locally by kernel-registered algorithm implementations and processed through an asynchronous callback mechanism, forming a highly standardized and modular kernel cryptographic calling system that ensures efficient and consistent cryptographic operation support.

[0003] However, the current Linux kernel cryptographic framework suffers from a fundamental technical flaw: the computation and execution of all cryptographic algorithms must be performed entirely on the local CPU within the kernel. It cannot transparently forward standard cryptographic requests from the kernel's crypto subsystem to external cryptographic devices such as Hardware Security Modules (HSMs), cryptographic accelerator cards, and remote cryptographic servers. This limitation prevents the system from effectively utilizing external high-performance or dedicated cryptographic hardware resources, severely hindering the expansion and optimization of cryptographic computation capabilities. When users forcibly bypass the kernel's crypto subsystem to communicate directly with external devices to access remote cryptographic resources, they inevitably lose critical functions provided by the kernel itself, such as the unified calling interface, request queue management, and asynchronous callback mechanisms. In this case, each application layer must independently implement complex network communication protocols, data serialization and deserialization, timeout retry logic, and exception handling mechanisms. This approach not only significantly increases system integration costs but also results in low code reusability, difficulty in guaranteeing compatibility and stability, and ultimately prevents seamless integration with the existing kernel cryptographic ecosystem. Therefore, there is an urgent need for an algorithm proxy framework that can run in kernel mode and seamlessly interface with the Linux kernel crypto subsystem to transparently proxy any type of asynchronous cryptographic request to remote cryptographic devices for execution, while ensuring that the upper-layer caller is completely unaware of it, thereby solving the technical bottleneck that the existing framework cannot adapt to remote cryptographic devices.

[0004] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0005] This application provides a Linux kernel cryptography subsystem algorithm proxy method and related apparatus, which has the advantage of being able to transparently proxy kernel cryptographic requests to remote cryptographic devices for execution, while keeping the upper-layer caller unaware of the request.

[0006] Firstly, the Linux kernel cryptography subsystem algorithm proxy method provided in this application adopts the following technical solution: A Linux kernel cryptographic subsystem algorithm proxy method includes: A KNC proxy framework is built in kernel mode to seamlessly interface with the Linux kernel crypto subsystem. For the five types of cryptographic algorithms of the crypto subsystem, namely symmetric encryption, authentication encryption, asynchronous hashing, asymmetric encryption, and key negotiation protocol, a unified extended operation table xops is defined to achieve algorithm-independent abstraction. Based on the xops, a three-level asynchronous pipeline of sendq-recvq-cmplq is constructed. The unified entry point knc_submit_areq receives crypto_async_request asynchronous requests. The pipeline completes request serialization and sending, response reception and deserialization, and request completion or retry decision-making. Maintain a 64-bit auto-incrementing sequence number seqno for each TCP connection, write the seqno into the request and transmit it with the network frame, and achieve precise correspondence between request and response by matching seqno; A framework-level global retry queue is established to asynchronously retry and reroute failed requests, and to transparently forward cryptographic computation requests to remote cryptographic devices for execution.

[0007] Optionally, the extended operation table xops includes nine function pointers: set_seqno, get_seqno, set_erc, get_erc, pack, recv, route, complete_or_retry, and is_retrying. The xops pointer is extracted from crypto_async_request using the container_of macro, thus decoupling the framework code from specific algorithm types.

[0008] Optionally, the three-stage asynchronous pipeline is configured with three sets of worker threads: send_worker, recv_worker, and cmpl_worker. The send_worker thread dequeues requests in batches from the send queue sendq, serializes them in batches via the send control block SCB, and then sends them in a single TCP sendmsg. After sending, the requests are moved into the receive queue recvq. The recv_worker thread dequeues requests in batches from recvq, parses and deserializes response frames based on seqno and last_seen / last_partial state machines, and then moves the requests into the completion queue cmplq. The cmpl_worker thread dequeues requests in batches from cmplq, reads the error code ERC, and makes a decision through complete_or_retry. If there is no error, it directly completes the callback; if it can be retried, it moves the request to the global retry queue.

[0009] Optionally, the send_worker thread performs backpressure control: before packaging, it waits for available space in recvq to avoid sending speed exceeding receiving processing capacity; at the same time, it processes sendq backlog requests, calls back -EINPROGRESS for the first squeezed backlog request, and skips the callback for backlog requests in retry.

[0010] Optionally, the seqno sequence number mechanism further includes: using signed difference arithmetic knc_seqno_after to process 64-bit sequence number wrapping, so as to correctly determine the order of requests even after the sequence number overflows; and detecting duplicate responses, kernel missed reception, and abnormal frame loss at the peer end by comparing the size of seqno.

[0011] Optionally, the processing flow of the global retry queue is as follows: the retry_worker thread retrieves retry requests in batches, clears error codes, and resubmits them using submit_areq; during resubmission, the routing schedule is re-executed, switching to a healthy connection to bypass the faulty node; after reaching the maximum number of attempts max_attempts, the retry is terminated and a callback is executed.

[0012] Optionally, the KNC proxy framework also supports: binding three-level pipeline threads to the same CPU core through the pipeline_bind_cpu module parameter to improve cache locality; integrating the kernel so that the kernel automatically completes transmission encryption and the framework handles encrypted transmission without being aware of it; and supporting three routing scheduling strategies: random, minimum load, and specified connection to adapt to different remote cryptographic device deployment scenarios.

[0013] Secondly, this application provides a Linux kernel cryptography subsystem algorithm proxy system, comprising: The framework building module is used to build a KNC proxy framework that seamlessly integrates with the Linux kernel crypto subsystem in kernel mode. It defines a unified extended operation table xops for the five types of cryptographic algorithms of the crypto subsystem, namely symmetric encryption, authentication encryption, asynchronous hashing, asymmetric encryption, and key negotiation protocol, to achieve algorithm-independent abstraction. The pipeline construction module is used to build a three-level asynchronous pipeline of sendq-recvq-cmplq based on the xops. It receives crypto_async_request asynchronous requests through a unified entry point knc_submit_areq, and completes request serialization and sending, response reception and deserialization, and request completion or retry decision through the pipeline. The request writing module is used to maintain a 64-bit auto-incrementing sequence number seqno for each TCP connection, write the seqno into the request and transmit it with the network frame, and achieve precise correspondence between request and response by matching seqno. The global retry module is used to build a framework-level global retry queue, perform asynchronous retry and rerouting of retryable failed requests, and transparently forward cryptographic calculation requests to remote cryptographic devices for execution.

[0014] Thirdly, this application provides a computer device, the device comprising: a memory and a processor, wherein the processor, when executing computer instructions stored in the memory, performs the method described above.

[0015] Fourthly, this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method described above.

[0016] In summary, this application achieves algorithm-independent abstraction by building a KNC proxy framework in kernel mode, and combines a three-level asynchronous pipeline with the seqno sequence number mechanism to complete accurate matching and transparent forwarding of requests. This effectively solves the technical bottleneck of existing technologies that cannot seamlessly proxy kernel cryptographic requests to remote devices. It has the advantage of being able to transparently proxy kernel cryptographic requests to remote cryptographic devices for execution, while keeping the upper-layer caller unaware of the changes. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the computer device structure of the hardware operating environment involved in the embodiments of this application; Figure 2 This is a flowchart illustrating the first embodiment of the Linux kernel cryptography subsystem algorithm proxy method of this application; Figure 3 This is a structural block diagram of the first embodiment of the Linux kernel cryptography subsystem algorithm proxy system of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] Reference Figure 1 , Figure 1 This is a schematic diagram of the computer device structure of the hardware operating environment involved in the embodiments of this application.

[0020] like Figure 1 As shown, the computer device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen, an input unit such as a keyboard, and may also include standard wired or wireless interfaces. The network interface 1004 may optionally include standard wired or wireless interfaces (such as Wireless-Fidelity (Wi-Fi) interfaces). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0021] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0022] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a Linux kernel cryptography subsystem algorithm proxy program.

[0023] exist Figure 1In the computer device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in this application can be set in the computer device, and the computer device calls the Linux kernel cryptography subsystem algorithm proxy program stored in the memory 1005 through the processor 1001, and executes the Linux kernel cryptography subsystem algorithm proxy method provided in the embodiment of this application.

[0024] Traditional Linux kernel cryptographic frameworks require cryptographic algorithm computation and execution to be performed locally within the kernel using the native CPU. They cannot transparently forward standard cryptographic requests from the kernel's crypto subsystem to external cryptographic devices such as hardware security modules, cryptographic accelerator cards, or remote cryptographic servers. Forcibly bypassing the kernel's crypto subsystem would result in the loss of fundamental capabilities natively provided by the kernel, such as a unified calling interface, request queue management, and asynchronous callback mechanisms. This would necessitate each application layer to independently implement complex logic, leading to high system integration costs, low code reusability, and difficulties in ensuring compatibility and stability, ultimately hindering seamless integration with the existing kernel cryptographic ecosystem.

[0025] To address this, this application provides a Linux kernel cryptographic subsystem algorithm proxy method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the Linux kernel cryptography subsystem algorithm proxy method of this application.

[0026] In this embodiment, the Linux kernel cryptography subsystem algorithm proxy method includes the following steps: Step S10: Build a KNC proxy framework in kernel mode that seamlessly interfaces with the Linux kernel crypto subsystem. Define a unified extended operation table xops for the five types of cryptographic algorithms of the crypto subsystem: symmetric encryption, authentication encryption, asynchronous hashing, asymmetric encryption, and key negotiation protocol, to achieve algorithm-independent abstraction.

[0027] Step S20: Based on the xops, construct a three-level asynchronous pipeline of sendq-recvq-cmplq. Receive asynchronous requests of crypto_async_request through a unified entry point knc_submit_areq. The pipeline completes request serialization and sending, response reception and deserialization, and request completion or retry decision-making. Step S30: Maintain a 64-bit auto-incrementing sequence number seqno for each TCP connection, write seqno into the request and transmit it with the network frame, and achieve accurate correspondence between request and response by matching seqno; Step S40: Build a framework-level global retry queue, perform asynchronous retry and rerouting of retryable failed requests, and transparently forward cryptographic calculation requests to remote cryptographic devices for execution.

[0028] For ease of understanding, the following explains some key terms in this embodiment: KNC Proxy Framework: This framework is a software module that runs in the Linux kernel space. It acts as a bridge between the Linux kernel crypto subsystem and remote cryptographic devices, enabling transparent proxying and forwarding of cryptographic requests.

[0029] Linux kernel crypto subsystem: This subsystem is the core component in the Linux kernel that provides cryptographic services, providing a unified cryptographic algorithm calling interface for upper-layer applications and modules, and supporting multiple cryptographic algorithm types.

[0030] The extended operation table `xops` is a collection of function pointers used to define a unified set of operation interfaces that are independent of specific cryptographic algorithm types. Through this table, the KNC proxy framework can handle different types of cryptographic algorithm requests in a uniform manner.

[0031] The sendq-recvq-cmplq three-level asynchronous pipeline: This pipeline is a request processing mechanism consisting of three queues (sendq, recvq, cmplq) used to asynchronously process the sending, receiving, and completion decisions of password requests.

[0032] knc_submit_areq: This interface is the unified entry point for the KNC proxy framework, used to receive asynchronous cryptographic requests from the Linux kernel crypto subsystem.

[0033] crypto_async_request: This structure is a standard data structure used by the Linux kernel crypto subsystem to encapsulate asynchronous cryptographic requests, containing information such as the request type, data, and callback function.

[0034] seqno: This sequence number is a 64-bit auto-incrementing sequence number, maintained independently for each TCP connection. Its purpose is to uniquely identify each sent cipher request and to match requests with responses when they are received.

[0035] Global Retry Queue: This queue is a data structure maintained internally by the KNC agent framework to store password requests that failed to be processed due to temporary errors. These requests will be resubmitted and rescheduled asynchronously.

[0036] Remote cryptographic device: This device refers to a hardware or software entity that performs cryptographic calculations on a non-local CPU, such as a hardware security module, a cryptographic accelerator card, or a remote cryptographic server.

[0037] In practical implementation, firstly, a KNC proxy framework is built in kernel space and seamlessly integrated with the Linux kernel crypto subsystem. This KNC proxy framework can be implemented as a kernel module, intercepting or proxying cryptographic requests through a general interface registered with the Linux kernel crypto subsystem. For example, a separate set of interface functions can be defined for each type of cryptographic algorithm (such as symmetric encryption, authentication encryption, asynchronous hashing, asymmetric encryption, and key negotiation protocols), and distributed within the KNC proxy framework according to the request type. Alternatively, the KNC proxy framework can employ a structure pointer-based mechanism, encapsulating specific operations of different algorithms in their respective structures and referencing them through a general pointer. When a cryptographic request is received, the framework dynamically looks up and invokes the corresponding operation based on the requested algorithm type. As another implementation approach, the KNC proxy framework can maintain a global mapping table, associating the identifier of each cryptographic algorithm with a set of predefined operation functions. When processing a request, the framework queries this mapping table to obtain and execute the corresponding operation. Through these methods, a unified extended operation table (xops) is defined for the five types of cryptographic algorithms in the crypto subsystem to achieve algorithm-independent abstraction.

[0038] Furthermore, a three-stage asynchronous pipeline of sendq-recvq-cmplq is constructed based on this xops. This three-stage asynchronous pipeline can consist of three independent queues (sendq, recvq, and cmplq), and these queues are polled by one or more worker threads. For example, a single worker thread can be responsible for retrieving a request from sendq, serializing it, sending it, and then placing it into recvq; next, it can retrieve the response from recvq, deserialize it, and place it into cmplq; finally, it can retrieve the request from cmplq for completion or retry decision. Alternatively, an event-driven mechanism can be used to manage the pipeline. When a request enters sendq, a send event is triggered, the event handler performs serialization and sending, and moves the request to recvq. When a response arrives, a receive event is triggered, the event handler performs deserialization and moves the response into the completion queue cmplq. When a request is ready in cmplq, a completion event is triggered for decision. As one implementation, each queue in the pipeline can be configured as a circular buffer and use a producer-consumer model for data transmission. The unified entry point knc_submit_areq receives crypto_async_request asynchronous requests, and the pipeline completes request serialization and sending, response reception and deserialization, and request completion or retry decision-making.

[0039] In addition, a 64-bit auto-incrementing sequence number (seqno) is maintained for each TCP connection. This seqno can be simply implemented as an unsigned 64-bit integer, incrementing with each request sent. When a response is received, the corresponding request is determined by linearly searching the seqno carried in the response against the local list of seqnos of sent requests. Alternatively, a hash table can be maintained for each TCP connection, where the key is the seqno and the value is the corresponding request context. When a request is sent, the seqno and request context are stored in the hash table; when a response is received, the seqno in the response is used as the key to quickly retrieve the corresponding request context from the hash table. As one implementation, the seqno can be embedded in a fixed header field of the request packet. At the sending end, this field is updated before each transmission; at the receiving end, the packet header is parsed to extract the seqno, which is then used to match the request awaiting a response. This seqno is written into the request and transmitted with the network frame, achieving a precise correspondence between request and response through seqno matching.

[0040] Simultaneously, a framework-level global retry queue is established. This global retry queue can be implemented as a first-in, first-out (FIFO) queue; when a request fails to process and is determined to be retryable, it is placed in this queue. A separate retry manager periodically retrieves requests from the queue and resubmits them to the `knc_submit_areq` entry. Routing can simply select any currently available TCP connection for forwarding. Alternatively, the retry queue can be a priority queue, assigning different priorities based on the number of retries or error type. The retry manager prioritizes high-priority requests. During rerouting, a round-robin approach can be used to select different remote cryptographic devices or TCP connections. As one implementation, the retry queue can be combined with a timer mechanism. When a request enters the retry queue, a retry interval is set for it. When the timer expires, the retry manager retrieves the request and resubmits it. Routing can forward requests to specific remote cryptographic devices based on preset static configurations. Asynchronous retransmission and rerouting are performed on retryable failed requests, transparently forwarding cryptographic computation requests to remote cryptographic devices for execution.

[0041] This embodiment achieves seamless integration and algorithm-independent abstraction between the Linux kernel crypto subsystem and remote cryptographic devices by building a KNC proxy framework in kernel space and defining a unified extended operation table xops. Based on a three-level asynchronous pipeline and a unified entry point knc_submit_areq, it can efficiently handle the serialization, sending, receiving, and deserialization of asynchronous cryptographic requests. By maintaining a 64-bit auto-incrementing sequence number seqno for each TCP connection, it ensures accurate matching of requests and responses. In addition, the introduction of a framework-level global retry queue enables retryable failed requests to be asynchronously retransmitted and rerouted, thereby transparently forwarding cryptographic computation requests to remote cryptographic devices for execution. This effectively solves the technical problems of traditional kernel cryptographic frameworks being unable to adapt to remote cryptographic devices, having high integration costs, and poor compatibility.

[0042] In some of the above implementations, the KNC proxy framework aims to provide a unified abstract interface for various cryptographic algorithms and process requests through asynchronous pipelines. However, a key issue that needs to be addressed is how to effectively manage and schedule these diverse cryptographic operations while ensuring a high degree of decoupling between the framework code and the underlying specific algorithm implementations to accommodate future algorithm expansions and changes. Tight coupling of the framework code with the operational details of each algorithm will increase system complexity, raise maintenance costs, and limit its flexibility and scalability.

[0043] To address this, this embodiment further proposes that the extended operation table xops includes nine function pointers: set_seqno, get_seqno, set_erc, get_erc, pack, recv, route, complete_or_retry, and is_retrying; and the xops pointer is extracted from crypto_async_request through the container_of macro, thereby decoupling the framework code from the specific algorithm type.

[0044] The extended operation table `xops` contains nine function pointers: `set_seqno`, `get_seqno`, `set_erc`, `get_erc`, `pack`, `recv`, `route`, `complete_or_retry`, and `is_retrying`. These function pointers collectively form a unified interface, enabling the KNC proxy framework to handle different types of cryptographic algorithm requests in a consistent manner. For example, the `set_seqno` and `get_seqno` pointers manage the request sequence number, ensuring accurate matching of requests and responses in asynchronous communication. The `pack` and `recv` pointers handle the serialization and deserialization of requests and responses, which is crucial for converting the kernel-mode `crypto_async_request` structure into a network transmission format and for recovering received network data into a processable request. The `set_erc` and `get_erc` pointers are used to uniformly set and retrieve error codes, providing a basis for subsequent error handling and retry decisions. The `route` pointer is responsible for selecting an appropriate remote cryptographic device connection for request forwarding according to a preset strategy. The `complete_or_retry` and `is_retrying` pointers, located at the end of the request processing, determine whether the request is complete or needs to enter a retry process based on the request status and error code. Through these abstract function pointers, the framework layer doesn't need to concern itself with the implementation details of the specific algorithms; it only needs to call the corresponding pointers to complete the operation.

[0045] By using the `container_of` macro to extract xops pointers from `crypto_async_request`, the framework code is decoupled from specific algorithm types. The `container_of` macro is a common technique in the Linux kernel that allows the starting address of the structure containing a member to be derived from the address of that member. In this approach, by associating xops pointers with the `crypto_async_request` structure and extracting them using the `container_of` macro, it ensures that each asynchronous request can dynamically obtain its corresponding algorithm operation table. This mechanism allows the KNC proxy framework to flexibly call the correct set of xops functions based on the request type or context when processing `crypto_async_request`, thus achieving deep decoupling between the framework code and specific cryptographic algorithm types. This means that when a new cryptographic algorithm needs to be integrated, only a new xops implementation needs to be provided without modifying the core logic of the KNC proxy framework, greatly improving the maintainability and scalability of the system.

[0046] By introducing an extended operation table (xops) containing specific function pointers and utilizing the `container_of` macro to dynamically associate xops pointers with `crypto_async_request`, this solution effectively addresses the problem of tight coupling between framework code and specific cryptographic algorithm types. The framework layer does not need to hardcode the details of various algorithms; instead, it calls corresponding operations such as serialization, deserialization, sequence number management, error handling, and routing decisions through a unified xops interface. This design enables the KNC proxy framework to handle different types of cryptographic algorithm requests in a highly abstract and unified manner, greatly improving the system's flexibility and scalability. When new cryptographic algorithms need to be supported, only a new set of xops functions needs to be implemented and associated with the corresponding request, without modifying the core logic of the framework. This reduces development and maintenance costs and ensures that the system can quickly adapt to constantly changing cryptographic algorithm requirements.

[0047] To address this, this embodiment proposes a Linux kernel cryptographic subsystem algorithm proxy method, which constructs a three-stage asynchronous pipeline of sendq-recvq-cmplq. Asynchronous requests (crypto_async_request) are received through a unified entry point, knc_submit_areq. The pipeline handles request serialization and sending, response reception and deserialization, and request completion / retry decisions. However, in practical implementation, relying solely on queues for request transmission without an efficient and independent mechanism to drive each stage of processing can lead to mutual blocking between pipeline stages, reducing overall processing efficiency. Especially in high-concurrency scenarios, ensuring rapid request flow, accurate response matching, and flexible error handling are key challenges in achieving high-performance proxying.

[0048] To effectively drive the aforementioned three-stage asynchronous pipeline, this embodiment configures three independent worker threads: the send_worker thread, the recv_worker thread, and the cmpl_worker thread. Each thread group is specifically responsible for a particular stage of the pipeline, thereby achieving task decoupling and parallel processing. This design pattern avoids mutual blocking between different processing stages and improves the system's concurrent processing capabilities. For example, these worker threads can be implemented as kernel threads or through kernel work queues, running independently in kernel mode and communicating efficiently through shared memory and queue mechanisms.

[0049] Specifically, the primary responsibility of the `send_worker` thread is to retrieve batches of cryptographic computation requests to be sent from the `sendq` queue. To improve network transmission efficiency, these requests are batch serialized via the Send Control Block (SCB). The SCB can be a custom data structure used to encapsulate the metadata and data of multiple requests, converting them into a byte stream suitable for network transmission. Subsequently, the `send_worker` thread completes the aggregated sending through a single `TCPsendmsg` system call. Aggregated sending significantly reduces the number of network subsystem calls and network packets, lowering CPU overhead and network latency. After a request is successfully sent, the `send_worker` thread updates the status of these requests and moves them to the `recvq` queue, awaiting a response from the remote cryptographic device.

[0050] The `recv_worker` thread is responsible for retrieving batches of sent requests awaiting responses from the `recvq` queue. Simultaneously, it listens for and receives response frames from remote cryptographic devices. To accurately match requests and responses, the `recv_worker` thread parses the response frame based on the auto-incrementing sequence number `seqno` carried in the request and the internally maintained `last_seen` / `last_partial` state machine. `last_seen` records the sequence number of the last fully received response, while `last_partial` is used to process partially received frames. Through this state machine mechanism, even in complex network environments where responses may be out of order or fragmented, it efficiently (with a time and space complexity of O(1) under normal service conditions and O(n) in the worst case) ensures accurate matching and integrity of requests and responses. After the response frame is parsed, the data is deserialized back to the original response data structure, and the corresponding request is moved into the `cmplq` queue.

[0051] The `cmpl_worker` thread is responsible for retrieving requests with received responses in batches from the completion queue `cmplq`. For each request, the `cmpl_worker` thread reads its internal error code `erc`. Then, it calls the `complete_or_retry` function pointer to decide on the request. If the error code `erc` indicates that the request is error-free, the completion function is called back directly, notifying the upper-layer application that the cryptographic calculation request has been successfully completed. If the error code `erc` indicates that the request has a retryable error (e.g., the remote device is temporarily unavailable), the request is moved to the global retry queue, awaiting subsequent asynchronous retry processing. This mechanism implements flexible error handling and recovery capabilities, avoiding request failures due to transient errors.

[0052] By combining the three-stage asynchronous pipeline with three independent worker threads—send_worker, recv_worker, and cmpl_worker—the above technical solution achieves refined management and efficient parallelization of the cryptographic computation request processing flow. The send_worker thread significantly reduces kernel network stack call overhead and network transmission burden by using batch dequeueing, batch serialization, and single TCP sendmsg aggregation, thereby improving request sending efficiency. The recv_worker thread utilizes the seqno and last_seen / last_partial state machines to ensure accurate parsing of response frames and precise matching of requests and responses in complex network environments, enhancing the efficiency and reliability of data processing. The cmpl_worker thread intelligently decides by reading error codes (erc) and calling the complete_or_retry function, achieving transparent handling and asynchronous retrying of retryable errors, greatly improving the system's fault tolerance and resilience. Overall, this multi-threaded, phased pipeline design effectively decouples the various processing stages, eliminates potential performance bottlenecks, and enables the Linux kernel cryptography subsystem algorithm proxy method to transparently forward cryptographic computation requests to remote cryptographic devices for execution with higher throughput and lower latency. In some of the embodiments described above, the send_worker thread is responsible for dequeuing requests in batches from the send queue sendq and sending them to the network, and then moving the requests into the receive queue recvq. However, if the send_worker thread sends requests too quickly, exceeding the processing capacity of the recv_worker thread or the network transmission capacity, it may cause recvq to accumulate rapidly or even overflow, leading to problems such as exhaustion of system resources, increased request processing latency, or data loss, affecting the stability and efficiency of the entire asynchronous pipeline.

[0053] To address this, this embodiment further proposes that the send_worker thread performs backpressure control. Specifically, it waits for available space in recvq before packaging to avoid the sending speed exceeding the receiving processing capacity. At the same time, the send_worker thread also handles sendq backlog requests, calling back -EINPROGRESS for the first squeezed backlog request, while skipping the callback for backlog requests that are being retried.

[0054] The backpressure control executed by the send_worker thread is a flow management mechanism. Its core lies in adjusting the data sender's (send_worker thread) rate to match the data receiver's (recv_worker thread or network) processing capacity. This mechanism aims to prevent upstream producers from overloading downstream consumers due to excessively fast sending, thereby maintaining the stability and efficiency of the entire data processing pipeline. Specifically, before packaging requests and sending them over the network, the send_worker thread actively checks the current state of the recvq, especially its available space. If there is insufficient free space in the recvq, the send_worker thread will pause or slow down its sending operation until the recv_worker thread processes and clears some requests in the recvq, releasing sufficient space. This waiting mechanism can be implemented through polling, condition variable notification, or threshold judgment based on queue watermarks, ensuring that the send_worker thread's sending rate does not exceed the recv_worker thread's receiving and processing capacity, effectively preventing recvq overflow.

[0055] In asynchronous pipelines, backlog requests refer to those requests that require flow control due to overload of sendq caused by untimely processing in the three-stage pipeline. Their original submitters must adhere to the semantics of the Linux kernel's Crypto subsystem, slowing down the submission of subsequent requests. The send_worker thread, while processing new submissions, is also responsible for identifying and processing these backlog requests from sendq, ensuring all requests are ultimately handled properly. When a backlog request is first retrieved from sendq by the send_worker thread and prepared for a send attempt, the system sends a -EINPROGRESS status code back to the original submitter or the upper-layer module. This callback explicitly informs the upper layer that the request has been accepted and is being processed asynchronously; although the final result is not yet determined, subsequent requests can be submitted. This provides transparency of request processing progress to the upper-layer application, avoiding unnecessary timeouts or duplicate submissions. For backlog requests already in the retry process, the send_worker thread will not send the -EINPROGRESS callback in subsequent retry attempts.

[0056] Through the above technical solution, the send_worker thread implements backpressure control, waiting for available space in the recvq before sending packets, effectively matching its sending rate with the receiving and processing capacity of the recv_worker thread. This significantly avoids recvq backlog and overflow issues caused by upstream excessively fast sending, thus ensuring the stable operation of the entire three-stage asynchronous pipeline, preventing the exhaustion of system resources, and ensuring that requests are processed efficiently and orderly, significantly improving the overall throughput and response speed of the system. Simultaneously, the intelligent handling of backlog requests in sendq, especially the -EINPROGRESS callback for the first squeezed request, provides clear request processing status feedback to the upper-layer application, enhancing the transparency of system flow control. Skipping callbacks for backlog requests in retry ensures the correctness of upper-layer semantics, optimizes system resource utilization, reduces unnecessary notification overhead, and makes the retry mechanism more efficient and robust, further improving the reliability and final completion rate of cryptographic computation requests.

[0057] In some of the embodiments described above, a precise correspondence between requests and responses is achieved by maintaining a 64-bit auto-incrementing sequence number (seqno) for each TCP connection and writing the seqno into the request and transmitting it with the network frame. However, in long-term operation or high-concurrency scenarios, the 64-bit auto-incrementing sequence number (seqno) may still overflow and wrap around, causing the sequence number comparison logic to fail, thus affecting the correct matching of requests and responses. In addition, abnormal situations such as duplicate responses, kernel missed reception, or frame loss at the peer end may occur during network transmission. If these are not effectively identified and handled, they will further impair the stability and data consistency of the KNC proxy framework.

[0058] In response, this embodiment further proposes that the seqno sequence number mechanism also includes: using signed difference arithmetic knc_seqno_after to process 64-bit sequence number wrapping, so as to correctly determine the order of requests even after sequence number overflow; and detecting duplicate responses, kernel missed reception, and peer frame loss anomalies by comparing the size of seqno.

[0059] In the KNC proxy framework, the 64-bit auto-incrementing sequence number `seqno` is used to uniquely identify each cryptographic request and its corresponding response in the connection domain. Although the 64-bit sequence number space is enormous, in extremely high-concurrency or long-running systems, the possibility of sequence number overflow (i.e., wrapping around from the maximum to the minimum value) still exists. Traditional unsigned integer comparisons become invalid after sequence number wrapping; for example, a smaller, wrapped sequence number may actually be "newer" than a larger, unwrapped sequence number. Therefore, this embodiment introduces signed difference arithmetic `knc_seqno_after`. This arithmetic operation determines the relative order of two 64-bit sequence numbers by calculating their signed difference. Specifically, when comparing two sequence numbers A and B, if the signed result of (A - B) is positive, then A is considered to be after B; if it is negative, then A is considered to be before B. This method can correctly handle sequence number wrapping within a "window," meaning that as long as the actual distance between the two sequence numbers does not exceed half of the 64-bit sequence number space, even if wrapping occurs, their order can be accurately determined. For example, a macro or function knc_seqno_after(seq1, seq2) can be defined, whose internal logic is ((int64_t)(seq1 - seq2)>0), so that the order of requests can still be reliably determined when the sequence number wraps around, ensuring the correct matching of requests and responses.

[0060] In addition to handling sequence number wrapping, the KNC proxy framework also utilizes a seqno comparison mechanism to detect and handle various anomalies in network transmission, enhancing system reliability. When the KNC proxy framework receives a response from a remote cryptographic device, it extracts the seqno. If the seqno of the response is less than or equal to the seqno of the latest request successfully processed by the current TCP connection, it indicates a duplicate response. The system can discard this duplicate response to avoid reprocessing completed requests, thus ensuring idempotency in data processing. If there is a large jump between the received response's seqno and the next seqno the KNC proxy framework expects to receive (i.e., the received seqno is much larger than the expected value), this may indicate that a partial response has been lost in the kernel layer or the KNC proxy framework's receive path (i.e., a kernel miss). In this case, the system can trigger appropriate error handling mechanisms, such as logging, notifying upper-layer applications, or attempting resynchronization, to avoid data inconsistency. If the received response's seqno is not consecutive with the expected next seqno, but the difference is within an acceptable range, this may indicate that the remote cryptographic device has dropped the request or response due to an error. By comparing the size of seqno, the KNC proxy framework can identify this discontinuity and handle it according to preset strategies, such as marking it as a failure and triggering a retry.

[0061] Through the above technical solutions, the KNC proxy framework can effectively address the overflow and wraparound issues that may occur with 64-bit auto-incrementing sequence numbers in long-term operation or high-concurrency scenarios. Employing signed difference arithmetic (knc_seqno_after), even if sequence number wraparound occurs, the order of requests can be accurately determined within a large range, ensuring precise matching of requests and responses and avoiding logical errors caused by sequence number overflow. Simultaneously, by comparing the magnitudes of seqno, the KNC proxy framework can detect and identify anomalies in network transmission in real time, such as duplicate responses, kernel omissions, and frame drops at the peer end. This mechanism enables the system to take timely corrective measures, such as discarding duplicate data, triggering error handling, or retrying, greatly improving the stability and reliability of the KNC proxy framework in complex network environments and ensuring the correctness of cryptographic request processing and data consistency.

[0062] To address this, this embodiment further proposes a global retry queue processing flow to solve the problem that in the Linux kernel cryptography subsystem algorithm proxy method, although a framework-level global retry queue is introduced to handle retryable failed requests, if the root cause of failure is not effectively identified and avoided, such as the failure of remote cryptographic devices or abnormal network connections, simple request retransmission may lead to continuous request failures, or even increase the system burden, making it impossible to ensure the reliable completion of cryptographic computation tasks.

[0063] The processing flow of the global retry queue described in this embodiment specifically includes: the retry_worker thread retrieves retry requests in batches; after clearing the error code, it resubmits the submit_areq; when resubmitting, it re-executes the routing schedule and switches to a healthy connection to bypass the faulty node; after reaching the maximum number of attempts max_attempts, it terminates the retry and completes the callback.

[0064] The `retry_worker` thread is a dedicated worker thread responsible for handling requests in the retry queue. This thread retrieves requests from the retry queue in batches, rather than processing them one by one, which helps improve processing efficiency and reduce lock synchronization overhead. The `retry_worker` thread can be woken up periodically or notified when there are new requests in the retry queue. It dequeues a batch of requests from a shared, thread-safe queue (i.e., the global retry queue). Batch processing can be achieved by setting a maximum batch size or processing all available requests within a certain time.

[0065] Before resubmitting a request, the system clears the original error codes. This ensures that the request is treated as a completely new task in the new processing cycle, rather than a request with a historical error state. `submit_areq` is the unified entry point for request submission; resubmitting means the request will re-enter the three-level asynchronous pipeline for processing. Specifically, when the `retry_worker` thread retrieves the request, it accesses the error code field in the request structure and resets it to its initial state (e.g., 0 or a specific "pending" state). Subsequently, the request will re-go through the entire process of serialization, sending, receiving, and completion.

[0066] When a request fails for some reason and needs to be retried, the system re-executes routing scheduling. This allows the system to select a different, healthier connection or remote cryptographic device to handle the request based on the current network and device status, thereby increasing the probability of successful retry. When the routing scheduling module receives a retry request, it dynamically selects an available, high-performance TCP connection or remote device based on preset scheduling policies (such as random, minimum load, specified connection, etc.) and currently known connection or device health status information (e.g., health indicators maintained through heartbeat mechanisms, error rate statistics, etc.). If the previous connection or device was marked as faulty, the scheduler will actively avoid these faulty nodes and route the request to other normally functioning nodes.

[0067] In addition, the system sets a maximum number of attempts, `max_attempts`. This is an important fault tolerance mechanism to prevent infinite retries from exhausting resources or causing the system to enter an infinite loop. Setting a maximum number of attempts ensures that if a request cannot be processed successfully after multiple attempts, the system can give up in a timely manner and notify the upper-layer application, avoiding unnecessary resource consumption. Each request structure can contain a counter that records the number of times it has been retried. Before each retry, the `retry_worker` thread increments this counter and compares it with the preset `max_attempts` value. Once the counter reaches `max_attempts`, even if the request has still not succeeded, the system will stop retrying, mark the request as ultimately failed, and then notify the initiator of the original request through a callback mechanism, informing them that the request has failed.

[0068] Through the global retry queue processing described above, the system can intelligently handle failed cryptographic computation requests. Batch processing by the `retry_worker` thread improves retry efficiency, while clearing error codes and resubmitting `submit_areq` ensures that the request re-enters the processing flow with a fresh state. Crucially, re-executing routing scheduling during resubmissions allows the system to dynamically avoid faulty connections or remote cryptographic devices, directing requests to healthy resources, significantly improving the success rate of cryptographic computation tasks and the overall availability of the system. Furthermore, by setting a maximum number of attempts, resource waste and system freezes caused by infinite retries are effectively avoided, ensuring the system's stability and controllability in the face of persistent failures, thus providing more reliable cryptographic services for upper-layer applications.

[0069] In some of the implementation methods described above, a KNC proxy framework is proposed to be built in kernel mode, and cryptographic computation requests are processed through a three-level asynchronous pipeline. A sequence number mechanism and a retry queue are used to ensure reliable transmission and processing of requests. However, in actual deployment and operation, this framework may face challenges such as insufficient performance optimization, data transmission security considerations, and how to efficiently adapt to various remote cryptographic device deployment scenarios, thereby affecting the overall system efficiency and flexibility.

[0070] In response, this embodiment further proposes that the KNC proxy framework also supports: binding three-level pipeline threads to the same CPU core through the pipeline_bind_cpu module parameters to improve cache locality; integrating the kernel so that the kernel automatically completes transmission encryption, and the framework handles encrypted transmission without being aware of it; and supporting three routing scheduling strategies: random, minimum load, and specified connection, to adapt to different remote cryptographic device deployment scenarios.

[0071] Specifically, to improve cache locality, the KNC proxy framework supports binding three-stage pipeline threads to the same CPU core via the `pipeline_bind_cpu` module parameter. Here, "three-stage pipeline threads" typically refers to the `send_worker` thread, the `recv_worker` thread, and the `cmpl_worker` thread. In a multi-core processor environment, if these threads frequently switch between different CPU cores or run on different cores, the shared data they access (such as request queues, control blocks, etc.) may need to be synchronized between the caches of different cores, leading to cache invalidation and additional performance overhead. By setting CPU affinity, these closely cooperating threads are forced to run on the same CPU core, ensuring they share the same core's cache, reducing cache synchronization overhead, and thus improving data access efficiency and pipeline processing speed.

[0072] Meanwhile, to ensure the security of password computation requests during network transmission, the KNC proxy framework integrates with the kernel, which automatically handles transmission encryption, leaving the framework unaware of the encryption. This means that the KNC proxy framework runs as a kernel module and can utilize existing secure transmission mechanisms provided by the Linux kernel, such as the IPsec protocol stack or kernel TLS (kTLS). When the KNC proxy framework sends data through interfaces such as TCPsendmsg, if the underlying TCP connection is configured with the corresponding IPsec policy or kTLS, the data will be automatically encrypted by the kernel before leaving the local network interface and automatically decrypted upon receipt. The KNC proxy framework itself does not need to explicitly perform encryption or decryption operations; it only needs to submit the data to the network stack, thereby simplifying the implementation complexity of the framework and ensuring the confidentiality and integrity of transmitted data.

[0073] Furthermore, to adapt to different remote cryptographic device deployment scenarios, the KNC proxy framework supports three routing scheduling strategies: random, minimum load, and specified connection. The routing scheduling strategy refers to the rules by which the KNC proxy framework selects the target device or connection when forwarding cryptographic computation requests to a remote cryptographic device.

[0074] 1. Random Strategy: When a new cryptographic computation request is received, the KNC proxy framework randomly selects one from all currently available remote cryptographic device connections for forwarding. This strategy is suitable for scenarios where load balancing accuracy requirements are not high, but simple request distribution is needed to avoid single-point overload.

[0075] 2. Minimum Load Strategy: The KNC proxy framework monitors and maintains real-time load information for each remote cryptographic device connection, such as the number of pending requests and average response time. When forwarding requests, the framework selects the connection with the lowest current load. This strategy achieves more effective load balancing and optimizes the resource utilization of remote devices.

[0076] 3. Specify connection policy: Allows administrators or upper-layer applications to specify connection policies based on specific business needs, such as supporting Init-Update. -The stateful service for the Final operation forces a cryptographic computation request to be forwarded through a pre-defined connection to a specific remote cryptographic device or the connection corresponding to the previous request. This can be achieved by adding specific metadata to the request or through configuration rules, and is suitable for scenarios that need to route specific types of cryptographic operations to hardware accelerators or secure zones with specific functions, security levels, or geographical locations.

[0077] By binding the three-stage pipeline threads to the same CPU core through the above technical solutions, cache locality is significantly improved, and data synchronization overhead between processor cores is reduced, thereby optimizing the overall performance of pipelined processing. Simultaneously, leveraging the kernel's automatic transmission encryption capability ensures data security for cryptographic computation requests and responses during network transmission, while the KNC proxy framework itself does not need to intervene in encryption details, reducing implementation complexity. Furthermore, by providing three routing and scheduling strategies—random, minimum load, and specified connection—the KNC proxy framework can flexibly adapt to different deployment environments and business needs of remote cryptographic devices, achieving intelligent load balancing and resource allocation for remote cryptographic devices, effectively improving the overall efficiency, security, and manageability of the system.

[0078] This embodiment achieves algorithm-independent abstraction by building a KNC proxy framework in kernel mode, and completes accurate matching and transparent forwarding of requests by combining a three-level asynchronous pipeline and a seqno sequence number mechanism. It effectively solves the technical bottleneck of existing technologies that cannot seamlessly proxy kernel cryptographic requests to remote devices. It has the advantage of being able to transparently proxy kernel cryptographic requests to remote cryptographic devices for execution, while keeping the upper-layer caller unaware of the request.

[0079] Furthermore, embodiments of this application also propose a computer-readable storage medium storing a program for a Linux kernel cryptographic subsystem algorithm proxy, wherein when the program for the Linux kernel cryptographic subsystem algorithm proxy is executed by a processor, it implements the steps of the Linux kernel cryptographic subsystem algorithm proxy method described above.

[0080] Reference Figure 3 , Figure 3 This is a structural block diagram of the first embodiment of the Linux kernel cryptography subsystem algorithm proxy system of this application.

[0081] like Figure 3 As shown, the Linux kernel cryptography subsystem algorithm proxy system proposed in this application includes: The framework building module 10 is used to build a KNC proxy framework that seamlessly connects with the Linux kernel crypto subsystem in kernel mode. It defines a unified extended operation table xops for the five types of cryptographic algorithms of the crypto subsystem, namely symmetric encryption, authentication encryption, asynchronous hashing, asymmetric encryption, and key negotiation protocol, to achieve algorithm-independent abstraction. Pipeline construction module 20 is used to construct a three-level asynchronous pipeline of sendq-recvq-cmplq based on the xops. It receives crypto_async_request asynchronous requests through a unified entry point knc_submit_areq, and completes request serialization and sending, response reception and deserialization, request completion or retry decision through the pipeline. The request writing module 30 is used to maintain a 64-bit auto-incrementing sequence number seqno for each TCP connection, write the seqno into the request and transmit it with the network frame, and achieve precise correspondence between the request and the response by matching the seqno. The global retry module 40 is used to build a framework-level global retry queue, perform asynchronous retry and rerouting of retryable failed requests, and transparently forward cryptographic calculation requests to remote cryptographic devices for execution.

[0082] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solution of this application. In specific applications, those skilled in the art can make settings as needed, and this application does not impose any restrictions on this.

[0083] This embodiment achieves algorithm-independent abstraction by building a KNC proxy framework in kernel mode, and completes accurate matching and transparent forwarding of requests by combining a three-level asynchronous pipeline and a seqno sequence number mechanism. It effectively solves the technical bottleneck of existing technologies that cannot seamlessly proxy kernel cryptographic requests to remote devices. It has the advantage of being able to transparently proxy kernel cryptographic requests to remote cryptographic devices for execution, while keeping the upper-layer caller unaware of the request.

[0084] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this application. In practical applications, those skilled in the art can select some or all of it to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0085] In addition, for technical details not described in detail in this embodiment, please refer to the method of Linux kernel cryptography subsystem algorithm proxy provided in any embodiment of this application, which will not be repeated here.

[0086] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system 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 system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0087] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0088] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application. The above are only preferred embodiments of this application and do not limit the patent scope of this application. All equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A proxy method for Linux kernel cryptographic subsystem algorithms, characterized in that, include: A KNC proxy framework is built in kernel mode to seamlessly interface with the Linux kernel crypto subsystem. For the five types of cryptographic algorithms of the crypto subsystem, namely symmetric encryption, authentication encryption, asynchronous hashing, asymmetric encryption, and key negotiation protocol, a unified extended operation table xops is defined to achieve algorithm-independent abstraction. Based on the xops, a three-level asynchronous pipeline of sendq-recvq-cmplq is constructed. The unified entry point knc_submit_areq receives crypto_async_request asynchronous requests. The pipeline completes request serialization and sending, response reception and deserialization, and request completion or retry decision-making. Maintain a 64-bit auto-incrementing sequence number seqno for each TCP connection, write the seqno into the request and transmit it with the network frame, and achieve precise correspondence between request and response by matching seqno; A framework-level global retry queue is established to asynchronously retry and reroute failed requests, and to transparently forward cryptographic computation requests to remote cryptographic devices for execution.

2. The method according to claim 1, characterized in that, The extended operation table xops contains nine function pointers: set_seqno, get_seqno, set_erc, get_erc, pack, recv, route, complete_or_retry, and is_retrying. The xops pointer is extracted from crypto_async_request using the container_of macro, thus decoupling the framework code from specific algorithm types.

3. The method according to claim 1, characterized in that, The three-stage asynchronous pipeline is configured with three groups of worker threads: send_worker, recv_worker, and cmpl_worker. The send_worker thread dequeues requests in batches from the send queue sendq, serializes them in batches via the send control block SCB, and then sends them in a single TCP sendmsg. After sending, the requests are moved into the receive queue recvq. The recv_worker thread dequeues requests in batches from recvq, parses and deserializes response frames based on seqno and last_seen / last_partial state machines, and then moves the requests into the completion queue cmplq. The cmpl_worker thread dequeues requests in batches from cmplq, reads the error code ERC, and makes a decision through complete_or_retry. If there is no error, it directly completes the callback; if it can be retried, it moves the request to the global retry queue.

4. The method according to claim 3, characterized in that, The send_worker thread performs backpressure control: before packaging, it waits for available space in recvq to avoid sending speed exceeding receiving processing capacity; at the same time, it processes sendq backlog requests, calls back -EINPROGRESS for the first squeezed backlog request, and skips the callback for backlog requests in retry.

5. The method according to claim 1, characterized in that, The seqno sequence number mechanism also includes: using signed difference arithmetic knc_seqno_after to process 64-bit sequence number wrapping, so as to correctly determine the order of requests even after the sequence number overflows; and using seqno size comparison to detect duplicate responses, kernel missed reception, and abnormal frame loss at the peer end.

6. The method according to claim 1, characterized in that, The processing flow of the global retry queue is as follows: the retry_worker thread retrieves retry requests in batches, clears error codes, and resubmits them using submit_areq; during resubmission, route scheduling is re-executed, switching to a healthy connection to bypass the faulty node; after reaching the maximum number of attempts max_attempts, the retry is terminated and a callback is executed.

7. The method according to claim 1, characterized in that, The KNC proxy framework also supports: binding three-level pipeline threads to the same CPU core through the pipeline_bind_cpu module parameter to improve cache locality; integrating the kernel so that the kernel automatically completes transmission encryption, and the framework handles encrypted transmission without being aware of it; and supporting three routing scheduling strategies: random, minimum load, and specified connection, to adapt to different remote cryptographic device deployment scenarios.

8. A Linux kernel cryptographic subsystem algorithm proxy system, characterized in that, include: The framework building module is used to build a KNC proxy framework that seamlessly integrates with the Linux kernel crypto subsystem in kernel mode. It defines a unified extended operation table xops for the five types of cryptographic algorithms of the crypto subsystem, namely symmetric encryption, authentication encryption, asynchronous hashing, asymmetric encryption, and key negotiation protocol, to achieve algorithm-independent abstraction. The pipeline construction module is used to build a three-level asynchronous pipeline of sendq-recvq-cmplq based on the xops. It receives crypto_async_request asynchronous requests through a unified entry point knc_submit_areq, and completes request serialization and sending, response reception and deserialization, and request completion or retry decision through the pipeline. The request writing module is used to maintain a 64-bit auto-incrementing sequence number seqno for each TCP connection, write the seqno into the request and transmit it with the network frame, and achieve precise correspondence between request and response by matching seqno. The global retry module is used to build a framework-level global retry queue, perform asynchronous retry and rerouting of retryable failed requests, and transparently forward cryptographic calculation requests to remote cryptographic devices for execution.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the processor, when executing computer instructions stored in the memory, performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images