Request processing method and system

Abstract

The embodiment of the present specification provides a request processing method and system, wherein the request processing method is applied to a request monitoring program, and the method comprises the following steps: intercepting an application management request sent to a target driver; in the case that it is determined that the application management request meets the request execution condition of the request monitoring program, but does not meet the request execution condition of the target driver, changing the application management request according to the request execution condition of the target driver; and sending the changed application management request to the target driver for execution, so as to control the management of the more precise calling, deployment, running and the like of the application program.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a request processing method. Background Technology

[0002] With the continuous development of computer technology, in order to ensure the security of applications and avoid network attacks, application development organizations will deploy applications to trusted execution environments and manage and control the calling, deployment, and running of applications in the trusted execution environment through application startup control modules.

[0003] However, the existing startup control module cannot provide fine-grained management and control over applications. For example, it allows authorized application development organizations to develop each application and perform operations such as invocation, deployment, and execution within the trusted execution environment, but it cannot specifically restrict any particular application. Therefore, a method that enables more granular management and control of applications is proposed. Summary of the Invention

[0004] In view of the above, embodiments of this specification provide a request processing method. One or more embodiments of this specification also relate to a request processing apparatus, a request processing system, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a request processing method is provided, applied to a request monitoring program, the method comprising:

[0006] Intercept application management requests sent to the target driver;

[0007] If it is determined that the application management request meets the request execution conditions of the request monitoring program, but does not meet the request execution conditions of the target driver, the application management request is modified according to the request execution conditions of the target driver.

[0008] The modified application management request is sent to the target driver for execution.

[0009] According to a second aspect of the embodiments of this specification, a request processing apparatus is provided, applied to a request monitoring program, comprising:

[0010] The interception module is configured to intercept application management requests sent to the target driver;

[0011] The modification module is configured to modify the application management request according to the request execution conditions of the target driver when it is determined that the application management request meets the request execution conditions of the request monitoring program but does not meet the request execution conditions of the target driver.

[0012] The sending module is configured to send the modified application management request to the target driver for execution.

[0013] According to a third aspect of the embodiments of this specification, a request processing system is provided, including a request monitoring program and a target driver, wherein...

[0014] The request monitoring program is configured to intercept application management requests sent to the target driver. If it is determined that the application management request meets the request execution conditions of the request monitoring program but does not meet the request execution conditions of the target driver, the program modifies the application management request according to the request execution conditions of the target driver and sends the modified application management request to the target driver.

[0015] The target driver is configured to execute received application management requests.

[0016] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising:

[0017] Memory and processor;

[0018] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the above-described request processing method.

[0019] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the above-described request processing method.

[0020] According to a sixth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described request processing method.

[0021] This specification provides a request processing method according to an embodiment, applied to a request monitoring program. The method includes: intercepting an application management request sent to a target driver; if it is determined that the application management request meets the request execution conditions of the request monitoring program but does not meet the request execution conditions of the target driver, modifying the application management request according to the request execution conditions of the target driver; and sending the modified application management request to the target driver for execution.

[0022] Specifically, this method uses a request monitoring program to intercept application management requests that need to be sent to the target driver. If the application management request does not meet the target driver's request execution conditions, it makes a more granular judgment based on the request monitoring program's request execution conditions. If the application management request meets the request monitoring program's request execution conditions, it is changed to an application management request that meets the target driver's request execution conditions and sent to the target driver for execution. This allows for more granular management and control over the application's invocation, deployment, and operation. Attached Figure Description

[0023] Figure 1 This is a schematic diagram illustrating the application of a request processing method provided in one embodiment of this specification;

[0024] Figure 2 This is a flowchart illustrating a request processing method provided in one embodiment of this specification;

[0025] Figure 3 This is a flowchart illustrating the processing procedure of a request processing method provided in one embodiment of this specification.

[0026] Figure 4 This is a schematic diagram of the startup process of an Enclave provided in one embodiment of this specification;

[0027] Figure 5 This is a schematic diagram of the structure of a request processing system provided in one embodiment of this specification;

[0028] Figure 6 This is a schematic diagram of the structure of a request processing device provided in one embodiment of this specification;

[0029] Figure 7 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0030] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0031] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0032] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0033] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0034] TEE stands for Trusted Execution Environment.

[0035] SGX: Short for Software Guard Extension, it is a TEE technology.

[0036] Launch Control: Startup control.

[0037] SGX Enclave: The TEE software carrier used in SGX technology.

[0038] MR Signer: A metric identifying the developer of the SGX Enclave.

[0039] MR Enclave: A metric for the SGX Enclave;

[0040] FLC stands for Flexible Launch Control, which is a flexible launch control function of the SGX Enclave.

[0041] eBPF: short for Extended Berkeley Packet Filter, is a mechanism by which applications execute code in kernel space.

[0042] Ioctl (input / output control) is a system call specifically used for device input / output operations.

[0043] API hooking is a technique used to change the result of API execution.

[0044] EPC: short for Enclave page cache, is a CPU-managed memory used to store data related to enclave programs.

[0045] API: Short for Application Programming Interface, it is a set of predefined functions designed to provide applications and developers with the ability to access a set of routines based on certain software or hardware.

