A processing method, apparatus and electronic device

Abstract

The application discloses a processing method, device and electronic equipment, the method comprises the following steps: in response to a first request of a first running environment, and sending the first request to a second running environment; the first request is used for requesting the second running environment to execute a first task; in the second running environment, a single subtask in multiple subtasks is used as a unit to execute the first task; the multiple subtasks are used to realize the first task; interrupt is prohibited in the process of executing each subtask in the second running environment; the security protection capability of the second running environment is higher than that of the first running environment; after each subtask is executed, task state information is generated, and the task state information is returned to the first running environment, so that the second request is generated based on the task state information in the first running environment, and is sent to the second running environment, and the second request is used to execute a next subtask in the first task; the task state information represents the execution progress of the first task.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a processing method, apparatus and electronic device. Background Technology

[0002] Currently, in order to address the issue that the non-secure side of the system cannot respond to external events or schedule routine business during the execution of secure processing tasks, it is possible to preempt secure processing tasks in response to interruptions on the non-secure side. However, this can easily lead to the leakage of sensitive data in secure processing tasks, making it difficult to effectively guarantee the security of secure processing task execution. Summary of the Invention

[0003] The technical solution provided in this application is as follows:

[0004] The first aspect of this application provides a processing method, including:

[0005] In response to a first request from a first runtime environment, the first request is sent to a second runtime environment; the first request is used to request the second runtime environment to perform a first task.

[0006] In the second operating environment, the first task is executed on a per-subtask basis, among multiple subtasks; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second operating environment; the security protection capability of the second operating environment is higher than that of the first operating environment.

[0007] After each subtask is completed, task status information is generated and returned to the first runtime environment. Based on the task status information, a second request is generated in the first runtime environment and sent to the second runtime environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task.

[0008] In one possible implementation, the processing method further includes:

[0009] After the second operating environment returns task status information to the first operating environment, the second task is executed in the first operating environment if the second task is detected; the security processing level of the first task is higher than that of the second task; the first task corresponds to the first scheduling priority; the second task corresponds to the second scheduling priority; the second scheduling priority is higher than the first scheduling priority.

[0010] In one possible implementation, the processing method further includes:

[0011] After the second runtime environment returns task status information to the first runtime environment, in the first runtime environment, if a third task is detected, a third request is generated and sent to the second runtime environment; the task status information indicates that the first task has not been completed; the security processing level of the third task is not lower than that of the first task; the first task corresponds to a first scheduling priority; the third task corresponds to a third scheduling priority; the third scheduling priority is higher than the first scheduling priority;

[0012] Upon receiving the third request, the second runtime environment executes the third task within the second runtime environment; the next subtask in the first task is not started.

[0013] In one possible implementation, the second request includes multiple second sub-requests, generated based on the task status information in the first runtime environment, including:

[0014] When the task status information indicates that the first task has not been completed, a first type of second sub-request is generated. The first type of second sub-request is used to trigger the continued execution of the next sub-task among the plurality of sub-tasks in the second running environment.

[0015] When the task status information indicates that the first task has been completed, a second type of second sub-request is generated. The second type of second sub-request is used to obtain the execution result of the first task in the second running environment.

[0016] Specifically, during the process of the first runtime environment responding to the second task, the execution context information of the first task is not lost in order to generate the plurality of second sub-requests.

[0017] In one possible implementation, the plurality of subtasks are obtained in the following manner:

[0018] Select a first candidate operation that satisfies a first set condition from among multiple operations of the first task;

[0019] Combine the first candidate operations into a first subtask;

[0020] Determine the target parameters of a second candidate operation among the plurality of operations, excluding the first candidate operation;

[0021] Based on the target parameters, the second candidate operations are grouped and combined to obtain the second sub-task;

[0022] The first subtask and the second subtask are identified as multiple subtasks for implementing the first task.

[0023] In one possible implementation, selecting a first candidate operation that satisfies a first predefined condition from a plurality of operations of the first task includes at least one of the following:

[0024] Select a first candidate operation from among the multiple operations of the first task whose runtime satisfies a first set duration threshold;

[0025] Select a first candidate operation from among the multiple operations of the first task that is relevant to the target data that needs to be protected.

[0026] In one possible implementation, determining the target parameters of the second candidate operation among the plurality of operations, excluding the first candidate operation, includes at least one of the following:

[0027] Determine a first parameter for each second candidate operation other than the first candidate operation among the plurality of operations; the first parameter characterizes the runtime of the second candidate operation;

[0028] Determine a second parameter for each second candidate operation other than the first candidate operation among the plurality of operations; the second parameter characterizes the computational complexity of the second candidate operation;

[0029] The process of grouping and combining the second candidate operations based on the target parameters to obtain the second sub-task includes at least one of the following:

[0030] Based on the first parameter, the corresponding second candidate operations are combined to obtain the second subtask; the cumulative value of the first parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the first parameter.

[0031] Based on the second parameter, the corresponding second candidate operations are combined to obtain the second subtask; the cumulative value of the second parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the second parameter.

[0032] Another aspect of this application provides a processing apparatus, comprising:

[0033] The first switching module is configured to respond to a first request from the first runtime environment and send the first request to the second runtime environment; the first request is used to request the second runtime environment to execute a first task;

[0034] The first execution module is used to execute a first task in the second running environment, taking each subtask as a unit; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second running environment; the security protection capability of the second running environment is higher than that of the first running environment;

[0035] A generation module is used to generate task status information after each of the subtasks is completed; the task status information represents the execution progress of the first task.

[0036] The return module is used to return the task status information to the first running environment, so that the first running environment can generate a second request based on the task status information and send it to the second running environment. The second request is used to execute the next subtask in the first task.

[0037] A third aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0038] The memory is used to store computer programs;

[0039] The processor is used to execute the computer program to enable the electronic device to perform the following method steps:

[0040] In response to a first request from a first runtime environment, the first request is sent to a second runtime environment; the first request is used to request the second runtime environment to perform a first task.

[0041] In the second operating environment, the first task is executed on a per-subtask basis, among multiple subtasks; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second operating environment; the security protection capability of the second operating environment is higher than that of the first operating environment.

[0042] After each subtask is completed, task status information is generated and returned to the first runtime environment. Based on the task status information, a second request is generated in the first runtime environment and sent to the second runtime environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task. Attached Figure Description

[0043] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0044] Figure 1 A flowchart illustrating a processing method provided in Embodiment 1 of this application;

[0045] Figure 2 A schematic diagram illustrating an implementation scenario of the processing method provided in this application;

[0046] Figure 3 A schematic diagram illustrating another implementation scenario of the processing method provided in this application;

[0047] Figure 4 This is a flowchart illustrating a processing method provided in Embodiment 2 of this application;

[0048] Figure 5 This is a flowchart illustrating a processing method provided in Embodiment 3 of this application;

[0049] Figure 6 This is a flowchart illustrating a processing method provided in Embodiment 4 of this application;

[0050] Figure 7 A schematic diagram of a collaborative secure call framework provided in this application;

[0051] Figure 8 A task scheduling timing diagram provided in this application;

[0052] Figure 9 A schematic diagram illustrating the execution of an application provided in this application;

[0053] Figure 10 This is a task breakdown diagram provided for this application. Detailed Implementation

[0054] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0055] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0056] The terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0057] Reference Figure 1 This is a flowchart illustrating a processing method provided in Embodiment 1 of this application, as shown below. Figure 1 As shown, the method may include, but is not limited to, the following steps:

[0058] Step S101: Respond to the first request of the first runtime environment and send the first request to the second runtime environment; the first request is used to request the second runtime environment to perform the first task.

[0059] The primary runtime environment can be responsible for hosting various non-security applications, responding to external events, scheduling routine business, handling user interactions, and other non-security-related operations, providing the runtime foundation for non-security applications.