[0046] In cloud computing environments, confidential computing hardware is rapidly becoming more widespread, but cybersecurity threats are also increasing. Attackers may exploit the confidentiality provided by confidential computing enclaves to launch attacks and evade malware scans (including malicious enclaves). Therefore, allowing only specific whitelisted or blacklisted enclaves to run can mitigate security risks. Based on this, an SGX technology employs a startup control mechanism based on enclave signature checks, meaning only authorized software vendors can develop, deploy, and run enclave applications. While this mechanism enhances security, it also places an additional burden on users' IT system operations and maintenance. Specifically, it raises four issues: 1. This startup control mechanism causes significant inconvenience and potential compliance problems for users. Users can only choose to disable this startup control function using FLC, but the practical result is that user-developed SGX enclave applications lack the enclave's startup control functionality. 1. SGX, as a security technology, should not cause such inconvenience to users; 2. The startup control mechanism only provides identification and verification of the application developer's identity. Even if the user obtains startup authorization, they cannot use the startup control mechanism to set precise startup control policies for different Enclaves; 3. The CPU, memory, and EPC security memory resources of the cloud server are all related to the user's usage costs. Users do not want arbitrary Enclave applications to run at will without the constraints of a startup control mechanism, consuming the customer's paid resources; 4. Malware may use SGX Enclave technology to launch attacks and evade detection. Therefore, the lack of Enclave startup control poses certain security risks.

[0047] To address the aforementioned issues, an FLC (Flying Leak Control) function was added to the SGX technology to allow users to disable the boot control mechanism. However, this boot control mechanism only checks the application developer's signature, meaning the control policy remains at the organizational level and doesn't apply precisely to specific Enclaves. Specifically, this solution provides Enclave boot control functionality in the system's driver module. It provides a maximum of 256MB of EPC secure memory per CPU and enforces SGX Enclave Launch Control, meaning application developers using Intel Enclave technology must obtain boot authorization to run their developed Enclave applications. However, this solution differs from SGX without FLC in two main ways: 1. It supports larger EPC secure memory (up to 1TB), enabling operation on cloud servers; 2. It provides FLC functionality, allowing software developers to launch their self-developed Enclave applications without a boot control license. Essentially, it allows users to disable SGX boot control; for example, with FLC enabled, the Enclave can launch freely (while without FLC, it cannot), posing a risk of information leakage. At the same time, this startup control policy is only precise at the Enclave Developer Signer (MR Signer) level, and cannot be precise at the level of each Enclave Signer (MR Enclave), so the control granularity is relatively coarse. Even if the user enables the startup control function and obtains startup authorization, it is still impossible to precisely control the startup permissions of each specific Enclave. Based on this, the main drawbacks of this scheme are as follows: 1. Users must accept an authorization process to use the Enclave boot control function, and this authorization is based on a key. If the user's key needs to be updated, it heavily relies on the authorization update process; 2. For security reasons, the boot control policy (application developer signature check) needs to be embedded in the signed kernel driver module and cannot be dynamically added or modified at runtime; 3. The control policy is geared towards application developer identity recognition (electronic signature check), and cannot more accurately identify different Enclaves. The granularity of boot control can only be the control of the application developer's identity, and cannot be fine-grained down to different Enclaves; 4. If users do not accept the authorization process, they can disable the boot control function through FLC, but this introduces security risks; 5. If users develop their own kernel driver module to add customized boot control functions, they cannot use the kernel driver module corresponding to the boot control policy, and the related security updates of the driver module cannot be directly upgraded; 6. Due to the mechanism limitations of the system kernel module, the user's customized kernel driver module needs to be developed and compiled according to the kernel version of the target system platform, making it difficult to achieve cross-platform portability of "compile once, run anywhere";

[0048] Therefore, how to perform precise startup control down to the specific Enclave according to user needs and ensure security, while preventing the normal use of the startup control mechanism, becomes a problem that needs to be solved.

[0049] This specification provides a request processing method, and also relates to a request processing apparatus, a request processing system, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0050] See Figure 1 , Figure 1 This diagram illustrates an application illustration of a request processing method according to an embodiment of this specification, wherein, see [link to illustration]. Figure 1 It is known that when the user application sends an application call request to the driver module, the system kernel module will intercept the application call request. This interception can be implemented based on AIP hooks technology. The system kernel module then judges the application call request. If it determines that the application call request meets its own configured startup control policy but does not meet the execution conditions of the driver module, the system kernel module will modify the application call request to meet the execution conditions based on the driver module's execution conditions and return it to the driver module for execution. The driver module can be the SGX driver module in the system kernel, which is a program. The system kernel module can be understood as a program containing binary code that implements the startup control policy. Based on this, the request processing method provided in this specification controls the loading behavior of the SGX driver module onto the SGX Enclave at the system kernel level, enabling a user-defined enclave startup control mechanism. This allows for precise control over different enclaves from the same software vendor, while avoiding the additional work required for users to modify and develop the native SGX software stack (including kernel drivers, SDKs, etc.). This achieves a frictionless, user-controlled SGX Enclave startup control mechanism. This method is highly effective in enhancing the security of cloud servers with SGX functionality.

[0051] See Figure 2 , Figure 2 A flowchart of a request processing method according to an embodiment of this specification is shown. The method is applied to a request monitoring program and specifically includes the following steps.

[0052] Step 202: Intercept the application management request sent to the target driver.

[0053] The request monitoring program can be understood as a program capable of monitoring, intercepting, and processing application management requests sent to the target driver. For example, the request monitoring program can be a system kernel module. It should be noted that the request processing method provided in this specification can employ any technology to intercept the application management requests; for example, it can use API hooks technology.

[0054] In this context, the application management request can be understood as a processing request from an application capable of controlling the startup of the target driver. For example, the application management request could be an application deployment request, an application invocation request, etc. This specification does not impose specific limitations on it.

[0055] This target driver can be understood as a program that controls the startup of an application to ensure its security. For example, this target driver could be an SGX driver module. Through this target driver, operations such as application invocation, deployment, and execution can be controlled.

[0056] Based on this, the request processing method provided in this specification, in order to achieve the purpose of controlling the startup of the application according to the startup control policy specified by the user, will intercept the application management requests sent to the target driver through the request monitoring program.

[0057] For example, the request processing method provided in this specification allows the system kernel module to intercept commands such as application creation, application modification, and application initialization sent to the user program by calling the interface corresponding to the SGX driver module, as well as the interface of the SGX driver module calling SGX instructions, thereby obtaining the application creation, application modification, application initialization commands and SGX instruction calls.

[0058] Step 204: If it is determined that the application management request meets the request execution conditions of the request monitoring program, but does not meet the request execution conditions of the target driver, the application management request is modified according to the request execution conditions of the target driver.

[0059] The request execution conditions of the monitoring program can be understood as the startup control policies defined by the user according to their own needs, such as whitelists and blacklists. The request execution conditions of the target driver can be understood as the startup control rules that the target driver itself uses to determine whether to execute the application management request; for example, the aforementioned control policies based on developer signatures.

[0060] Specifically, the request processing method provided in this specification, after intercepting the application management request, determines whether the application management request meets its own request execution conditions and whether it meets the target driver's request execution conditions. If the application management request meets the request execution conditions of the request monitoring program but not the target driver's request execution conditions, in order to achieve precise control over the startup of different Enclaves from the same software vendor based on a user-defined startup control strategy, while avoiding the additional work required by the user to modify and develop the SGX native software stack, and thus achieving the goal of a user-controlled startup control mechanism, the application management request will be modified according to the target driver's request execution conditions to obtain an application management request that meets the target driver's request execution conditions. This allows for application startup control according to the user's needs.

[0061] In one embodiment provided in this specification, since the startup control mechanism of the SGX driver module is based on the developer signature of an authorized developer, in order to bypass the SGX driver and launch an unauthorized application when needed by the user, the developer signature in the application call request sent by the user application to the SGX driver can be changed to the signature of an authorized developer, thereby enabling the launch of the unauthorized application. Specifically, modifying the application management request according to the request execution conditions of the target driver includes:

[0062] Determine the request verification information carried in the application management request, and determine the program verification information that satisfies the request execution conditions of the target driver;

[0063] Based on the program verification information, the request verification information carried in the application management request is replaced.

[0064] The request verification information can be understood as information used by the target driver to determine whether to execute the application management request. For example, the request verification information can be the developer's signature or developer identifier.

[0065] The program verification information can be understood as signature or identification information stored locally by the target driver for managing the application. For example, the program verification information could be an authorized developer's signature, or a developer identifier obtained through the authorization process.

[0066] Following the previous example, if it is determined that the application's call request satisfies the user's startup control policy configured in the system kernel module, but does not satisfy the startup control policy of the SGX driver module, then the developer signature that satisfies the startup control policy of the SGX driver module will be determined. This developer signature is authorized by the SGX driver module.

[0067] The system replaces the unauthorized developer signature carried in the application call request with the authorized developer signature, thereby satisfying the application call request of the SGX driver module's startup control strategy.

[0068] Step 206: Send the modified application management request to the target driver for execution.

[0069] Specifically, after receiving an application management request that meets the execution conditions of the target driver, the driver sends the application management request to the target driver for execution. Upon receiving the application management request, the target driver manages the applications it manages based on the request. For example, it performs operations such as running, deploying, and loading the applications.

[0070] The request processing method provided in this specification intercepts application management requests that need to be sent to the target driver through a request monitoring program. If it is determined that the application management request does not meet the request execution conditions of the target driver, it makes a more granular judgment based on the request execution conditions of the request monitoring program. If the application management request meets the request execution conditions of the request monitoring program, it is changed into an application management request that meets the request execution conditions of the target driver and sent to the target driver for execution. This allows for more granular management and control over the invocation, deployment, and operation of the application.

[0071] In one embodiment provided in this specification, after intercepting the application management request sent to the target driver, the method further includes:

[0072] If it is determined that the application management request does not meet the request execution conditions of the request monitoring program, the application management request is discarded.

[0073] In practical applications, considering that some of the developer's applications have vulnerabilities while others function normally, the request processing method provided in this specification can discard an application management request if it is determined that the request targets a vulnerable application, thus avoiding security issues caused by running the vulnerable application. Similarly, if it is determined that the application management request does not meet the request execution conditions of the request monitoring program, the application management request will be discarded.

[0074] In one embodiment provided in this specification, after intercepting the application management request sent to the target driver, the method further includes:

[0075] If it is determined that the application management request meets the request execution conditions of the request monitoring program and the request execution conditions of the target driver, the application management request is sent to the target driver for execution.

[0076] In practical applications, when an application management request meets both the request execution conditions of the request monitoring program and the request execution conditions of the target driver, in order to ensure the smooth execution of the application management request, the intercepted application management request will be forwarded to the target driver for execution.

[0077] In one embodiment provided in this specification, determining that the application management request meets the request execution conditions of the request monitoring program includes:

[0078] Determine the application identifier carried in the application management request, and determine the application identifier to be executed corresponding to the request execution conditions of the request monitoring program;

[0079] If the application identifier matches the application identifier to be executed, the application management request is determined to meet the request execution conditions of the request monitoring program.

[0080] The application identifier can be understood as information that identifies an application, such as the application name or application ID. In practical applications, this application identifier can be the identifier of the enclave that runs the application.

[0081] The application identifier to be executed can be understood as a user-defined identifier for an application that is allowed to perform operations such as running and calling. This application identifier can be stored as a whitelist. The whitelist contains identifiers of applications that are allowed to perform operations such as running and calling.

[0082] Following the example above, the request processing method provided in this manual, after intercepting an application call request, will determine the Enclave identifier carried in the request and match the Enclave identifier with the Enclave identifier in its own configured whitelist. If the match is successful, that is, if the Enclave identifier carried in the request exists in the whitelist, it is determined that the application call request meets the startup control policy.