[0060] When an application has security processing requirements (such as encryption, data verification, key generation, post-quantum cryptography operations (such as ML-DSA signatures), these requirements cannot be completed in the first runtime environment (because the security protection capabilities of the first runtime environment are insufficient). In this case, the application can initiate a first request to the system kernel through the first runtime environment, triggering runtime environment switching and the start of security tasks.

[0061] In this embodiment, the first request may include, but is not limited to:

[0062] The execution instruction can specify the details of the first task to be executed (such as ML-DSA (Module-Lattice Digital Signature Algorithm) signature, ciphertext validity verification, key generation, etc.), and is used to inform the second runtime environment of the type of security processing task to be executed.

[0063] The basic operation parameters may include: the original data required for the execution of the first task (such as the original information to be encrypted, the ciphertext to be verified, the basic threshold of the algorithm, the basic parameters of the key, etc.), which are the core input data for the execution of the secure processing task.

[0064] The session initialization information is used to establish a dedicated interactive session between the non-secure side application and the second runtime environment. It includes information such as session identifier and task identifier to ensure the uniqueness and correspondence of subsequent execution of multiple sub-tasks and task status information feedback, avoid confusion when multiple applications and tasks interact in parallel, and ensure the independence of the execution process of a single first task.

[0065] After the system kernel receives the first request transmitted by the first runtime environment (initiated by a non-secure application), it can trigger a hardware and software collaborative runtime environment switching mechanism. This switching process may include, but is not limited to:

[0066] Step S11: Temporarily store non-secure side resources.

[0067] The system kernel can completely and temporarily save the current running state of the first running environment, including: the execution context of the non-security side business application being executed in the first running environment, the current state of the CPU registers, peripheral scheduling information, intermediate execution data of the non-security side business, etc.

[0068] The core purpose of this temporary storage operation is to ensure that when the sub-tasks of the first task are completed and the runtime environment switches back to the first runtime environment, the non-security side business applications can seamlessly resume execution without business interruption or data loss, thus guaranteeing the normal operation of non-security side services.

[0069] Step S12: Security-side hardware resource scheduling.

[0070] The system kernel can schedule dedicated security hardware resources to allocate independent hardware resources to the second runtime environment that are physically isolated from the non-security side. Specifically, these resources may include: an independent security computing core (used only to perform security processing tasks and not to participate in non-security side business operations), an independent security storage area (accessible only by the second runtime environment and used to store security task computation data, sensitive parameters, etc.), and an encryption coprocessor (dedicated to handling security operations such as encryption, decryption, and signing, improving security processing efficiency).

[0071] By physically isolating hardware resources, interference from non-secure hardware operations (such as access to non-secure peripherals and routine calculations) on secure processing tasks is avoided from the bottom layer, preventing sensitive data from being leaked through the hardware level.

[0072] Step S13: Second runtime environment software initialization and secure data transmission.

[0073] First, a complete environment setup can be performed at the security software level, which includes: mounting a secure file system (for managing the secure storage area), loading a security algorithm library (containing security algorithms required for encryption, data verification, post-quantum cryptography, etc.), and initializing a secure communication protocol (for subsequent secure data interaction with the primary operating environment).

[0074] Subsequently, the execution instructions, basic operation parameters, and session initialization information in the first request can be synchronously transmitted to the secure storage area of ​​the second runtime environment through a dedicated secure data channel. This secure data channel adopts an encrypted transmission mechanism and prohibits access by any non-secure code or non-secure application, ensuring that all information in the first request is not tampered with or leaked during transmission.

[0075] Finally, the entire initialization process of the second operating environment is completed, creating an independent, isolated, and highly protected secure execution environment that meets all the requirements for executing the first task.

[0076] Step S102: In the second operating environment, the first task is executed on a per-subtask basis among multiple subtasks; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second operating environment; the security protection capability of the second operating environment is higher than that of the first operating environment.

[0077] In this embodiment, a single subtask is the smallest unit of execution for security processing. It may contain one or a group of logically coherent security processing actions (such as the continuous actions of "random vector sampling → hash operation → intermediate value verification" in ML-DSA signature, or only the single action of "random vector sampling"). However, regardless of whether it contains one or multiple actions, the subtask has the atomicity characteristics of being indivisible and uninterruptible at the execution level. That is, the execution flow of the subtask must be completed completely and is not allowed to be interrupted by any external or internal events during the execution process.

[0078] After a single subtask is completed, before the second runtime environment returns control to the first runtime environment, it can process the session context of the current first task, save the completed subtask identifier, the overall execution progress of the first task, and ordinary intermediate results that need to be carried over to the next subtask, but does not save the hardware context containing sensitive data, such as temporary sensitive values ​​in CPU registers and sensitive memory states.

[0079] The reason is that the execution of the subtask cannot be interrupted. Sensitive data is only used within the subtask and will be immediately and securely cleared after use. After the subtask is completed, there is no sensitive data in the hardware context, so there is no need to save it. Saving the non-sensitive session context is for the purpose of enabling the second runtime environment to accurately continue the first task from the current execution stage based on the context when the first runtime environment initiates a request to execute the next subtask, rather than re-executing it from the beginning, thus ensuring the continuity and efficiency of the first task execution.

[0080] Step S103: After each subtask is completed, task status information is generated and returned to the first running environment. Based on the task status information, a second request is generated in the first running environment and sent to the second running environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task.

[0081] In this embodiment, task status information may include, but is not limited to:

[0082] The session identifier is consistent with the session initialization information in the first request and is used to uniquely identify the current security task session to avoid confusion when multiple applications and tasks are running in parallel.

[0083] The first task execution progress information represents the current progress of the first task. Specifically, it may include the number of completed subtasks, the total number of subtasks, and the unique identifier of the completed subtasks. This provides a direct basis for the first runtime environment to determine whether to generate a second request (trigger the next subtask).

[0084] In this embodiment, a secure data channel can be used to transmit task status information. The secure data channel can employ an encrypted transmission mechanism and only allows the second runtime environment to transmit data to the first runtime environment. Access to the channel by non-secure code or applications is prohibited, and reverse data transmission is also prohibited (the first runtime environment only receives data and does not actively write data to the channel), ensuring that the task status information is not tampered with or leaked during transmission.

[0085] Before transmitting task status information, the second runtime environment can perform integrity verification (such as generating a checksum). After transmission, the first runtime environment receives and verifies the integrity of the task status information. If the verification fails, it will send a verification failure signal to the second runtime environment, which will then retransmit the information to ensure accurate delivery of the task status information. If the verification succeeds, the first runtime environment confirms receipt, the second runtime environment stops occupying core resources such as the CPU, releases the temporary occupation of security hardware resources, and the system kernel returns control to the first runtime environment. At this time, the first runtime environment can respond to external events and schedule routine business normally.

[0086] After receiving the second request, the second runtime environment, based on its own saved non-sensitive session context (completed subtask progress, pending logic), autonomously determines the next subtask to be executed and directly starts the execution of the subtask. The execution process still maintains the security feature of not being interrupted until the subtask is completed. Then, the status feedback and control handover process of this step is repeated to form a closed loop.

[0087] For example, assuming the first task is an ML-DSA (Module Grid Digital Signature Algorithm) signature task (total time 800ms), in this application, the first task can be divided into 8 sub-tasks. The execution time of a single sub-task is about 100ms, and the execution process is not allowed to be interrupted. Sensitive data is only used within the sub-task and is cleared immediately.

[0088] For example, assuming the first task is an ML-DSA (Modular Grid Digital Signature Algorithm) signature task (total time 800ms), in this embodiment, the first task can be divided into 8 atomic subtasks. The execution time of a single subtask is about 100ms, and the execution process of each subtask is strictly prohibited from being interrupted. Sensitive data is only used within the corresponding subtask and is immediately and securely cleared after use to ensure that sensitive data is not leaked.

[0089] If the first task is not broken down into the above 8 sub-tasks, to resolve the issue of the non-safe side being unable to respond due to an 800ms long blocking time, it is necessary to allow the non-safe side to interrupt the preemptive safety processing. The specific process is as follows: Figure 2 As shown: After the non-secure side (first runtime environment) calls the relevant interface and sends the first request, the secure side (second runtime environment) starts the full-process execution of the ML-DSA signature task. This full-process execution can be interrupted by the non-secure side.

[0090] When an insecure interrupt occurs on the insecure side (e.g., external button interruption, peripheral data reception, or other routine business requirements), the system kernel forcibly interrupts the ML-DSA signature execution process and switches to the insecure side to execute the routine business. During this process, the secure side will pause execution and save the context, which will contain sensitive parameters temporarily stored in CPU registers and temporary memory (such as random vectors generated during the ML-DSA signature process, private key fragments, etc.). These sensitive data are at risk of being accessed and read by the insecure side code, which could lead to the leakage of sensitive data.

[0091] When the ISR execution ends and the interruption is recovered, the security side restores the saved context and continues to execute the ML-DSA signing task. Although this can solve the problem of non-security side blocking, it cannot avoid the security risk of sensitive data leakage.

[0092] like Figure 3 As shown in the embodiment of this application, based on the design of splitting the first task into multiple atomic subtasks, the specific execution flow is as follows: after the non-security side calls the relevant interface and sends the first request, the security side (second runtime environment) completes initialization and starts the execution of the first subtask.

[0093] During the execution of each subtask (which takes approximately 100ms to complete), no interrupt handling is allowed to ensure that sensitive data is used securely within the subtask. In the intervals between two subtasks, the system kernel can respond to non-secure interrupts to ensure system real-time performance.

[0094] After each subtask is completed, the second runtime environment immediately generates task status information (including session identifier, completion of 1 / 8 subtasks, total of 8 subtasks, etc.) and returns it to the first runtime environment through a secure data channel; after the first runtime environment verifies the information, the second runtime environment immediately returns system control.

[0095] During the interval between two subtasks (i.e., the very short time between the completion of the first subtask and the generation and transmission of the second request by the first runtime environment), the non-secure side can respond to interruptions or handle other routine tasks normally without preempting the security processing, thus avoiding the leakage of sensitive data at the source.

[0096] When the first runtime environment determines that execution needs to continue based on the task status information, it generates a second request and transmits it to the system kernel. The system kernel wakes up the second runtime environment, which autonomously determines and executes the next subtask (such as the 2nd subtask, ..., the 7th subtask, the 8th subtask) based on its own saved non-sensitive session context. The execution process is still strictly prohibited from interruption to ensure the security of the secure processing. This process is repeated until all 8 subtasks are completed. The non-secure side stops generating the second request and ends the current request process. After the 8th subtask is completed, the secure side returns the final result (non-sensitive) of the task to the non-secure side. After the non-secure side obtains the result, the ML-DSA signature task is completed.

[0097] In this embodiment, a first request is responded to by the first runtime environment, and the first request is sent to the second runtime environment. The second runtime environment executes the task as a single subtask, and interruptions are prohibited during the execution of each subtask. This ensures that sensitive runtime parameters and key-related intermediate states exist only during the execution of the subtask, preventing the exposure of such sensitive data due to interruption preemption. After each subtask is completed, task status information representing the progress of the first task is generated and returned to the first runtime environment. The first runtime environment generates a second request based on this status information to trigger the execution of the next subtask. After the subtask is completed, the task status information is returned and verified, the second runtime environment immediately relinquishes system control. This allows the first runtime environment to respond normally to external events and schedule routine services between two subtasks without needing to resolve non-security-side blocking issues through preemption security processing, thus fundamentally avoiding the risk of sensitive data leakage caused by interruption preemption.

[0098] Meanwhile, by reasonably splitting subtasks, each blocking period is controlled within the short execution range of a single subtask (such as tens to hundreds of milliseconds), ensuring that the business in the first operating environment is only temporarily unresponsive during the short blocking period of each subtask execution, and can resume response in a timely manner during the interval after the subtask is completed. This enables the timely handling of external events and routine business as expected, avoiding business delays or anomalies.

[0099] In summary, this embodiment achieves a balance between high security in secure processing tasks and real-time performance and business continuity, while also considering both security protection and system operating efficiency.

[0100] As another optional embodiment of this application, refer to Figure 4 This is a flowchart illustrating a processing method provided in Embodiment 2 of this application, as shown below. Figure 4 As shown, the method may include, but is not limited to, the following steps:

[0101] Step S201: Responding to the first request from the first runtime environment, and sending the first request to the second runtime environment; the first request is used to request the second runtime environment to execute the first task.

[0102] Step S202: In the second operating environment, the first task is executed on a per-subtask basis; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second operating environment; the security protection capability of the second operating environment is higher than that of the first operating environment.

[0103] Step S203: After each subtask is completed, task status information is generated and returned to the first running environment. Based on the task status information, a second request is generated in the first running environment and sent to the second running environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task.

[0104] For a detailed description of steps S201-S203, please refer to the relevant description of steps S101-S103 in Example 1, which will not be repeated here.

[0105] Step S204: After the second running environment returns task status information to the first running environment, the second task is executed in the first running environment when the second task is detected; the security processing level of the first task is higher than that of the second task; the first task corresponds to the first scheduling priority; the second task corresponds to the second scheduling priority; the second scheduling priority is higher than the first scheduling priority.

[0106] After generating the task status information, system control is completely returned to the first operating environment.

[0107] After the first operating environment switch is completed and normal operation is restored, it can detect in real time whether there is a second task to be executed. The detection scope may include, but is not limited to: tasks triggered by external interrupts (such as key interrupts, peripheral data reception interrupts), and high-priority regular tasks preset by the system (such as real-time data monitoring, regular business scheduling instructions, etc.).

[0108] If the first runtime environment detects a second task to be executed, since the scheduling priority of the second task is higher than that of the first task, the system kernel can prioritize scheduling core resources such as the CPU to execute the second task; if no second task is detected, the first runtime environment determines whether a second request needs to be generated based on the task status information returned in step S203, and triggers the execution of the next subtask.

[0109] The execution of the second task is completed entirely in the first runtime environment. There is no need to switch to the second runtime environment during the execution process, and it will not affect the non-sensitive session context saved in the second runtime environment. After the execution is completed, the first runtime environment releases the relevant resources and checks again whether there are other second tasks to be executed. If there are, the execution continues. If not, a second request is generated, and the second runtime environment is woken up by the system kernel to continue executing the next subtask of the first task.

[0110] If the first runtime environment detects a new second task (with higher priority) while executing the second task, it can prioritize executing the new high-priority second task.

[0111] In this embodiment, by splitting the first task into multiple subtasks, that is, breaking down long-term blocking into short-term blocking of individual subtasks, the waiting time of non-security side services is significantly shortened. In this embodiment, after generating task status information, control is actively returned to the first running environment without waiting for the first running environment to actively acquire control. After the switch is completed, the first running environment can detect the second task in real time and execute it first once detected. This avoids the situation where high-priority second tasks (such as emergency peripheral data reception and critical interrupt response) passively wait between subtasks, eliminates the additional waiting delay of the second task, and further improves the system's response efficiency to high-priority non-security side tasks. This ensures that such emergency services can be started and executed immediately, effectively avoiding problems such as task delays, data loss, or anomalies caused by waiting.

[0112] As another optional embodiment of this application, refer to Figure 5 This is a flowchart illustrating a processing method provided in Embodiment 3 of this application, as shown below. Figure 5 As shown, the method may include, but is not limited to, the following steps:

[0113] Step S301: Respond to the first request of the first runtime environment and send the first request to the second runtime environment; the first request is used to request the second runtime environment to execute the first task.

[0114] Step S302: In the second operating environment, the first task is executed on a per-subtask basis among multiple subtasks; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second operating environment; the security protection capability of the second operating environment is higher than that of the first operating environment.

[0115] Step S303: After each subtask is completed, task status information is generated and returned to the first running environment. Based on the task status information, a second request is generated in the first running environment and sent to the second running environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task.

[0116] For a detailed description of steps S301-S303, please refer to the relevant description of steps S101-S103 in Example 1, which will not be repeated here.

[0117] Step S304: After the second running environment returns task status information to the first running environment, in the first running environment, if a third task is detected, a third request is generated and sent to the second running environment; the task status information indicates that the first task has not been completed; the security processing level of the third task is not lower than that of the first task; the first task corresponds to a first scheduling priority; the third task corresponds to a third scheduling priority; the third scheduling priority is higher than the first scheduling priority.

[0118] Based on the task status information, the first runtime environment can continue to initiate a request after completing the non-safety side task between subtasks, allowing the second runtime environment to execute the next subtask, ensuring that the first task can proceed continuously without interruption or repeated execution.

[0119] After a single subtask completes execution (short-term blocking ends), the system kernel actively returns system control completely to the first runtime environment.

[0120] The task status information clearly indicates that the first task has not been completed, meaning that only a single subtask has been completed, and there are still subtasks to be executed. Under this premise, after the first operating environment switches over and resumes normal operation, it will detect in real time whether there is a third task to be executed. The third task may specifically include high-priority security tasks triggered by external interrupts (such as emergency key generation, high-priority data encryption / verification interrupts) and high-priority security tasks preset by the system (such as real-time sensitive data verification). These tasks are all security processing tasks involving sensitive data and cannot be executed in the first operating environment with insufficient security protection capabilities.

[0121] The scheduling priority of the third task is higher than that of the first task. Even if the task status information determines that the first task has not been completed and there are still sub-tasks to be advanced, the high-priority third task should be responded to first to avoid delays in high-priority security tasks due to waiting for the completion of the first task's sub-tasks, which could lead to security risks.

[0122] Furthermore, the security level of the third task is no lower than that of the first task. Both tasks involve the security processing of sensitive data and cannot be executed in the first operating environment. They can only be executed securely by generating a third request and sending it to the second operating environment with higher security protection capabilities, thus preventing the leakage of sensitive data.

[0123] Based on this, the first runtime environment can immediately generate a third request, which may include the specific execution instructions of the third task, basic operation parameters, and a session identifier (different from the session identifier of the first task), and send it to the second runtime environment through a full data channel. This secure data channel can employ an encrypted transmission mechanism to prohibit access by any non-secure code or application, ensuring that sensitive data in the third request is not tampered with or leaked during transmission, further strengthening security protection.

[0124] If the first runtime environment does not detect the third task before the first task is completed, it can generate a second request based on the task status information (indicating that the first task has not been completed) to trigger the execution of the next subtask of the first task, ensuring that the first task proceeds normally and does not affect the continuity of the first task.

[0125] Step S305: After receiving the third request, the second running environment executes the third task within the second running environment; the next subtask in the first task is not started.

[0126] The third task is executed in the second runtime environment. Its execution logic is consistent with that of the subtasks of the first task. Interruption is prohibited throughout the process. Sensitive data exists only during the execution of the third task and is immediately and securely cleared after use.

[0127] Meanwhile, the system kernel can allocate independent secure hardware resources (such as independent secure computing cores and secure storage areas) for the third task to avoid resource conflicts with the first task, eliminate the risk of sensitive data leakage, and ensure the security of secure processing.

[0128] During the execution of the third task, the next subtask of the first task will not be started. This avoids the third task and the first task's subtasks competing for security hardware resources and CPU core resources, which could lead to reduced execution efficiency or security vulnerabilities. After the third task is completed, the second runtime environment will generate completion status information for the third task and return it to the first runtime environment through a secure data channel. After receiving and verifying the information, the first runtime environment will generate a second request to wake up the second runtime environment and resume the execution of the next subtask of the first task.

[0129] In this embodiment, by dividing the first task into multiple uninterrupted subtasks, while ensuring high security of the security processing task, the system actively switches back to the first running environment during the intervals between subtasks. This allows the system to detect and prioritize the execution of a third task with a higher priority and a security processing level no lower than that of the first task in real time. This avoids delays in high-priority security tasks due to waiting for the completion of the first task's subtasks. On the basis of ensuring system real-time performance and business continuity, this embodiment further enhances the responsiveness to high-priority security tasks, effectively avoids security risks, and improves the overall system security and task execution efficiency.

[0130] As another optional embodiment of this application, refer to Figure 6 This is a flowchart illustrating a processing method provided in Embodiment 4 of this application, as shown below. Figure 6 As shown, the method may include, but is not limited to, the following steps:

[0131] Step S401: Respond to the first request from the first runtime environment and send the first request to the second runtime environment; the first request is used to request the second runtime environment to execute the first task.

[0132] Step S402: In the second operating environment, the first task is executed on a per-subtask basis among multiple subtasks; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second operating environment; the security protection capability of the second operating environment is higher than that of the first operating environment.

[0133] Step S403: After each subtask is completed, task status information is generated and returned to the first running environment. Based on the task status information, a second request is generated in the first running environment and sent to the second running environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task.

[0134] For detailed procedures of steps S401-S403, please refer to the relevant description of steps S101-S103 in Example 1, which will not be repeated here.

[0135] Step S404: In the first operating environment, in response to a release event triggered by the application corresponding to the first task, the task is scheduled for execution from other tasks with the same scheduling priority as the first task; the release event is used to release the access rights to the central processing unit.

[0136] The application corresponding to the first task can actively trigger a release event to actively release its CPU usage rights. The first task is not suspended; that is, the first task is neither terminated nor paused. It only temporarily relinquishes CPU resources and remains in a state of waiting to continue executing the next subtask. Its execution flow is not interrupted.

[0137] In this embodiment, the application triggering a release event may include, but is not limited to:

[0138] When an application calls the k_yield() interface, it voluntarily relinquishes the right to use the CPU, does not enter a sleep state, and immediately returns the CPU scheduling right to the system scheduler, allowing the scheduler to prioritize scheduling other tasks with the same scheduling priority. The application then immediately enters the execution queue, waiting for the next CPU scheduling.

[0139] Alternatively, the application can call the k_sleep() interface to actively enter a short sleep state (the sleep duration can be set), actively release CPU usage rights during the sleep period, not participate in CPU scheduling, and automatically wake up after the sleep ends, re-enter the execution queue, and wait for CPU scheduling.

[0140] In this embodiment, if a high-priority task is detected (e.g., the second task in embodiment 2, the third task in embodiment 3), the high-priority task is executed first, and the scheduling of tasks with the same priority in this step is not triggered. The scheduling of tasks with the same priority is only executed when there are no high-priority tasks.

[0141] In this embodiment, the scheduler (which may be managed by the system kernel) can select a task from other tasks to be executed with the same priority as the first task for scheduling and execution. The scheduling rules may adopt conventional scheduling methods such as round-robin or priority preemption and supplementation, and this application does not make specific limitations.

[0142] The scheduled tasks with the same priority are executed in the first runtime environment. After execution, the scheduler can release the CPU usage rights of the task. At this time, the first task is still in the pending execution state. Based on the task status information, the first runtime environment generates a second request, triggering the system control to be returned to the second runtime environment, and the next subtask of the first task continues to be executed, ensuring the continuity of the first task.

[0143] If a higher-priority task (such as the second or third task) is detected during the execution of other tasks with the same scheduling priority, the execution of the task with the same scheduling priority can be immediately paused, and the higher-priority task can be scheduled first. After the higher-priority task is completed, the execution of the task with the same scheduling priority can be resumed, or the execution can be directly switched to the second runtime environment to execute the next subtask of the first task.

[0144] In this embodiment, from the perspective of task scheduling fairness, the first task may continuously occupy CPU resources during the intervals between subtasks. This can cause other non-safety-side regular tasks with the same scheduling priority as the first task to fail to execute due to the inability to obtain CPU scheduling opportunities. However, the mechanism of the application actively releasing CPU resources can effectively avoid this situation without terminating or suspending the first task, thus improving the fairness of the system in task scheduling and ensuring that all types of tasks can obtain reasonable running opportunities.

[0145] Regarding system resource utilization and responsiveness, applications can trigger release events by calling interfaces such as k_yield() and k_sleep(). This operation enables the rational allocation of CPU resources among tasks of the same priority, avoiding the waste of core hardware resources due to prolonged occupation by a single task. Simultaneously, it reduces system response latency caused by prolonged resource occupation by a single task, further improving the overall system responsiveness and performance.

[0146] From a security and task continuity perspective, the application's act of actively releasing CPU usage rights is merely a temporary relinquishment. This process does not affect the pending execution state of the first task, nor does it alter the security logic of subtask splitting and interrupt-prohibited execution in previous embodiments. On the one hand, it ensures that the first task can subsequently proceed normally to execute the next subtask based on task status information, ensuring the continuity and stability of secure task processing; on the other hand, it eliminates the risk of sensitive data leakage that may occur due to resource release or task scheduling.

[0147] As another optional embodiment of this application, a processing method provided in embodiment 5 of this application, in this embodiment, the second request may include multiple second sub-requests. In this embodiment, a cooperative security call subsystem can be set in the system kernel (e.g., Zephyr OS kernel space) to provide standardized API interfaces for applications.

[0148] The standardized API interface can specifically include csc_init() (initialization interface), csc_cont() (continue execution interface), and csc_finish() (end processing interface), which correspond to the three key stages of initializing the first task, continuing the execution of subtasks, and obtaining the task end result, respectively.

[0149] The cooperative secure invocation subsystem can interact with the scheduler in the system kernel to achieve flexible task scheduling, support the collaboration of secure and non-secure tasks, and respond to high-priority task interrupts.

[0150] The collaborative secure invocation subsystem can manage the execution context of the primary task, ensuring that the context is not lost and supporting the interruption and recovery of secure tasks.

[0151] This embodiment is mainly an implementation method for generating a second request based on the task status information in the first operating environment, and may include, but is not limited to, the following steps:

[0152] Step S21: When the task status information indicates that the first task has not been completed, a first type of second sub-request is generated. The first type of second sub-request is used to trigger the continued execution of the next sub-task among the multiple sub-tasks in the second running environment.

[0153] When the first runtime environment receives task status information returned by the second runtime environment, and the task status information indicates that the first task has not been completed (i.e., some sub-tasks have been completed, but there is still another sub-task to be executed), the application in the first runtime environment can generate the first type of second sub-request by calling the cooperative secure call subsystem's csc_cont().

[0154] The first type of second sub-request may include, but is not limited to, a session identifier (which is completely identical to the session identifier in the first request). Its core function is to uniquely identify the currently executing first task session, ensuring that the second runtime environment can accurately match the corresponding security task.

[0155] The first type of second sub-request (carrying only a session identifier) ​​can be transmitted to the second runtime environment through the hardware abstraction layer (TrustZone Driver). After receiving it, the second runtime environment accurately locates the corresponding first task through the session identifier. Based on its own maintained sub-task execution order, completed progress, and non-sensitive session context, it can directly start the execution of the next sub-task without re-initializing the security environment, and without the first runtime environment intervening in the scheduling and order management of the sub-tasks.

[0156] Step S22: When the task status information indicates that the first task has been completed, a second type of second sub-request is generated. The second type of second sub-request is used to obtain the execution result of the first task in the second running environment.

[0157] When the first runtime environment receives task status information indicating that the first task has been completed (i.e., all subtasks have been completed and all security processing tasks have been completed), the application in the first runtime environment can generate a second type of second sub-request by calling csc_finish() of the cooperative security call subsystem.

[0158] The second type of second sub-request may include, but is not limited to, a session identifier (consistent with the session identifier of the first request and the first type of second sub-request). Its core purpose is to allow the second runtime environment to accurately locate the completed first task through the session identifier, triggering the second runtime environment to autonomously execute the end-of-processing flow. This eliminates the need for the first runtime environment to send an additional task completion confirmation instruction. The `csc_finish()` call itself, combined with the session identifier, clearly informs the second runtime environment that the first task corresponding to the current session has been fully completed and requires cleanup operations. The specific content of the end-of-processing (such as securely cleaning sensitive data, organizing the final execution results, and releasing security hardware resources) is all autonomously controlled by the second runtime environment.

[0159] The second type of second sub-request (carrying only a session identifier) ​​can be transmitted to the second runtime environment through the hardware abstraction layer. The second runtime environment locates the completed first task through the session identifier, autonomously executes the end processing flow, completely clears all sensitive data (to avoid sensitive information residue), organizes the final execution result of the first task (non-sensitive data, to ensure data security), and then returns the final result to the first runtime environment through a secure data channel. At the same time, it autonomously releases the security hardware resources and session context occupied by the task, completely ending the current security task session. The entire process requires no additional intervention from the first runtime environment.

[0160] Specifically, during the process of the first runtime environment responding to the second task, the execution context information of the first task is not lost in order to generate the plurality of second sub-requests.

[0161] The execution context information of the first task may include, but is not limited to: the session identifier of the first task and the progress of currently completed subtasks.

[0162] It should be noted that the subtask execution order related records that the second runtime environment can maintain independently belong to the internal management information of the second runtime environment and do not need to be stored in the first runtime environment. The collaborative security call subsystem also does not need to back up such records synchronously. It only needs to maintain the core information related to the generation of the second sub-request on the first runtime environment side.

[0163] When the first runtime environment responds to the second task, it temporarily interrupts the sub-request generation process related to the first task. At this time, the collaborative secure call subsystem can securely store the aforementioned context information (session identifier, progress of completed sub-tasks) belonging only to the first runtime environment (stored in a non-sensitive storage area to eliminate the risk of leakage), preventing the loss of this information due to responding to the second task. When the second task is completed and the first runtime environment resumes processing the first task, the collaborative secure call subsystem will retrieve the saved context information, allowing the first runtime environment to accurately know the current execution status of the first task (incomplete / completed), and then generate the corresponding first or second type of second sub-request (carrying only the session identifier). This ensures that the generation logic of the second sub-request is coherent and accurate, and can be consistent with the task status maintained autonomously by the second runtime environment, achieving seamless resumption of the first task's execution without problems such as chaotic sub-request generation or inability to reconnect task execution breakpoints.

[0164] In this embodiment, combined with Figure 7 The Cooperative Secure Call (CSC) framework illustrated here describes the processing method. For example, as... Figure 7 As shown, during the initialization phase: the Zephyr OS user space / application layer (non-security side, corresponding to the first runtime environment) initiates the first request, calls the csc_init() function of the cooperative secure call subsystem (i.e., an implementation of a state machine interface), and initializes the session context of the first task.

[0165] Environment switching and subtask execution: The cooperative secure call subsystem transmits the first request to the second runtime environment through the hardware abstraction layer (TrustZone Driver), triggering the runtime environment to switch from the first runtime environment to the second runtime environment. After the second runtime environment completes initialization, it starts the execution of the first subtask (interruption is prohibited during the execution process).

[0166] Subtasks are executed in a loop (triggered by the second sub-request of the first type): After a single subtask is completed, the second runtime environment generates task status information (indicating that the execution is not complete) and returns it to the first runtime environment through a secure data channel; after the first runtime environment passes the verification, it calls csc_cont() (i.e., an implementation of a state machine interface) to generate the second sub-request of the first type, which is transmitted to the second runtime environment through the hardware abstraction layer to trigger the execution of the next subtask; this loop continues until all subtasks are completed.

[0167] Task completion (second type of second sub-request trigger): When the last sub-task is completed, the second runtime environment generates task status information indicating "task completed" and returns it to the first runtime environment; the first runtime environment calls csc_finish() (i.e., an implementation of a state machine interface) to generate a second type of second sub-request and transmits it to the second runtime environment; the second runtime environment performs the completion processing, returns the final execution result, and releases resources.

[0168] Interrupt response and context protection: In the above process, if the Zephyr OS kernel space interrupt management detects a high-priority second task (a non-safety-side task), it triggers the scheduler to interrupt the current process. The cooperative safety call subsystem saves the execution context of the first task (i.e., context management). The first runtime environment prioritizes the execution of the second task. After the execution is completed, based on the saved context, the execution of the subtasks of the first task is resumed through csc_cont() to ensure that the context is not lost and the process is not interrupted.

[0169] The second runtime environment (e.g., a TEE based on TF-M (TF-M / TEE)) serves as the core carrier for security processing and can be autonomously controlled throughout the entire process without intervention from the first runtime environment. Specific control processes may include:

[0170] Session context management is the foundation for the second runtime environment to process the first task and is present throughout the entire security task execution process. The session context here is non-sensitive execution information related to the current first task that is autonomously maintained by the second runtime environment (distinct from the context saved by the collaborative security call subsystem on the first runtime environment side).

[0171] The session context may include, but is not limited to, the session identifier for the current first task, the total number of subtasks, the identifiers of completed subtasks, the execution logic parameters of the currently pending subtasks, and the subtask execution order rules. These are all internal management information of the second runtime environment and are not transmitted to the first runtime environment, nor do they require maintenance by the first runtime environment. Its core function is to ensure that the second runtime environment can accurately record the execution progress of the first task, connect the execution flow of each subtask, and prevent subtasks from being executed repeatedly, missed, or in a disordered order.

[0172] Initialization(): This corresponds to the environment switching and subtask execution phase in the preceding process. It is the first processing action after the second running environment receives the first request. Its core purpose is to complete the construction of a secure execution environment and lay the foundation for the execution of the subtasks of the first task.

[0173] After receiving the first request (carrying a session identifier, first task execution instructions, basic operation parameters, etc.) from the cooperative secure invocation subsystem through the hardware abstraction layer, the second runtime environment initiates initialization operations, which may include: mounting a secure file system, loading a secure algorithm library (such as the ML-DSA signature algorithm), initializing a secure storage area (used to store non-sensitive parameters required for subtask execution), initializing its own session context based on the session identifier in the first request (recording the total number of subtasks, execution order, etc.), and simultaneously allocating secure hardware resources (independent computing cores, cryptographic coprocessors). Once initialization is complete, the second runtime environment possesses all the conditions for subtask execution and immediately starts the execution of the first subtask. The execution process is strictly prohibited from interruption to ensure the security of sensitive data.

[0174] Continue execution ( ) (includes state machine) × N: corresponds to the subtask loop execution stage. "Continue execution ( )" is the core processing action after the second running environment receives the first type of second sub-request. It integrates state machine logic and is the core mechanism for realizing the loop execution of subtasks. "× N" means that this action will be executed N times (N is equal to the total number of subtasks split by the first task minus 1, that is, from the second subtask to the last subtask, all are triggered by this action).

[0175] When the second runtime environment receives the first type of second sub-request (carrying only a session identifier) ​​through the hardware abstraction layer, it locates the corresponding first task through the session identifier and calls the continue execution module. The state machine inside this module reads the session context maintained by the second runtime environment and automatically determines the sub-task to be executed (based on the progress and execution order of completed sub-tasks) without the first runtime environment needing to provide specific sub-task information. Subsequently, the state machine triggers the execution of the sub-task. The execution process still maintains the security feature of not allowing interruption. Sensitive data is only used within the sub-task and is cleared immediately. After a single sub-task is completed, the state machine automatically updates the session context (updates the progress of completed sub-tasks) and triggers the second runtime environment to generate task status information, returning to the first runtime environment to wait for the next first type of second sub-request to be triggered. This cycle continues until all sub-tasks are completed (i.e., N loops are completed).

[0176] End Processing(): This corresponds to the task completion stage. It is the final processing action after the second runtime environment receives the second type of second sub-request. Its core purpose is to complete security cleanup, result organization, and resource release to ensure the security task is closed-loop.

[0177] After locating the first task, which has completed all subtasks, through the session identifier, the second runtime environment initiates the termination processing module. This module securely clears all sensitive data (including temporary sensitive parameters and intermediate values ​​generated during subtask execution to prevent sensitive information from remaining), organizes the final execution results of the first task (retaining only non-sensitive result data and removing all sensitive information), and releases all resources occupied by the task, including secure hardware resources (independent computing cores and secure storage areas) and session context (clearing related records), thus completely terminating the current security task session. After completing the above processing, the second runtime environment returns the final execution results to the first runtime environment through a secure data channel, and the entire security task processing flow ends.

[0178] It should be noted that the session context management, initialization, continuation, and termination of the second runtime environment are all completed autonomously. The collaborative security call subsystem is only responsible for transmitting requests (the first request and two types of second sub-requests), and the first runtime environment is only responsible for triggering requests. Neither of them interferes with the internal processing logic of the second runtime environment, thus ensuring the independence and security of security processing.

[0179] This embodiment breaks down the complete security task (first task) into multiple independent, loosely coupled subtasks (i.e., task blocks). The execution of each subtask strictly adheres to the atomicity requirement of non-interruption, fundamentally eliminating security risks such as sensitive data leakage, execution logic tampering, and context confusion that may occur during interruptions, thus upholding the core of security protection. Furthermore, this solution eliminates the need for device manufacturers to develop and implement custom security interrupt handlers, lowering the development threshold for manufacturers. Only during the design phase of the standardized APIs (csc_init(), csc_cont(), csc_finish()) of the collaborative security call subsystem, by reasonably dividing the first task according to the principles of decomposability, loose coupling, and atomic execution, is it possible to achieve perfect compatibility with the existing system kernel framework without any modification to the underlying hardware. This significantly reduces the adaptation difficulty and development cost of the solution, achieving a balance between high security and low development complexity.

[0180] Furthermore, the collaborative secure call subsystem is not deployed at the application layer, but rather as a native implementation module of the system kernel, embedded within the kernel architecture, and collaborates with native components such as the kernel scheduler, interrupt management module, and hardware abstraction layer. The core advantage of this natively integrated design is that it provides a unified and standard non-blocking secure call interface (csc_init(), csc_cont(), csc_finish()) for all upper-layer applications and various system subsystems (such as file subsystems, network subsystems, and peripheral subsystems) under the system kernel. This eliminates the need for different applications or subsystems to develop their own dedicated secure call logic, effectively standardizing and unifying the secure call interface and reducing the development complexity of upper-layer applications.

[0181] Meanwhile, as a native kernel module, it has stronger synergy with various components of the system kernel, lower scheduling latency, and can better adapt to the collaborative scheduling requirements of secure and non-secure tasks, further improving the real-time performance and operational stability of the system. Moreover, it does not require the additional deployment of third-party security components, simplifying the overall system architecture and reducing system maintenance costs.

[0182] correspond Figure 7 The Cooperative Secure Call (CSC) framework shown in this embodiment combines... Figure 8 The task scheduling sequence diagram further refines the execution sequence of processing methods, clarifies the interaction logic and priority relationships of each component, and ensures that the description is accurate, thorough, and closely matches the actual scheduling process. Specific details are as follows:

[0183] Figure 8 As a task scheduling sequence diagram, it clearly presents the collaborative scheduling process between the first runtime environment (non-secure side), the second runtime environment (secure side, i.e., Secure Word (Execution State)), the Zephyr kernel scheduler, and the interrupt driver. The priorities of each component are clearly defined: the interrupt driver has the highest priority (Prio: High), the Zephyr scheduler has the next highest priority (Prio: Kernel), and the Zephyr App (non-secure side application) has the lowest priority (Prio: Normal). The timing flow may include:

[0184] Secure session initialization sequence: The Zephyr App (Prio: Normal, running in the first runtime environment, i.e., ZephyrOS user space / application layer) actively calls the cooperative secure call subsystem's csc_init() to initiate a secure service session initialization request; this request is transmitted to the second runtime environment (Secure Word (ExecutionState)) via the hardware abstraction layer. The second runtime environment immediately performs the initialization operation, and after the initialization process is completed efficiently, it quickly returns a response to inform the Zephyr App that the initialization is complete. At this time, the session context of the first task has been established, laying the foundation for the execution of subsequent subtasks.

[0185] The execution sequence of the first subtask: After receiving the initialization completion response, the Zephyr App calls the cooperative secure call subsystem's csc_continue(), triggering the generation of the first type of second sub-request and transmitting it to the second runtime environment; after receiving the request, the second runtime environment executes atomic operation 1. Here, atomic operation 1 is essentially a subtask (i.e., task block) after the first task is split. The execution process strictly follows the atomicity requirement of not being interrupted. Sensitive data is only used within this atomic operation and is cleared immediately after execution.

[0186] CPU Yield and Interrupt Scheduling Timing: After atomic operation 1 is completed, the second runtime environment returns a status indicating that the task has not been completed. After the Zephyr App obtains this status, it actively calls k_yield() to enter the pending state and actively yields the right to use the CPU. At this time, the Zephyr Scheduler (Prio: Kernel) takes over the CPU scheduling right. If it detects an interrupt request from the Interrupt Driver (Prio: High) (i.e., an interrupt triggered by the high-priority second task), it immediately schedules the Interrupt Driver to perform interrupt handling. After the interrupt handling is completed, the Interrupt Driver sends a signal to the ZephyrScheduler indicating that the processing is complete. The Zephyr Scheduler, according to the priority scheduling logic, reschedules the ZephyrApp to resume from the pending state and continue to advance the first task.

[0187] Subtask cyclic execution sequence: After the Zephyr App resumes, it calls csc_continue() again, triggering the second runtime environment to execute atomic operation 2. Atomic operation 2 corresponds to the next subtask of the first task, and the execution process also maintains the atomicity requirement of disabling interrupts. After a single atomic operation (subtask) is completed, the above process of Zephyr App calling k_yield() to yield the CPU → scheduler scheduling → interrupt handling (if any) → App resumption → calling csc_continue() to execute the next atomic operation is repeated, forming a loop until all atomic operations (i.e. all subtasks) have been completed.

[0188] It is important to note that each call to the csc_continue() interface corresponds to the execution of an atomic operation (subtask) in the second runtime environment; that is, one interface call on the non-safe side corresponds to one computation stage on the safe side. The call to k_yield() implements the reasonable allocation of CPU usage rights, ensuring that high-priority interrupts can be responded to in a timely manner. The scheduling logic of ZephyrScheduler ensures that the components coordinate in an orderly manner according to priority, realizing both the continuous advancement of safe tasks and the timely processing of high-priority non-safe tasks (interrupts), fully demonstrating the core advantages of the CSC framework: interruptibility, recoverability, and collaborative scheduling.

[0189] correspond Figure 7 The CSC framework shown in this embodiment is combined with... Figure 9 This section further explains the entire processing method from the perspective of the application (running in the first runtime environment, i.e., Zephyr OS user space / application layer), clarifying the operational logic and interaction flow on the application side, such as... Figure 9 As shown, the security service session is first initialized: The application initiates the initialization operation of the security service session by calling `csc_init()` provided by the cooperative security call subsystem, triggering the initialization process of the first task. After calling this interface, the cooperative security call subsystem assigns a unique session identifier (i.e., handle) to this first task and returns the handle to the application. This handle (session identifier) ​​is the core credential for subsequent interactions between the application and the cooperative security call subsystem and the second runtime environment, used to uniquely identify this security service session and ensure that all requests can accurately match the corresponding first task.

[0190] After obtaining the handle, the application calls the cooperative secure invocation subsystem's `csc_continute(handle)` (i.e., `csc_cont(handle)`), triggering the generation of the first type of second sub-request. Simultaneously, it retrieves the execution status (status) of the current first task from the cooperative secure invocation subsystem. This status is essentially the task status information returned by the second runtime environment (forwarded and adapted by the cooperative secure invocation subsystem and then provided to the application), used to inform the application of the current execution progress (incomplete / completed) of the first task.

[0191] After the application obtains the status, it can determine whether the status is IN_PROGRESS (in progress).

[0192] If the status is IN_PROGRESS, it means that the current first task is still in an incomplete state (i.e., there are still subtasks to be executed). At this time, the application will actively call the k_yield() interface to voluntarily relinquish CPU usage rights (without entering a sleep state, only temporarily relinquishing scheduling rights). After the CPU usage rights are released, the system kernel scheduler can prioritize scheduling other tasks (such as the high-priority second task, other non-safety-side tasks of the same priority), or respond to various external interrupts, to achieve reasonable allocation of system resources and prevent other tasks or interrupts from being unable to respond in a timely manner due to the application continuously occupying the CPU.

[0193] If the status is not IN_PROGRESS (i.e., the status is "execution completed"), it means that all subtasks of the first task have been completed. At this time, the application does not need to continue to trigger the execution of subtasks. Instead, it calls the csc_finish(handle) function of the cooperative security call subsystem to trigger the generation of the second type of second sub-request, and then obtains the final result (non-sensitive data) of the first task returned by the second runtime environment, thus completing this security service session.

[0194] As another optional embodiment of this application, a processing method provided in Embodiment 6 of this application is mainly an implementation method for multiple subtasks. The multiple subtasks can be, but are not limited to, obtained in the following ways:

[0195] Step S31: Select a first candidate operation that satisfies the first set condition from the multiple operations of the first task.

[0196] In this embodiment, the first task may include multiple consecutive or independent operations (such as ML-DSA signature including operations such as "loading key, sampling random vector, hash operation, signature generation, result verification").

[0197] The first set of conditions can be related to sensitive data security and core task logic, and are used to select the first candidate operation where the execution process cannot be interrupted and sensitive data is not leaked.

[0198] Step S32: Combine the first candidate operation into a first subtask.

[0199] In this embodiment, all first candidate operations are combined into an independent first subtask to ensure that its execution process is uninterrupted, thereby protecting sensitive data and core task logic from the source.

[0200] The first candidate operations can have logical coherence (such as the continuous operation of "sampling random vector → calculating commitment → calculating response" in ML-DSA signature), avoiding the forced combination of unrelated operations, which would lead to logical confusion in subtasks.

[0201] Step S33: Determine the target parameters of the second candidate operation among the plurality of operations, excluding the first candidate operation.

[0202] In the multiple operations of the first task, the remaining operations, excluding the first candidate operations that have been filtered, are the second candidate operations.

[0203] The second candidate operation usually does not involve core sensitive data, or is logically divisible and combinable, and its target parameters directly affect the rationality of the subtask split.

[0204] Step S34: Group and combine the second candidate operations based on the target parameters to obtain the second sub-task.

[0205] In this embodiment, based on the target parameters of the second candidate operation, a strategy of reasonable grouping and load balancing can be adopted to split the second candidate operation into one or more second sub-tasks.

[0206] During the grouping process, it is necessary to ensure the continuity of the operational logic within the same second subtask to avoid the interruption of the subtask execution process due to unreasonable grouping. At the same time, there is no need to provide excessive security protection for the second subtask (because it does not involve core sensitive data), but it is still necessary to follow the atomicity requirement that the execution process must not be interrupted to ensure the consistency of the overall security logic.

[0207] Step S35: Determine the first subtask and the second subtask as multiple subtasks for implementing the first task.

[0208] In this embodiment, the first subtask (core security subtask) and all second subtasks (auxiliary subtasks) can be integrated to form a set of multiple subtasks that implement the first task. At this point, the execution order of the subtasks must be clearly defined: the overall execution order of the subtasks must strictly follow the original operational logic of the first task and cannot be arbitrarily arranged outside the original operational order.

[0209] As another optional embodiment of this application, a processing method provided in embodiment 7 of this application, this embodiment is mainly an implementation of the above step S31, which may include, but is not limited to, at least one of the following:

[0210] Step S311: Select a first candidate operation from the multiple operations of the first task whose runtime satisfies a first set duration threshold.

[0211] The first set duration threshold can be flexibly set according to the system hardware performance and non-security side business response requirements to ensure that the first operating environment can respond to external events during the interval after the first subtask is completed.

[0212] In this embodiment, all operations of the first task are traversed, and the individual runtime of each operation is counted. Operations with a runtime ≤ a first set time threshold are included in the first candidate operation set. If the runtime of an operation exceeds the threshold, it is not included in the first candidate operation and is subsequently grouped and combined as the second candidate operation.

[0213] In this embodiment, the time-threshold quantification screening standard is simple to operate and can be implemented. It can effectively control the execution time of the first subtask and avoid affecting the real-time performance of the system. At the same time, short-time operations are usually simple in logic and have low coupling, making them easy to combine into atomic subtasks.

[0214] Step S312: Select a first candidate operation from the multiple operations of the first task that is related to the target data that needs to be protected.

[0215] The target data may include, but is not limited to, keys (such as the private key sk for ML-DSA signature), sensitive intermediate states (such as random vector y, hash intermediate values), one-time secret information, etc. Once such data is leaked, it will cause the entire security task to fail and is the core object of security protection.

[0216] In this embodiment, by traversing all operations of the first task, it is determined whether each operation involves the generation, processing, use or destruction of target data. If it does, it is included in the first candidate operation set regardless of whether its runtime meets the first set duration threshold. If it does not involve any sensitive data, it is used as the second candidate operation.

[0217] Any operation involving one-time secrets (such as temporarily generated random vectors) or intermediate states that may reveal private key information (such as intermediate values ​​of private key fragment operations) must be included as a first-choice operation to ensure its atomic execution. If such an operation is interrupted, sensitive data may be accessed by an insecure side, leading to the risk of leakage.

[0218] In this embodiment, by ensuring that all operations related to sensitive data are atomic, the leakage of sensitive data caused by interruptions is eliminated at the source. At the same time, the types of operations that must be atomic are clearly defined, providing a clear basis for the screening process.

[0219] As another optional embodiment of this application, this embodiment provides a processing method for embodiment 8 of this application. This embodiment is mainly an implementation of the above-mentioned steps S33 and S34. Step S33 may include, but is not limited to, at least one of the following:

[0220] Step S331: Determine the first parameter of each second candidate operation other than the first candidate operation among the plurality of operations; the first parameter characterizes the runtime of the second candidate operation.

[0221] In this embodiment, the actual runtime of each second candidate operation can be recorded by pre-statistics through system testing, i.e., executing each second candidate operation separately in the second operating environment and recording it as the first parameter of the operation; or it can be calculated by hardware performance (e.g., estimating the runtime based on the number of instructions and CPU processing speed of the operation).

[0222] In this embodiment, the first parameter serves as the core basis for grouping, ensuring that the cumulative runtime of a single second subtask is controlled within a reasonable threshold range, thus avoiding long-term blocking on the non-safe side.

[0223] Step S332: Determine the second parameter of each second candidate operation other than the first candidate operation among the plurality of operations; the second parameter represents the computational complexity of the second candidate operation.

[0224] The computational load of the second candidate operation may include, but is not limited to, the number of CPU operations (such as the number of multiplication and addition operations) required during the execution of a single second candidate operation, or the amount of data processed (such as the number of bytes), reflecting the workload of the operation.

[0225] In this embodiment, the number of operations required can be counted by analyzing the execution logic of the operation; alternatively, the CPU computation volume during the operation execution process can be monitored and recorded in real time by system tools, and used as the second parameter of the operation.

[0226] In this embodiment, when multiple second candidate operations have similar runtimes but different computational loads, they can be grouped by balancing computational load to avoid excessive computational load of a single second subtask, which could lead to excessive CPU load.

[0227] Step S34 may include, but is not limited to, at least one of the following:

[0228] Step S341: Based on the first parameter, combine the corresponding second candidate operations to obtain a second subtask; the cumulative value of the first parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the first parameter.

[0229] In this embodiment, all second candidate operations can be sorted by runtime from shortest to longest.

[0230] From the second candidate operations after sorting, operations are selected in sequence and added to temporary groups, and their runtime is accumulated.

[0231] When the cumulative runtime of a temporary group reaches the first parameter's cumulative threshold, the addition operation stops, and the temporary group is identified as a second subtask.

[0232] Repeat the above steps until all second-candidate operations have been grouped.

[0233] Step S342: Based on the second parameter, combine the corresponding second candidate operations to obtain the second subtask; the cumulative value of the second parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the second parameter.

[0234] In this embodiment, all second candidate operations can be sorted in ascending order of computational complexity.

[0235] From the second candidate operations after sorting, operations are selected one by one and added to a temporary group, and their computational load is accumulated.

[0236] When the cumulative computational load of a temporary group reaches the cumulative threshold of the second parameter, the addition operation is stopped, and the temporary group is identified as a second subtask.

[0237] Repeat the above steps until all second-candidate operations have been grouped.

[0238] In this embodiment, the target parameters of the second candidate operation are refined into a first parameter representing the runtime and a second parameter representing the computational load. Specific methods for determining the two parameters are provided, which not only ensures the operability and accuracy of parameter acquisition, but also provides a clear and quantitative core basis for subsequent grouping and combination, solving the problems of ambiguous target parameters and lack of clear standards for grouping in previous embodiments.

[0239] Meanwhile, corresponding grouping rules are provided for the two target parameters. By sorting by runtime or computational load and controlling by cumulative threshold, the cumulative runtime of a single second subtask can be kept within a reasonable range, avoiding long-term blocking on the non-safe side. At the same time, the CPU load can be balanced to prevent the system response from slowing down due to excessive computational load of a single subtask, thus taking into account both system real-time performance and resource utilization efficiency.

[0240] Combining the ML-DSA (Modular Grid Digital Signature Algorithm) signature task, complete subtask decomposition examples are provided to further clarify the core logic of embodiments 6-8, for example, such as... Figure 10 As shown, the complete process of the ML-DSA signature task includes the following 7 operations, arranged in the order of execution:

[0241] Initialization: Load private key sk, public key pk, and message M to be signed;

[0242] 1. Sample random vector y (sensitive data, belonging to one-time secrets, whose lifecycle must be strictly controlled, and must be destroyed immediately after generation and use to prevent leakage);

[0243] 2. Calculate the commitment w1 = HighBits(A·y) (involving sensitive data y);

[0244] 3. Calculate the response z = y + H(w1‖M‖tr)·s1 (involving sensitive data y and private key fragment s1);

[0245] 4. Reject sampling to check if the norm of z is valid;

[0246] If ineffective, 4a. Safely clear all intermediate states of z; 4b. Roll back to step 2 and retry;

[0247] If valid, 5. Calculate the hint h; 6. Assemble the signature sig = (z, c, h); 7. Safely clear all temporary intermediate states;

[0248] The signature ends and outputs sig.

[0249] The subtask splitting process based on Examples 6-8 may include:

[0250] Corresponding to Example 7, based on the atomic operation core: the secrecy of y is immediately destroyed after generation and use, and the first candidate operation is selected:

[0251] (1) Operation 2 (sampling y), operation 3 (calculating w1), and operation 4 (calculating z) all involve sensitive data (y, s1), and operation 2 involves a one-time secret, so it must be included in the first candidate operation set;

[0252] (2) Assuming the runtime of a single operation is as follows: Operation 1 (20ms), Operation 2 (30ms), and Operation 3 (30ms), the total runtime of the three is 80ms, which does not exceed the first set time threshold (100ms) set in Example 7. Therefore, no operation needs to be eliminated to ensure the integrity and atomicity of the first candidate operation. The final first candidate operation set (i.e., the atomic operation group, which is used to realize the full life cycle security management of y) is: Operation 1, Operation 2, and Operation 3. This set is the first subtask in Example 6. The execution process is strictly prohibited from interruption to ensure the security of the entire process of y from generation and calculation to immediate clearing after use, and to eliminate the risk of sensitive data leakage.

[0253] Corresponding to Examples 6 and 8 (Second Candidate Operation Grouping): In the first task, apart from the first candidate operation, the remaining operations (initialization, operation 4, 4a, 4b, operation 5, operation 6, operation 7) are all second candidate operations. Combining the parameter determination and grouping rules of Example 8, the grouping is as follows: 1. The initialization operation (loading key, message) is an independent second sub-task (the runtime is short, and grouping it separately can avoid coupling with other operations); 2. Operations 4 (rejection sampling check), 4a (safely clearing the intermediate state of z), and 4b (rollback retry) are logically coherent and all revolve around the exception handling after rejection sampling. They are combined into a second sub-task to ensure the integrity of the exception handling process.

[0254] 3. Operations 5 (calculate hint h), 6 (assemble signature sig), and 7 (safely clear all temporary intermediate states) are each an independent second subtask. All three are auxiliary operations before the signature is completed. They have short runtimes (each operation lasts less than 20ms) and are relatively independent in logic. Grouping them separately can reduce the coupling of subtasks and avoid excessive computation of individual subtasks.

[0255] The processing apparatus provided in this application will be described below. The processing apparatus described below can be referred to in correspondence with the processing method described above.

[0256] The processing device includes:

[0257] The first switching module is used to respond to a first request from the first operating environment and send the first request to the second operating environment; the first request is used to request the second operating environment to execute a first task.

[0258] The first execution module is used to execute the first task in the second running environment, taking each subtask as a unit; the multiple subtasks are used to implement the first task; interruption is prohibited during the execution of each subtask in the second running environment; the security protection capability of the second running environment is higher than that of the first running environment.

[0259] The generation module is used to generate task status information after each of the subtasks is completed; the task status information represents the execution progress of the first task.

[0260] The return module is used to return the task status information to the first running environment, so that the first running environment can generate a second request based on the task status information and send it to the second running environment. The second request is used to execute the next subtask in the first task.

[0261] The processing apparatus may also include:

[0262] The second execution module is used to execute the second task in the first running environment when the second running environment detects the second task after the second running environment returns task status information to the first running environment; the security processing level of the first task is higher than that of the second task; the first task corresponds to a first scheduling priority; the second task corresponds to a second scheduling priority; and the second scheduling priority is higher than the first scheduling priority.

[0263] The processing apparatus may further include:

[0264] The sending module is configured to, after the second runtime environment returns task status information to the first runtime environment, generate a third request in the first runtime environment when a third task is detected, and send the third request to the second runtime environment; the task status information indicates that the first task has not been completed; the security processing level of the third task is not lower than that of the first task; the first task corresponds to a first scheduling priority; the third task corresponds to a third scheduling priority; and the third scheduling priority is higher than the first scheduling priority.

[0265] The third execution module is used to execute the third task in the second running environment after the second running environment receives the third request; the next subtask in the first task is not started.

[0266] The processing apparatus may also include:

[0267] The fourth switching module is used to switch from the second running environment to the first running environment after the task status information is generated;

[0268] The fourth execution module is used, in the first operating environment, in response to a release event triggered by the application corresponding to the first task, to schedule and execute from other tasks with the same scheduling priority as the first task; the release event is used to release the right to use the central processing unit.

[0269] The second request may include multiple second sub-requests. Generating the second request based on the task status information in the first runtime environment may include:

[0270] When the task status information indicates that the first task has not been completed, a first type of second sub-request is generated. The first type of second sub-request is used to trigger the continued execution of the next sub-task among the plurality of sub-tasks in the second running environment.

[0271] When the task status information indicates that the first task has been completed, a second type of second sub-request is generated. The second type of second sub-request is used to obtain the execution result of the first task in the second running environment.

[0272] Specifically, during the process of the first runtime environment responding to the second task, the execution context information of the first task is not lost in order to generate the plurality of second sub-requests.

[0273] The processing apparatus may further include: a determining module, used for:

[0274] Select a first candidate operation that satisfies a first set condition from among multiple operations of the first task;

[0275] Combine the first candidate operations into a first subtask;

[0276] Determine the target parameters of a second candidate operation among the plurality of operations, excluding the first candidate operation;

[0277] Based on the target parameters, the second candidate operations are grouped and combined to obtain the second sub-task;

[0278] The first subtask and the second subtask are identified as multiple subtasks for implementing the first task.

[0279] The determining module selects a first candidate operation that satisfies a first set condition from multiple operations of the first task, which may include at least one of the following:

[0280] Select a first candidate operation from among the multiple operations of the first task whose runtime satisfies a first set duration threshold;

[0281] Select a first candidate operation from among the multiple operations of the first task that is relevant to the target data that needs to be protected.

[0282] The determining module determines the target parameters of a second candidate operation other than the first candidate operation among the plurality of operations, which may include at least one of the following:

[0283] Determine a first parameter for each second candidate operation other than the first candidate operation among the plurality of operations; the first parameter characterizes the runtime of the second candidate operation;

[0284] Determine a second parameter for each second candidate operation other than the first candidate operation among the plurality of operations; the second parameter characterizes the computational complexity of the second candidate operation;

[0285] The process of grouping and combining the second candidate operations based on the target parameters to obtain the second sub-task includes at least one of the following:

[0286] Based on the first parameter, the corresponding second candidate operations are combined to obtain the second subtask; the cumulative value of the first parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the first parameter.

[0287] Based on the second parameter, the corresponding second candidate operations are combined to obtain the second subtask; the cumulative value of the second parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the second parameter.

[0288] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0289] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred 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 readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0290] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0291] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A processing method, comprising: In response to a first request from the first runtime environment, the first request is sent to the second runtime environment; The first request is used to request the second runtime environment to execute the first task; In the second operating environment, the first task is executed on a per-subtask basis, taking each subtask as an individual task among multiple subtasks; The multiple subtasks are used to implement the first task; Interruptions are prohibited during the execution of each of the subtasks in the second runtime environment; The second operating environment has higher security protection capabilities than the first operating environment; After each subtask is completed, task status information is generated and returned to the first runtime environment. Based on the task status information, a second request is generated in the first runtime environment and sent to the second runtime environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task.