[0083] Furthermore, in one embodiment provided in this specification, determining that the application management request does not meet the request execution conditions of the request monitoring program includes:

[0084] If it is determined that the application identifier does not match the application identifier to be executed, it is determined that the application management request does not meet the request execution conditions of the request monitoring program.

[0085] Following the example above, the request processing method provided in this manual, after intercepting an application call request, will determine the Enclave identifier carried in the request and match it with the Enclave identifier in its own configured whitelist. If the match fails, that is, if the Enclave identifier carried in the request does not exist in the whitelist, it is determined that the application call request does not meet the startup control policy and cannot perform operations such as running or deploying the application.

[0086] In the embodiments provided in this specification, the startup control mechanism of the SGX driver module is implemented based on the developer's signature of an authorized developer. Therefore, determining that the application management request does not meet the execution conditions of the target driver includes:

[0087] Determine the request verification information carried in the application management request, and determine the program verification information of the request execution conditions of the target driver;

[0088] If it is determined that the request verification information does not match the program verification information, it is determined that the application management request does not meet the request execution conditions of the target driver.

[0089] The verification information in this request can be understood as the developer signature carried in the application management request, while the program verification information can be understood as the developer signature configured by the target driver itself and authorized for startup. This developer signature can be stored in a whitelist format.

[0090] Following the example above, the request processing method provided in this manual, after intercepting an application call request, will determine the developer signature carried in the request and match the developer signature with the developer signature configured for SGX operation authorization. If the match fails, that is, if the developer signature carried in the request is not found in the developer signatures authorized for SGX operation, it will be determined that the application call request does not meet the SGX startup control policy.

[0091] In one embodiment provided in this specification, the application management request satisfies the request execution conditions of the target driver, including:

[0092] If the request verification information matches the program verification information, the application management request is determined to meet the request execution conditions of the target driver.

[0093] Following the example above, the request processing method provided in this manual matches the developer signature with the developer signature configured by itself and authorized by SGX. If the match is successful, that is, if the developer signature carried in the request exists in the developer signature authorized by SGX, it is determined that the application call request meets the SGX startup control policy.

[0094] The request processing method provided in this specification can not only intercept application management requests sent to the target driver, but also intercept requests sent by the target driver to the CPU and determine whether the request meets the application loading conditions, thereby enabling more precise control over application loading and other operations. Specifically, the request processing method also includes:

[0095] Intercept the application loading request sent to the CPU by the target driver;

[0096] If it is determined that the application loading request does not meet the application loading conditions of the request monitoring program, the application loading request is discarded; or, if it is determined that the application loading request meets the application loading conditions of the request monitoring program, the application loading request is sent to the CPU.

[0097] In this context, the application loading request can be understood as a request that instructs the CPU to load a specific application from memory.

[0098] Specifically, the request processing method provided in this specification can also intercept application loading requests sent by the target driver to the CPU and determine whether the intercepted application loading request meets the application loading policy specified by the user; if it is determined that the application loading request does not meet the application loading conditions of the request monitoring program, the application loading request is discarded, and loading of specific applications, such as target applications with vulnerabilities, is prohibited; if it is determined that the application loading request meets the application loading conditions of the request monitoring program, the application loading request is sent to the CPU, thereby instructing the CPU to retrieve the binary code of the specific application from memory and run it.

[0099] Furthermore, in one embodiment provided in this specification, determining that the application loading request does not meet the application loading conditions of the request monitoring program includes:

[0100] Determine the application identifier carried in the application loading request, and determine the application loading identifier corresponding to the application loading condition;

[0101] If the application identifier does not match the application loading identifier, it is determined that the application loading request does not meet the application loading conditions of the request monitoring program.

[0102] The application loading identifier can be understood as the identifier of the application specified by the user and loaded by the CPU.

[0103] Specifically, the request processing method provided in this specification, after intercepting the application loading request sent by the target driver to the CPU, will determine the application identifier carried in the application loading request and match the application identifier with the user-specified, allowed application identifier. If the match is successful, that is, if the user-allowed application identifier contains the application identifier carried in the intercepted application loading request, then the application loading request is determined to meet the startup control policy.

[0104] Furthermore, in the embodiments provided in this specification, determining that the application loading request satisfies the application loading conditions of the request monitoring program includes:

[0105] If the application identifier matches the application loading identifier, it is determined that the application loading request meets the application loading conditions of the request monitoring program.

[0106] Specifically, the request processing method provided in this specification, after intercepting the application loading request sent by the target driver to the CPU, will determine the application identifier carried in the application loading request and match the application identifier with the user-specified, allowed application identifiers. If the match is unsuccessful, that is, if the application identifier carried in the intercepted application loading request is not among the identifiers of the user-allowed applications, it will be determined that the application loading request does not meet the startup control policy.

[0107] In the embodiments provided in this specification, the request processing method, considering the need for portability across different system platforms, leverages the excellent cross-platform and portability of eBPF technology. The eBPF-based Enclave startup control program can achieve a "compile once, run anywhere" cross-platform portability solution. Specifically, the request processing method provided in this specification offers an Enclave startup control program, which consists of two parts: an eBPF application and an eBPF kernel module. The eBPF kernel module can be understood as a request monitoring program. The eBPF application runs in user space; it is responsible for managing the configuration of the Enclave startup control policy, monitoring data, and logs, and for distributing the configuration to the eBPF kernel module. The eBPF kernel module is provided by the system kernel, and the eBPF application distributes the eBPF binary program that executes the control policy to the eBPF kernel module for execution. Through the cooperation of the user space module (eBPF application) and the kernel module of the eBPF control program, the Enclave control policy (signature checking, blacklisting, whitelisting) is implemented, thus achieving cross-platform portability of the startup control program. Specifically, before intercepting the application management request sent to the target driver, the process also includes:

[0108] The code configuration program receives request processing code sent by the client and forwards it.

[0109] By running the request processing code, the steps for request management in the request processing method are executed.

[0110] The request handling code can be understood as the binary code data of the application that executes the startup control mechanism. The code configuration program can be understood as a program capable of configuring, managing, and distributing the request handling code, such as the eBPF application mentioned above. The code configuration program runs in the system's user space, while the request monitoring program runs in the system's kernel space.

[0111] Continuing with the previous example, the eBPF application can receive eBPF binary program code input by the user from the client and send the eBPF binary program code that executes the control policy (the code that implements the Enclave boot control policy) to the eBPF kernel module for execution. This eBPF kernel module uses the eBPF programming language and interfaces to implement the code that executes the Enclave boot control policy, intercepts requests sent to the SGX driver module, and processes the parameters of the intercepted requests through the eBPF kernel module's boot control policy logic to determine whether they conform to the boot policy.

[0112] The request handling method provided in this specification utilizes eBPF's user-space kernel control technology to achieve non-intrusive and frictionless control over the native SGX driver module. Leveraging eBPF's cross-platform capabilities, it achieves cross-system kernel portability for Enclave boot control. Furthermore, the user's Enclave boot control policy is executed by the eBPF program; unauthorized Enclaves will be identified and blocked during the driver module's Enclave loading phase. The control policy is distributed to the eBPF kernel module by the user-space eBPF management program, allowing for dynamic addition, deletion, modification, and querying at any time without modifying any Intel software components. In addition, this method is compatible with any version of the SGX software stack, achieving compatibility with different SGX driver versions.

[0113] In the embodiments provided in this specification, the request processing code sent by the receiving code configuration program includes:

[0114] Receive a code configuration message sent by the code configuration program, wherein the code configuration message carries first verification information and request processing code;

[0115] Determine the second verification information corresponding to the request monitoring program, and if the first verification information and the second verification information are consistent, obtain the request processing code carried in the code configuration message.

[0116] It should be noted that during the configuration of this request handling code, in order to ensure the consistency and security of the configured code, the received request will be verified, and the binary code will only be executed if the verification passes.

[0117] The verification information can be understood as information used for security verification, such as hash values ​​and keys. Specifically, the first verification information can be understood as verification information held by the code configuration program, such as the private key held by the eBPF application. The second verification information can be understood as verification information held by the request monitoring program, such as the public key built into the eBPF kernel module.

[0118] Following the previous example, the public key certificate is built into the eBPF kernel module. After the eBPF application sends the configuration policy and private key to the kernel module, the kernel module verifies the information using the private key signature and the public key to ensure the consistency of the binary configuration policy code.

[0119] It should be noted that, in one embodiment provided in this specification, the eBPF application can dynamically issue and change the existing configuration strategy in the eBPF kernel. Specifically, it obtains the update code sent by the code configuration program, updates the request processing code based on the update code, and executes the request management steps in the request processing method by running the updated request processing code.

[0120] Furthermore, the eBPF application can dynamically distribute updated binary policy code. After receiving the updated binary policy code, the eBPF kernel module will update its own deployed boot control program code to obtain the updated boot control program.

[0121] The following is in conjunction with the appendix Figure 3 Taking the application of the request processing method provided in this specification in a scenario where precise Enclave startup control is implemented based on eBPF technology as an example, the request processing method will be further explained. Figure 3 This specification shows a flowchart of a request processing method according to an embodiment of the present specification. See also: Figure 3 As can be seen, this solution leverages eBPF's extensive and precise monitoring capabilities (API hooks technology) of system call interfaces and kernel modules to achieve precise control over Enclave startup. The specific solution is as follows: The request processing method described in this specification provides an Enclave startup control program, which consists of two parts: an eBPF application and an eBPF kernel module. The eBPF application runs in user space, while the eBPF kernel module is provided by the system kernel. The eBPF application is... Figure 3 The startup control program, this eBPF kernel module is Figure 3 The system kernel module.

[0122] This eBPF application is responsible for managing the configuration, monitoring data, and logs of the Enclave boot control policy, and for distributing the boot control policy configuration (i.e., the code of the Enclave boot control policy, which is the code of the eBPF binary program that executes the control policy) to the eBPF kernel module.

[0123] This eBPF kernel module utilizes the eBPF programming language and interfaces to implement code that executes the Enclave boot control policy. The executed code intercepts Ioctl commands (loading, initializing, running, stopping), as well as the interface for the SGX driver module to call SGX instructions. It obtains requests that need to be sent to the SGX driver module and processes the parameters carried in these requests (such as the Enclave identifier or developer signature) within the eBPF boot control policy logic to determine whether the boot policy is met. The SGX driver module is... Figure 3 The driver in the program.

[0124] Specifically, identifying whether a request conforms to the startup policy can be achieved by obtaining the Enclave identifier carried in the request and determining whether this Enclave identifier is a user-defined identifier for an Enclave capable of executing the startup process. If so, the request is deemed to conform to the startup policy. If not, the request is discarded, thereby enabling the eBPF startup control policy logic code to prevent unexpected startup behavior in the Hook function, and the startup process of the Enclave will terminate in failure.

[0125] The same applies to the Enclave startup process with SGX startup control enabled (i.e., FLC function disabled). That is, for different Enclaves from the same licensed application developer, different startup control policies can be configured according to the Enclave's identifier.