2. The processing method according to claim 1, further comprising: After the second operating environment returns task status information to the first operating environment, the second task is executed in the first operating environment if the second task is detected; the security processing level of the first task is higher than that of the second task; the first task corresponds to the first scheduling priority; the second task corresponds to the second scheduling priority; the second scheduling priority is higher than the first scheduling priority.

3. The processing method according to claim 1, further comprising: After the second runtime environment returns task status information to the first runtime environment, in the first runtime environment, if a third task is detected, a third request is generated and sent to the second runtime environment; the task status information indicates that the first task has not been completed; the security processing level of the third task is not lower than that of the first task; the first task corresponds to a first scheduling priority; the third task corresponds to a third scheduling priority; the third scheduling priority is higher than the first scheduling priority; Upon receiving the third request, the second runtime environment executes the third task within the second runtime environment; the next subtask in the first task is not started.

4. The processing method according to claim 1, further comprising: In the first operating environment, in response to a release event triggered by the application corresponding to the first task, execution is scheduled from other tasks with the same scheduling priority as the first task; the release event is used to release the access rights to the central processing unit.

5. The processing method according to claim 1, wherein the second request includes a plurality of second sub-requests, and the second request is generated based on the task status information in the first operating environment, including: When the task status information indicates that the first task has not been completed, a first type of second sub-request is generated. The first type of second sub-request is used to trigger the continued execution of the next sub-task among the plurality of sub-tasks in the second running environment. When the task status information indicates that the first task has been completed, a second type of second sub-request is generated. The second type of second sub-request is used to obtain the execution result of the first task in the second running environment. Specifically, during the process of the first runtime environment responding to the second task, the execution context information of the first task is not lost in order to generate the plurality of second sub-requests.

6. The processing method according to claim 1, wherein the plurality of subtasks are obtained in the following manner: Select a first candidate operation that satisfies a first set condition from among multiple operations of the first task; Combine the first candidate operations into a first subtask; Determine the target parameters of a second candidate operation among the plurality of operations, excluding the first candidate operation; Based on the target parameters, the second candidate operations are grouped and combined to obtain the second sub-task; The first subtask and the second subtask are identified as multiple subtasks for implementing the first task.

7. The processing method according to claim 6, wherein selecting a first candidate operation satisfying a first preset condition from a plurality of operations of the first task includes at least one of the following: Select a first candidate operation from among the multiple operations of the first task whose runtime satisfies a first set duration threshold; Select a first candidate operation from among the multiple operations of the first task that is relevant to the target data that needs to be protected.

8. The processing method according to claim 6, wherein determining the target parameter of the second candidate operation other than the first candidate operation among the plurality of operations includes at least one of the following: Determine a first parameter for each second candidate operation other than the first candidate operation among the plurality of operations; the first parameter characterizes the runtime of the second candidate operation; Determine the second parameter of each second candidate operation among the plurality of operations, excluding the first candidate operation; The second parameter represents the computational complexity of the second candidate operation; The process of grouping and combining the second candidate operations based on the target parameters to obtain the second sub-task includes at least one of the following: Based on the first parameter, the corresponding second candidate operations are combined to obtain the second subtask; the cumulative value of the first parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the first parameter. Based on the second parameter, the corresponding second candidate operations are combined to obtain the second subtask; The cumulative value of the second parameter of the second candidate operation in the second subtask reaches the cumulative threshold of the second parameter.