[0126] Furthermore, it should be noted that the boot control strategy provided in this specification also offers corresponding solutions for requests that conform to the eBPF boot control strategy logic but not to the SGX driver's boot control strategy. Specifically, when a request carries a developer signature that is not an authorized developer signature configured in the SGX driver, but the request conforms to the eBPF boot control strategy logic, an authorized developer signature is determined, and this authorized developer signature is used to replace the developer signature carried in the request, thereby obtaining a request that conforms to the SGX driver's boot control strategy and executing the Enclave's boot process.

[0127] The above embodiments illustrate the control of requests sent to the SGX driver through a startup control policy configured in the eBPF kernel module. These requests refer to those generated during the Enclave's startup process, including requests for loading, initializing, running, and stopping the Enclave.

[0128] For details on the startup process of this Enclave, please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram illustrating the startup process of an Enclave according to one embodiment of this specification; Figure 4 The process is illustrated below, where a user-space application drives the entire flow via a system call interface:

[0129] 1. The user application (i.e., the Enclave application) calls the iotcl interface to pass the Enclave's metadata to the SGX driver, notifying the SGX driver module to create an EPC space in memory for the Enclave program.

[0130] 2. After receiving the metadata, the SGX driver allocates a space for the Enclave program within the EPC space based on the metadata. Once the space allocation is complete, the startup control program will send a notification to the user application confirming the completion of the space allocation.

[0131] 3. After receiving the notification, the user program will repeatedly call the iotcl interface to send the binary code data of the Enclave program to the SGX driver module. Specifically, the user program can transfer the binary code of the Enclave program to the SGX driver module in units of 4KB memory pages.

[0132] 4. After receiving the binary code data, the SGX driver module sends it to the CPU. The CPU, upon receiving the binary code data, stores it in the Enclave runtime space (EPC), thus deploying the Enclave program. The binary code data is... Figure 3 The application file content is used to send binary code data to the CPU, which is... Figure 3 The application file content is loaded onto the CPU.

[0133] 5. After the data transmission is completed, the user program calls the iotcl interface to notify the SGX driver module to obtain the metric of the Enclave program binary code calculated by the CPU. This metric can be a hash value.

[0134] 6. After obtaining this metric, the SGX driver module will instruct the CPU to retrieve the Enclave program binary code from memory and execute it when it receives a request from a user program to initialize and start an Enclave instance by calling the iotcl interface.

[0135] During the startup process described above, the SGX driver module controls the startup of the Enclave instance by comparing and deciding whether to allow the Enclave to start based on the metrics provided by the user application and the metrics it obtains in the above steps.

[0136] It should be noted that the solution provided in this manual can also be implemented by the user writing their own SGX kernel driver to achieve boot control functions without using eBPF kernel programming technology; that is, the kernel driver can implement the Enclave signature check, Enclave measurement, and Enclave blacklist and whitelist check mechanism.

[0137] The request processing method provided in this manual decouples the user's Enclave startup control mechanism from the management and control of the SGX driver module, allowing the user to implement their own Enclave control strategy without relying on the SGX driver module's processes. It is also fully compatible with the native SGX kernel driver, and security updates related to the SGX driver module can be directly upgraded. The loading, initialization, running, and stopping of the Enclave can still utilize the SGX driver module, leaving the monitored Enclave in a "seamless" state, achieving frictionless startup control. Furthermore, the Enclave control strategy (signature check, blacklist, whitelist) is implemented jointly by the user-space module and kernel module of the eBPF control program. The user-space module is responsible for configuration distribution, while the kernel module is responsible for consistency verification and execution. This enables online distribution and execution of startup control strategies, achieving decoupling between configuration strategies and kernel components, and improving the flexibility of system configuration management. For application developers, it also compensates for their lack of granular control over the Enclave.

[0138] Meanwhile, for systems with the SGX boot control mechanism enabled, this solution can supplement the shortcomings of the developer-identifier-based boot control policy in terms of control granularity. This solution can add configuration policy control at the Enclave identifier level without affecting the execution of the developer-identifier boot control policy.

[0139] Corresponding to the above method embodiments, this specification also provides a request processing system embodiment. Figure 5 A schematic diagram of the structure of a request processing system according to one embodiment of this specification is shown. Figure 5 As shown, the system includes a request monitoring program 502 and a target driver 504, wherein,

[0140] The request monitoring program 502 is configured to intercept application management requests sent to the target driver. If it is determined that the application management request meets the request execution conditions of the request monitoring program 502, but does not meet the request execution conditions of the target driver, the application management request is modified according to the request execution conditions of the target driver, and the modified application management request is sent to the target driver.

[0141] The target driver 504 is configured to execute the received application management request.

[0142] For an explanation of the request processing request, please refer to the corresponding or relevant content in the above request processing method. This specification will not elaborate further here.

[0143] Furthermore, in the embodiments provided in this specification, the application management request is an application deployment request or an application invocation request, wherein,

[0144] The target driver 504 is further configured to verify the received application deployment request, and if the verification is successful, to deploy the application code carried in the application deployment request to memory using the CPU; or

[0145] The target driver 504 is further configured to verify the received application call request, and if the verification is successful, determine the application identifier carried in the application call request, and use the CPU to load the application corresponding to the application identifier.

[0146] In practical applications, the target driver will perform startup control on the application based on its own configured startup control policy, including but not limited to the deployment and operation of the application.

[0147] An application deployment request can be understood as a request to deploy an application into the memory corresponding to the CPU. An application invocation request can be understood as a request to invoke the CPU to execute a pre-deployed application.

[0148] Specifically, after receiving the application call request, the target driver 504 determines the request verification information carried in the application call request and the program verification information of its own configured request execution conditions. If the request verification information matches the program verification information, the target driver determines that the application management request does not meet the target driver's request execution conditions. Then, the target driver 504 determines the application identifier carried in the application call request and instructs the CPU to retrieve the binary code of the application corresponding to the application identifier from memory and run the binary code to perform a specific operation.

[0149] Alternatively, after receiving the application deployment request, the target driver 504 verifies the application deployment request using the above verification method. If the verification is successful, the target driver 504 instructs the CPU to allocate a storage area from memory to store the application code carried in the application deployment request. Once the application code is stored in the storage area in memory, the deployment of the application is considered complete.

[0150] The request processing system provided in this specification intercepts application management requests that need to be sent to the target driver through a request monitoring program. If it is determined that the application management request does not meet the request execution conditions of the target driver, it makes a more granular judgment based on the request execution conditions of the request monitoring program. If the application management request meets the request execution conditions of the request monitoring program, it is changed into an application management request that meets the request execution conditions of the target driver and sent to the target driver. The target driver then executes the modified application management request, thereby enabling more granular management and control over the invocation, deployment, and operation of applications.

[0151] The above is an illustrative scheme of a request processing system according to this embodiment. It should be noted that the technical solution of this request processing system and the technical solution of the request processing method described above belong to the same concept. For details not described in detail in the technical solution of the request processing system, please refer to the description of the technical solution of the request processing method described above.

[0152] Corresponding to the above method embodiments, this specification also provides embodiments of a request processing apparatus. Figure 6 A schematic diagram of a request processing apparatus according to one embodiment of this specification is shown. Figure 6 As shown, the device is used in a request monitoring program and includes:

[0153] Interception module 602 is configured to intercept application management requests sent to the target driver;

[0154] Modification module 604 is configured to modify the application management request according to the request execution conditions of the target driver when it is determined that the application management request meets the request execution conditions of the request monitoring program but does not meet the request execution conditions of the target driver.

[0155] Sending module 606 is configured to send the modified application management request to the target driver for execution.

[0156] Optionally, the request processing apparatus further includes a request discarding module, configured to:

[0157] If it is determined that the application management request does not meet the request execution conditions of the request monitoring program, the application management request is discarded.

[0158] Optionally, the request processing apparatus further includes a request sending module, configured to:

[0159] If it is determined that the application management request meets the request execution conditions of the request monitoring program and the request execution conditions of the target driver, the application management request is sent to the target driver for execution.

[0160] Optionally, the modification module 604 is further configured to:

[0161] Determine the request verification information carried in the application management request, and determine the program verification information that satisfies the request execution conditions of the target driver;

[0162] Based on the program verification information, the request verification information carried in the application management request is replaced.

[0163] Optionally, the modification module 604 is further configured to:

[0164] Determine the application identifier carried in the application management request, and determine the application identifier to be executed corresponding to the request execution conditions of the request monitoring program;

[0165] If it is determined that the application identifier matches the application identifier to be executed, then the application management request is determined to meet the request execution conditions of the request monitoring program;

[0166] Accordingly, the request discarding module is also configured to:

[0167] If it is determined that the application identifier does not match the application identifier to be executed, it is determined that the application management request does not meet the request execution conditions of the request monitoring program.

[0168] Optionally, the modification module 604 is further configured to:

[0169] Determine the request verification information carried in the application management request, and determine the program verification information of the request execution conditions of the target driver;

[0170] If it is determined that the request verification information does not match the program verification information, it is determined that the application management request does not meet the request execution conditions of the target driver.

[0171] Accordingly, the request sending module is also configured to:

[0172] If the request verification information matches the program verification information, the application management request is determined to meet the request execution conditions of the target driver.

[0173] Optionally, the request processing apparatus further includes an application loading request management module, configured to:

[0174] Intercept the application loading request sent to the CPU by the target driver;

[0175] If it is determined that the application loading request does not meet the application loading conditions of the request monitoring program, the application loading request is discarded; or, if it is determined that the application loading request meets the application loading conditions of the request monitoring program, the application loading request is sent to the CPU.

[0176] Optionally, the application loading request management module is further configured to:

[0177] Determine the application identifier carried in the application loading request, and determine the application loading identifier corresponding to the application loading condition;

[0178] If the application identifier does not match the application loading identifier, it is determined that the application loading request does not meet the application loading conditions of the request monitoring program;

[0179] Accordingly, the application loading request management module is also configured as follows:

[0180] If the application identifier matches the application loading identifier, it is determined that the application loading request meets the application loading conditions of the request monitoring program.

[0181] Optionally, the request processing method further includes a code configuration module, configured as follows:

[0182] The code configuration program receives request processing code sent by the client and forwards it.

[0183] The steps of the above-described request processing device are executed by running the request processing code.

[0184] Optionally, the request processing method further includes a code configuration module, which is further configured to:

[0185] Receive a code configuration message sent by the code configuration program, wherein the code configuration message carries first verification information and request processing code;

[0186] Determine the second verification information corresponding to the request monitoring program, and if the first verification information and the second verification information are consistent, obtain the request processing code carried in the code configuration message.

[0187] The request processing device for a request monitoring program provided in this specification intercepts application management requests that need to be sent to a target driver. If the application management request does not meet the request execution conditions of the target driver, it makes a more granular judgment based on the request execution conditions of the request monitoring program. If the application management request meets the request execution conditions of the request monitoring program, it changes it to an application management request that meets the request execution conditions of the target driver and sends it to the target driver for execution. This allows for more granular management and control of the invocation, deployment, and operation of applications.

[0188] The above is an illustrative scheme of a request processing device according to this embodiment. It should be noted that the technical solution of this request processing device and the technical solution of the above-described request processing method belong to the same concept. For details not described in detail in the technical solution of the request processing device, please refer to the description of the technical solution of the above-described request processing method.