9. A processing apparatus, comprising: The first switching module is used to respond to a first request from the first operating environment and send the first request to the second operating environment; The first request is used to request the second runtime environment to execute the first task; The first execution module is used to execute the first task in the second running environment, taking a single subtask from a plurality of subtasks as a unit; The multiple subtasks are used to implement the first task; Interruptions are prohibited during the execution of each of the subtasks in the second runtime environment; The second operating environment has higher security protection capabilities than the first operating environment; The generation module is used to generate task status information after each of the subtasks is completed; The task status information represents the execution progress of the first task; The return module is used to return the task status information to the first running environment, so that the first running environment can generate a second request based on the task status information and send it to the second running environment. The second request is used to execute the next subtask in the first task.

10. An electronic device comprising at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to perform the following method steps: In response to a first request from a first runtime environment, the first request is sent to a second runtime environment; the first request is used to request the second runtime environment to perform a first task. In the second operating environment, the first task is executed on a per-subtask basis, taking each subtask as an individual task among multiple subtasks; The multiple subtasks are used to implement the first task; Interruptions are prohibited during the execution of each of the subtasks in the second runtime environment; The second operating environment has higher security protection capabilities than the first operating environment; After each subtask is completed, task status information is generated and returned to the first runtime environment. Based on the task status information, a second request is generated in the first runtime environment and sent to the second runtime environment. The second request is used to execute the next subtask in the first task. The task status information represents the execution progress of the first task.

Images