[0189] Figure 7 A structural block diagram of a computing device 700 according to one embodiment of this specification is shown. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0190] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0191] In one embodiment of this specification, the above-described components of the computing device 700 and Figure 7 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 7 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0192] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 700 can also be a mobile or stationary server.

[0193] The processor 720 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described request processing method.

[0194] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described request processing method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described request processing method.

[0195] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described request processing method.

[0196] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the above-described request processing method belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described request processing method.

[0197] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described request processing method.

[0198] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the aforementioned request processing method belong to the same concept. Details not described in detail in the technical solution of the computer program can be found in the description of the technical solution of the aforementioned request processing method.

[0199] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0200] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0201] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0202] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0203] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A request processing method, applied to a request monitoring program, the method comprising: Intercept application management requests sent to the target driver; If it is determined that the application management request meets the request execution conditions of the request monitoring program, but does not meet the request execution conditions of the target driver, the application management request is modified according to the request execution conditions of the target driver. The request execution conditions of the request monitoring program include the startup control policy defined by the user according to their own needs, and the request execution conditions of the target driver include the startup control rules of the target driver itself for determining whether to execute the application management request. The modified application management request is sent to the target driver for execution.

2. The request processing method according to claim 1, further comprising, after intercepting the application management request sent to the target driver: If it is determined that the application management request does not meet the request execution conditions of the request monitoring program, the application management request is discarded.

3. The request processing method according to claim 1, further comprising, after intercepting the application management request sent to the target driver: If it is determined that the application management request meets the request execution conditions of the request monitoring program and the request execution conditions of the target driver, the application management request is sent to the target driver for execution.

4. The request processing method according to claim 1, wherein modifying the application management request according to the request execution conditions of the target driver includes: Determine the request verification information carried in the application management request, and determine the program verification information that satisfies the request execution conditions of the target driver; Based on the program verification information, the request verification information carried in the application management request is replaced.

5. The request processing method according to claim 2, wherein determining that the application management request meets the request execution conditions of the request monitoring program includes: Determine the application identifier carried in the application management request, and determine the application identifier to be executed corresponding to the request execution conditions of the request monitoring program; If it is determined that the application identifier matches the application identifier to be executed, then the application management request is determined to meet the request execution conditions of the request monitoring program; Accordingly, determining that the application management request does not meet the request execution conditions of the request monitoring program includes: If it is determined that the application identifier does not match the application identifier to be executed, it is determined that the application management request does not meet the request execution conditions of the request monitoring program.

6. The request processing method according to claim 3, wherein determining that the application management request does not meet the request execution conditions of the target driver includes: Determine the request verification information carried in the application management request, and determine the program verification information of the request execution conditions of the target driver; If it is determined that the request verification information does not match the program verification information, it is determined that the application management request does not meet the request execution conditions of the target driver. Accordingly, determining that the application management request satisfies the request execution conditions of the target driver includes: If the request verification information matches the program verification information, the application management request is determined to meet the request execution conditions of the target driver.

7. The request processing method according to claim 1, further comprising: Intercept the application loading request sent to the CPU by the target driver; If it is determined that the application loading request does not meet the application loading conditions of the request monitoring program, the application loading request is discarded; or, if it is determined that the application loading request meets the application loading conditions of the request monitoring program, the application loading request is sent to the CPU.

8. The request processing method according to claim 7, wherein determining that the application loading request does not meet the application loading conditions of the request monitoring program includes: Determine the application identifier carried in the application loading request, and determine the application loading identifier corresponding to the application loading condition; If the application identifier does not match the application loading identifier, it is determined that the application loading request does not meet the application loading conditions of the request monitoring program; Accordingly, determining that the application loading request satisfies the application loading conditions of the request monitoring program includes: If the application identifier matches the application loading identifier, it is determined that the application loading request meets the application loading conditions of the request monitoring program.

9. The request processing method according to any one of claims 1 to 8, further comprising, before intercepting the application management request sent to the target driver: The code configuration program receives request processing code sent by the client and forwards it. By running the request processing code, the steps of the request processing method according to any one of claims 1 to 8 are executed.

10. The request processing method according to claim 9, wherein the request processing code sent by the receiving code configuration program includes: Receive a code configuration message sent by the code configuration program, wherein the code configuration message carries first verification information and request processing code; Determine the second verification information corresponding to the request monitoring program, and if the first verification information and the second verification information are consistent, obtain the request processing code carried in the code configuration message.

11. A request processing system, comprising a request monitoring program and a target driver, wherein, The request monitoring program is configured to intercept application management requests sent to the target driver. If it is determined that the application management request meets the request execution conditions of the request monitoring program but does not meet the request execution conditions of the target driver, the application management request is modified according to the request execution conditions of the target driver, and the modified application management request is sent to the target driver. The request execution conditions of the request monitoring program include the startup control policy defined by the user according to their own needs, and the request execution conditions of the target driver include the startup control rules of the target driver itself for determining whether to execute the application management request. The target driver is configured to execute received application management requests.

12. The request processing system according to claim 11, wherein the application management request is an application deployment request or an application invocation request, wherein, The target driver is further configured to verify the received application deployment request, and if the verification is successful, to deploy the application code carried in the application deployment request to memory using the CPU; or The target driver is further configured to verify the received application call request, and if the verification is successful, determine the application identifier carried in the application call request, and use the CPU to load the application corresponding to the application identifier.

13. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the request processing method according to any one of claims 1 to 10.

14. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the request processing method according to any one of claims 1 to 10.

15. A computer program product comprising computer instructions that, when executed by a processor, implement the steps of the request processing method according to any one of claims 1 to 10.

Images