Abnormal task handling methods, apparatus, computer equipment and storage media

Abstract

This application discloses a method, apparatus, computer device, and storage medium for handling abnormal tasks. The method includes: when a current task running in a non-security domain encounters an abnormality, triggering the system's security domain to analyze the abnormal task and determine its abnormality type; the abnormality type includes recoverable abnormalities and unrecoverable abnormalities; if the abnormality type is a recoverable abnormality, then correcting the abnormal task's data access address; if the abnormality type is an unrecoverable abnormality, then performing at least one of the following operations: task termination, memory release, and hardware resource cleanup. This method can improve the efficiency of handling abnormal tasks.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to an abnormal task handling method, apparatus, computer device, and storage medium. Background Technology

[0002] Embedded devices, such as Internet of Things (IoT) devices and vehicle controllers, often employ hardware security isolation technology (ARM TrustZone) to divide the execution environment into two physically isolated execution environments: a secure domain and a non-secure domain. The secure domain runs a trusted execution environment, secure monitoring modes, and security services to handle sensitive tasks such as encryption operations and biometric authentication; the non-secure domain runs a regular operating system (such as Android) and applications to handle everyday computing tasks.

[0003] When tasks running in non-safe domains encounter exceptions such as memory overflow or illegal instructions, a system-level reset is often triggered to clean up the exception tasks. However, this method of exception task cleanup results in long service interruptions and low efficiency in handling exception tasks. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide an abnormal task processing method, apparatus, computer device and storage medium that can improve the processing efficiency of abnormal tasks.

[0005] Firstly, this application provides an exception handling method applicable to systems including security domains and non-security domains. The method includes:

[0006] When an anomaly occurs in a current task running in a non-security domain, the system's security domain is triggered to analyze the anomaly task and determine its anomaly type; the anomaly type includes recoverable anomalies and unrecoverable anomalies.

[0007] If the exception type of the abnormal task is a recoverable exception, then the data access address of the abnormal task is corrected.

[0008] If the exception type of the abnormal task is an unrecoverable exception, then perform at least one of the following operations on the abnormal task: task termination, memory release, and hardware resource cleanup.

[0009] In conjunction with the first aspect, in one possible implementation, the abnormal task is analyzed to determine the abnormal type of the abnormal task, including: obtaining at least one of the function call information and memory information of the abnormal task; determining the abnormal type of the abnormal task based on the matching result between the function call information and the function call whitelist corresponding to the non-security domain; and / or, determining the abnormal type of the abnormal task based on the matching result between the memory information of the abnormal task and the memory boundary mapping table.

[0010] In conjunction with the first aspect, in one possible implementation, the exception type of the abnormal task is determined based on the matching result between the function call information and the function call whitelist corresponding to the non-security domain. This includes: if there is function call information in the function call information of the abnormal task that is different from the function in the function call whitelist, then it is determined that the function call information and the function call whitelist do not match, and the exception type of the abnormal task is an unrecoverable exception.

[0011] In conjunction with the first aspect, in one possible implementation, the memory information includes at least one of the execution instruction address of the process corresponding to the abnormal task and the data access address of the abnormal task. The exception type of the abnormal task is determined based on the matching result between the memory information of the abnormal task and the memory boundary mapping table, including: if the execution instruction address of the process corresponding to the abnormal task is not within the range of executable instruction addresses specified in the memory boundary mapping table, then the exception type of the abnormal task is determined to be an unrecoverable exception; if the data access address of the abnormal task is not within the range of data access addresses specified in the memory boundary mapping table, then the exception type of the abnormal task is determined to be a recoverable exception.

[0012] In conjunction with the first aspect, in one possible implementation, the data access address of the abnormal task is corrected, including: modifying the stack top address of the stack corresponding to the abnormal task to an address within the data access address range specified in the memory boundary mapping table.

[0013] In conjunction with the first aspect, in one possible implementation, at least one of the following operations is performed on the abnormal task: task termination, memory release, and hardware resource cleanup, including: stopping the scheduling state of the abnormal task and removing the abnormal task from the ready queue; and / or, traversing the system's task memory mapping table, finding and releasing the user memory and kernel memory corresponding to the abnormal task based on the identifier of the abnormal task; and / or, traversing the system's hardware resource list, finding and releasing the hardware resources occupied by the abnormal task based on the identifier of the abnormal task.

[0014] In conjunction with the first aspect, in one possible implementation, the exception handling method further includes: if the exception type of the exception task is a recoverable exception, then the data access address of the exception task is sent to the security domain, instructing the security domain to obtain the target data from the data access address, and returning the target data to the non-security domain.

[0015] Secondly, this application also provides an abnormal task handling apparatus. The apparatus includes:

[0016] The analysis module is used to trigger the system's security domain to analyze the abnormal task when an anomaly occurs in the current task running in the non-security domain, and to determine the anomaly type of the abnormal task; the anomaly type includes recoverable anomalies and unrecoverable anomalies;

[0017] The correction module is used to correct the data access address of the abnormal task if the exception type of the abnormal task is a recoverable exception.

[0018] The cleanup module is used to perform at least one of the following operations on the abnormal task if the exception type of the abnormal task is an unrecoverable exception: task termination, memory release, and hardware resource cleanup.

[0019] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method described in the first aspect.

[0020] Fourthly, this application also provides a computer-readable storage medium. This computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the method described in the first aspect.

[0021] Fifthly, this application also provides a computer program product. This computer program product includes a computer program that, when executed by a processor, implements the method described in the first aspect.

[0022] This application provides an abnormal task handling method, apparatus, computer device, and storage medium. When an abnormality occurs in a current task running in a non-security domain, the system's security domain is triggered to analyze the abnormal task and determine its abnormality type. If the abnormal task's abnormality type is recoverable, the data access address of the abnormal task is corrected. If the abnormal task's abnormality type is unrecoverable, at least one of the following operations is performed: task termination, memory release, and hardware resource cleanup. The method provided in this application classifies abnormal tasks in non-security domains into two abnormality types: recoverable and unrecoverable. For recoverable abnormalities, corresponding abnormality handling schemes are set; for unrecoverable abnormalities, corresponding task cleanup schemes are set. This allows the system to perform specific analysis on specific abnormal tasks and execute corresponding handling schemes without requiring system resets or interrupting the execution of other tasks, effectively improving the efficiency and accuracy of abnormal task handling. Attached Figure Description

[0023] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0024] Figure 1 This is a flowchart illustrating an abnormal task handling method in one embodiment;

[0025] Figure 2This is another flowchart illustrating the abnormal task handling method in one embodiment;

[0026] Figure 3 This is another flowchart illustrating the abnormal task handling method in one embodiment;

[0027] Figure 4 This is another flowchart illustrating the abnormal task handling method in one embodiment;

[0028] Figure 5 This is a structural block diagram of an exception handling device in one embodiment;

[0029] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0030] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0031] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0032] Embedded devices, such as IoT devices and vehicle controllers, often use ARM TrustZone to divide the execution environment into two physically isolated execution environments: a secure domain and a non-secure domain. The secure domain runs a trusted execution environment, security monitoring mode, and security services to handle sensitive tasks such as encryption operations and biometric authentication; the non-secure domain runs a regular operating system and applications to handle routine computing tasks.

[0033] When tasks running in non-safe domains encounter exceptions such as memory overflow or illegal instructions, a system-level reset is often triggered to clean up the abnormal tasks. However, this method of cleanup results in prolonged service interruptions and low efficiency in handling abnormal tasks. Furthermore, the system-level reset method also suffers from incomplete resource reclamation.

[0034] In addition, abnormal tasks are currently handled through data backup and administrator intervention via a public cloud platform to debug faulty programs. However, these methods still suffer from problems such as long system downtime and low processing efficiency.

[0035] Based on this, embodiments of this application provide an abnormal task handling method, applicable to systems including security domains and non-security domains, or applicable to devices that divide security domains and non-security domains, which can improve the processing efficiency of abnormal tasks. Figure 1 As shown, the method includes the following steps:

[0036] Step 101: When an anomaly occurs in the current task running in the non-security domain, the system's security domain is triggered to analyze the anomaly task and determine the anomaly type.

[0037] The exception types include recoverable exceptions and unrecoverable exceptions. To avoid system-level resets caused by abnormal tasks outside the security domain, this application's embodiments categorize abnormal tasks outside the security domain into recoverable and unrecoverable exception types. For recoverable exceptions, corresponding exception handling schemes are set; for unrecoverable exceptions, corresponding task clearing schemes are set. That is, specific abnormal tasks are analyzed and corresponding handling schemes are executed without requiring system resets or interrupting the execution of other tasks, thus improving the efficiency and accuracy of abnormal task handling.

[0038] In this embodiment, an anomaly analysis module can be set up in the security domain to handle abnormal tasks outside the security domain. When an anomaly occurs in the current task running in the non-security domain, the system directly jumps to the anomaly analysis module in the security domain, which analyzes the anomaly type of the abnormal task. Specifically, the system can pre-store the correspondence between multiple different abnormal tasks and anomaly types locally. That is, it pre-stores at least one anomaly situation corresponding to unrecoverable anomalies and at least one anomaly situation corresponding to recoverable anomalies.

[0039] The exception analysis module can obtain information such as register states, process execution, and memory access during the execution of an abnormal task, and then determine the specific exception situation based on this information. For example, it can determine whether the function calls of the abnormal task are compliant based on the register state information, and whether the memory addresses of the executed instructions and accessed data are within the specified memory area when the process corresponding to the abnormal task is executing. Finally, based on the exception situation of the abnormal task, it searches and determines the exception type corresponding to the abnormal task in the above correspondence.

[0040] Step 102: If the exception type of the abnormal task is a recoverable exception, then correct the data access address of the abnormal task.

[0041] In this embodiment of the application, after the anomaly analysis module of the security domain determines the anomaly type of the anomaly task, it can determine the corresponding processing plan for the anomaly type and execute or instruct the non-security domain to execute the corresponding processing plan.

[0042] For exceptions classified as recoverable exceptions, considering that these types of exceptions often occur because data access addresses during task execution exceed the compliant memory address range, task recovery can be achieved by correcting the task's data access addresses. Specifically, this can be done by modifying the address of the top of the exception task's stack to within the compliant memory address range, ensuring that subsequent data access addresses are also within the compliant memory address range, thereby achieving task recovery.

[0043] Step 103: If the exception type of the abnormal task is an unrecoverable exception, then perform at least one of the following operations on the abnormal task: task termination, memory release, and hardware resource cleanup.

[0044] In this embodiment, for an exception task with an unrecoverable exception type, the security domain can instruct the non-security domain to terminate the task scheduling of the exception task first. Then, the system's task memory mapping table is traversed, and the memory occupied during the execution of the exception task is found based on the task identifier of the exception task, and the memory is released; and the system's task hardware resource list is traversed, and the hardware resources used during the execution of the exception task are found based on the task identifier of the exception task, and the hardware resources are cleaned up. This achieves comprehensive exception cleanup operations for the exception task, realizes fine-grained and precise exception handling at the task level, avoids affecting the execution process of other tasks, does not require system reset, and reduces the processing time of the entire exception task from seconds to milliseconds, effectively improving the processing efficiency of exception tasks.

[0045] In one possible implementation, when the security domain determines that the abnormal task is an unrecoverable anomaly, it can send a cleanup command to the non-security domain through a secure channel established between the security domain and the non-security domain based on hardware isolation technology, instructing the non-security domain to perform at least one of the following operations on the abnormal task: task termination, memory release, and hardware resource cleanup.

[0046] In one possible implementation, the technical solution of this application can also be applied to a system based on the RISC-V architecture, and memory permissions can be managed based on the Physical Memory Protection (PMP) mechanism to implement the above-mentioned task exception handling scheme.

[0047] This application provides a method for handling abnormal tasks. When a current task running in a non-security domain encounters an exception, the system's security domain is triggered to analyze the abnormal task and determine its exception type. If the exception type is recoverable, the data access address of the abnormal task is corrected. If the exception type is unrecoverable, at least one of the following operations is performed: task termination, memory release, and hardware resource cleanup. The method provided in this application classifies abnormal tasks in non-security domains into two exception types: recoverable and unrecoverable. For recoverable exceptions, corresponding exception handling schemes are set; for unrecoverable exceptions, corresponding task cleanup schemes are set. This allows the system to analyze specific abnormal tasks and execute corresponding handling schemes without requiring system resets or interrupting the execution of other tasks, effectively improving the efficiency and accuracy of abnormal task handling.

[0048] The embodiments described above introduced a scheme for determining the exception type of an abnormal task. In another embodiment of this application, the abnormal situation of an abnormal task can be analyzed from both function call and memory perspectives. For example, the aforementioned "analyzing the abnormal task and determining the exception type of the abnormal task" may include, for example... Figure 2 The steps shown are as follows:

[0049] Step 201: Obtain at least one of the function call information and memory information of the abnormal task.

[0050] In this embodiment, after an abnormal task in a non-security domain triggers the exception analysis module in the security domain, the exception analysis module can obtain the register information corresponding to the abnormal task. For example, it can obtain the program counter (PC) information to obtain the memory address of the next instruction to be fetched from memory and executed by the processor; it can obtain the stack pointer (SP) information to obtain the address of the stack top corresponding to the abnormal task in memory; and it can obtain the current program status register (CPSR) information to obtain key information about the current execution state of the abnormal task, such as the result of the previous arithmetic or logical operation, and the current processor's running privileges / mode.

[0051] The exception analysis module can synthesize the memory information from the register information to obtain the memory information corresponding to the exception task. The task's memory information may include the instruction address of the process executing the task, as well as the data access address during task execution. Therefore, obtaining the memory information of the exception task from the register information can include at least one of the execution instruction address of the process corresponding to the exception task and the data access address of the exception task.

[0052] Regarding function call information, the exception analysis module can extract the instruction information of the exception task from the aforementioned register information, and then extract function call information from the instruction information to obtain the initial function call information of the exception task. Next, based on the initial function call information, the function call chain is traced back to determine all function information called during the execution of the exception task, thus obtaining the function call information of the exception task.

[0053] Step 202: Determine the exception type of the abnormal task based on the matching results between the function call information and the function call whitelist corresponding to the non-security domain.

[0054] In this embodiment, the system specifies the functions that tasks running in non-security domains can call, i.e., a function call whitelist corresponding to the non-security domain. Therefore, the function call information of abnormal tasks can be matched with the function call whitelist to determine whether the function calls of abnormal tasks are compliant, thereby determining whether abnormal tasks have function call anomalies.

[0055] In one embodiment, if the function call information of an abnormal task contains function call information that is different from the function call whitelist, then it is determined that the function call information and the function call whitelist do not match, and the exception type of the abnormal task is an unrecoverable exception.

[0056] Specifically, for any function in the function call information of an abnormal task, a match is made in the function call whitelist based on the function identifier. If no function matching the function is found in the function call whitelist, it is determined that the function call information of the abnormal task does not match the function call whitelist, and the abnormal task is determined to have a function call abnormality.

[0057] Only when all functions in the function call information are in the function call whitelist can it be determined that the function call information of the abnormal task matches the function call whitelist, thus confirming that the abnormal task does not have a function call exception.

[0058] When the exception condition of an abnormal task is a function call exception, the exception type of the abnormal task is determined to be an unrecoverable exception.

[0059] Step 203: Determine the exception type of the exception task based on the matching result between the memory information of the exception task and the memory boundary mapping table.

[0060] The memory boundary mapping table manages the boundaries of different memory regions, such as the code segment (.text), data segment (.data), heap (.heap), and stack (.stack), thus defining the memory access permissions for a task. Specifically, the code segment (.text) stores the program's executable machine instructions; the data segment (.data) stores initialized global and static variables; the heap (.heap) stores dynamically allocated memory during program execution; and the stack (.stack) stores local variables, function parameters, and return values.

[0061] In this embodiment of the application, the memory information of the abnormal task can be matched with the memory access permissions specified in the memory boundary mapping table to determine whether the memory access of the abnormal task complies with the permissions, thereby determining whether there is a memory access abnormality in the abnormal task.

[0062] The memory information of an abnormal task includes at least one of the execution instruction address of the process corresponding to the abnormal task and the data access address of the abnormal task; correspondingly, the memory boundary mapping table defines the range of executable instruction addresses (e.g., code segment, heap area, stack area) and the range of data access addresses (e.g., data segment) of the task through different memory region boundaries.

[0063] In one possible implementation, if the memory information includes the execution instruction address of the process corresponding to the abnormal task, and the execution instruction address of the process corresponding to the abnormal task is not within the range of executable instruction addresses specified in the memory boundary mapping table, then the abnormal type of the abnormal task is determined to be an unrecoverable abnormality.

[0064] In this implementation, if the execution instruction address of the process corresponding to the abnormal task is not within the range of executable instruction addresses specified in the memory boundary mapping table, it indicates that there is an instruction execution error during the execution of the abnormal task, which cannot be recovered. Therefore, the abnormal type of the abnormal task is determined to be an unrecoverable exception.

[0065] In one possible implementation, if the memory information includes the data access address of the abnormal task, and the data access address of the abnormal task is not within the data access address range specified in the memory boundary mapping table, then the abnormal type of the abnormal task is determined to be a recoverable abnormality.

[0066] In this implementation, if the data access address of the abnormal task is not within the data access address range specified in the memory boundary mapping table, it means that the data access of the abnormal task exceeds the permission. The data access address of the abnormal task can be corrected by modifying the stack top address. Therefore, the exception type of the abnormal task is determined to be a recoverable exception.

[0067] In one possible implementation, if the anomaly of the abnormal task analyzed by the anomaly analysis module of the security domain does not fall under the categories of function call anomalies, memory access anomalies, etc., as described above, then the specific anomaly of the abnormal task can be recorded and specifically recorded in at least one anomaly corresponding to an unrecoverable anomaly (i.e., the correspondence between multiple different abnormal tasks and anomaly types). If a subsequent abnormal task matches this anomaly, then the abnormal task can be processed using the cleanup handling method corresponding to the unrecoverable anomaly.

[0068] The method provided in this application can obtain at least one of the function call information and memory information of an abnormal task. The exception type of the abnormal task is determined based on the matching result between the function call information and the function call whitelist corresponding to the non-security domain. The exception type of the abnormal task is also determined based on the matching result between the memory information of the abnormal task and the memory boundary mapping table. This application embodiment can analyze the specific exception situation of the abnormal task based on its specific information, thereby determining the exception type of the abnormal task, so as to facilitate the subsequent execution of the corresponding processing plan for the abnormal task, achieving fine-grained and precise exception handling at the task level, and improving the processing efficiency and accuracy of abnormal tasks.

[0069] The embodiments described above illustrate that for recoverable abnormal tasks, recovery processing can be achieved by correcting the data access addresses of the abnormal task. For example, the "correction of the data access addresses of the abnormal task" mentioned above may include the following steps:

[0070] Modify the stack top address of the stack corresponding to the abnormal task to an address within the data access address range specified in the memory boundary mapping table.

[0071] In this embodiment, the top address of the stack corresponding to the abnormal task can be modified by either the Memory Management Unit (MMU) or the Memory Protection Unit (MPU) to any address within the data access address range specified in the memory boundary mapping table. This ensures the compliance of data access for the abnormal task and completes the abnormal recovery process.

[0072] In one possible implementation, if the exception type of the exception task is a recoverable exception, the data access address of the exception task is sent to the security domain, instructing the security domain to obtain the target data from the data access address and return the target data to the non-security domain.

[0073] In this implementation, task exceptions caused by accessing memory addresses outside the permissions of the non-security domain can be handled or avoided through security domain proxy access. Specifically, when the exception type of the exception task is a recoverable exception, the non-security domain can send the data access address of the exception task to the security domain, allowing the security domain with the necessary permissions to access the data access address, retrieve the data, and return the retrieved data to the non-security domain. This prevents the non-security domain from accessing memory addresses outside its permissions, thus completing the exception recovery process for the exception task.

[0074] Alternatively, the compliance of data access for non-secure domain tasks can be checked in real time before an anomaly occurs. If a data access address is detected to be outside the corresponding data access address range, the data access address is sent to the secure domain so that the secure domain with the necessary permissions can access the data access address to obtain the data and then send the obtained data to the non-secure domain, thus preventing the non-secure domain task from becoming abnormal.

[0075] The method provided in this application can modify the stack top address of the stack corresponding to the abnormal task to an address within the data access address range specified in the memory boundary mapping table. That is, this application can provide corresponding exception handling methods for specific abnormal situations of abnormal tasks. Specifically, for recoverable abnormal tasks, a pre-set processing scheme can be used to recover the abnormal task without requiring a system reset, effectively improving the processing efficiency of abnormal tasks.

[0076] The embodiments described above illustrate how to perform task cleanup operations on unrecoverable abnormal tasks. For example, the aforementioned "performing at least one of the following operations on abnormal tasks: task termination, memory release, and hardware resource cleanup" may include, for instance, tasks that are not recoverable. Figure 3 The steps shown are as follows:

[0077] Step 301: Stop the scheduling state of the abnormal task and remove the abnormal task from the ready queue; and / or,

[0078] Step 302: Traverse the system's task memory mapping table, locate and release the user memory and kernel memory corresponding to the abnormal task based on the abnormal task's identifier; and / or,

[0079] Step 303: Traverse the system's hardware resource list, find and release the hardware resources occupied by the abnormal task based on the identifier of the abnormal task.

[0080] In this embodiment of the application, for unrecoverable abnormal tasks, the scheduler can first adjust the process state of the abnormal task to interrupt its execution. Then, the abnormal task is removed from the ready queue, thus clearing the task itself.

[0081] Next, regarding the memory occupied during the execution of abnormal tasks, the system's task memory mapping table used to store task data can be traversed, and the user memory and kernel memory where the task data corresponding to the abnormal task is located can be found based on the identifier of the abnormal task, and the data in user memory and kernel memory can be released.

[0082] Furthermore, regarding the hardware resources used during the execution of abnormal tasks, the task hardware resource list used to store tasks in the system can be traversed, and the hardware resources used by the abnormal task can be found based on the identifier of the abnormal task, such as port mapping, Direct Memory Access (DMA) channel occupation, etc., and the hardware resources used by the abnormal task can be released.

[0083] The method provided in this application addresses unrecoverable abnormal tasks by removing the task, releasing memory, and freeing hardware resources to completely eliminate information related to the abnormal task. This avoids security risks such as memory leaks and hardware resource occupation caused by resource residue, effectively improving the security and reliability of the system.

[0084] like Figure 4 As shown, an abnormal task handling method is provided. When an abnormality occurs in a business process (task) outside the security domain, the security domain analysis engine (the abnormality analysis module of the non-security domain) is triggered to analyze the abnormal task and determine whether it is a recoverable abnormality. If the abnormal task is a recoverable abnormality, the task abnormality is repaired by correcting the stack top address, and after the abnormality repair is completed, execution jumps back to the point where the abnormality was triggered in the business process to continue. If the abnormal task is an unrecoverable abnormality, a cleanup command is issued to the non-security domain, instructing the non-security domain (task cleanup device) to perform cleanup operations on the process resources (memory and hardware resources) of the abnormal task.

[0085] It should be noted that although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0086] In one embodiment, such as Figure 5 As shown, an abnormal task processing device is provided, including: an analysis module 401, a correction module 402, and a cleanup module 403, wherein:

[0087] Analysis module 401 is used to trigger the system's security domain to analyze the abnormal task when an abnormality occurs in the current task running in the non-security domain, and to determine the abnormality type of the abnormal task; the abnormality type includes recoverable abnormality and unrecoverable abnormality.

[0088] The correction module 402 is used to correct the data access address of the abnormal task if the abnormal type of the abnormal task is a recoverable abnormality.

[0089] The cleanup module 403 is used to perform at least one of the following operations on the abnormal task if the exception type of the abnormal task is an unrecoverable exception: task termination, memory release, and hardware resource cleanup.

[0090] In one embodiment, the analysis module 401 is specifically used to obtain at least one of the function call information and memory information of the abnormal task; determine the abnormal type of the abnormal task based on the matching result between the function call information and the function call whitelist corresponding to the non-security domain; and / or determine the abnormal type of the abnormal task based on the matching result between the memory information of the abnormal task and the memory boundary mapping table.

[0091] In one embodiment, the analysis module 401 is further configured to determine that the function call information and the function call whitelist do not match if there is function call information in the function call information of the abnormal task that is different from the function call whitelist, and the abnormal type of the abnormal task is an unrecoverable abnormality.

[0092] In one embodiment, the memory information includes at least one of the execution instruction address of the process corresponding to the abnormal task and the data access address of the abnormal task. The analysis module 401 is further configured to determine the abnormal type of the abnormal task as an unrecoverable abnormal if the execution instruction address of the process corresponding to the abnormal task is not within the range of executable instruction addresses specified in the memory boundary mapping table; and to determine the abnormal type of the abnormal task as a recoverable abnormal if the data access address of the abnormal task is not within the range of data access addresses specified in the memory boundary mapping table.

[0093] In one embodiment, the correction module 402 is specifically used to modify the stack top address of the stack corresponding to the abnormal task to an address within the data access address range specified in the memory boundary mapping table.

[0094] In one embodiment, the cleanup module 403 is specifically used to stop the scheduling state of the abnormal task and remove the abnormal task from the ready queue; and / or, traverse the system's task memory mapping table, find and release the user memory and kernel memory corresponding to the abnormal task according to the identifier of the abnormal task; and / or, traverse the system's hardware resource list, find and release the hardware resources occupied by the abnormal task according to the identifier of the abnormal task.

[0095] In one embodiment, the abnormal task processing device further includes an access module, which, if the abnormal task's abnormality type is a recoverable abnormality, sends the abnormal task's data access address to the security domain, instructs the security domain to obtain the target data from the data access address, and returns the target data to the non-security domain.

[0096] It should be understood that the units or modules described in the abnormal task handling device are related to the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations and features described above for the method also apply to the exception task handling device and the units contained therein, and will not be repeated here. The exception task handling device can be pre-implemented in the browser or other security applications of an electronic device, or it can be loaded into the browser or its security applications of an electronic device through download or other means. The corresponding units in the exception task handling device can cooperate with the units in the electronic device to implement the solutions of the embodiments of this application.

[0097] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 500 suitable for implementing terminal devices or servers in the embodiments of this application.

[0098] like Figure 6 As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the system 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0099] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.

[0100] In particular, according to embodiments of this disclosure, the above references Figure 1The described process can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing instructions for performing... Figure 1 The program code for the method. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable media 511.

[0101] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0102] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0103] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0104] On the other hand, this application also provides a computer-readable storage medium, which may be included in the computer device described in the above embodiments, or may exist independently and not assembled into the computer device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figures 1-4 The steps of the method shown are as follows.

[0105] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figures 1-4 The steps of the method shown are as follows.

[0106] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0107] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. An abnormal task processing method characterized by comprising: The method is applied to an operating system including a secure domain and a non-secure domain, and comprises: When a current task running in the non-secure domain is abnormal, jumping to an exception analysis module in the secure domain of the operating system to obtain at least one of function call information and memory information of the abnormal task; determining an exception type of the abnormal task according to a matching result between the function call information and a function call whitelist corresponding to the non-secure domain; and / or determining the exception type of the abnormal task according to a matching result between the memory information of the abnormal task and a memory boundary mapping table; the exception type includes a recoverable exception and an unrecoverable exception; If the exception type of the abnormal task is the recoverable exception, correcting a data access address of the abnormal task; If the exception type of the abnormal task is the unrecoverable exception, performing at least one of task termination, memory release and hardware resource cleaning on the abnormal task.

2. The method of claim 1, wherein, The determination of the exception type of the abnormal task according to the matching result between the function call information and the function call whitelist corresponding to the non-secure domain comprises: If there is function call information different from functions in the function call whitelist in the function call information of the abnormal task, it is determined that the function call information and the function call whitelist do not match, and the exception type of the abnormal task is the unrecoverable exception.

3. The method of claim 1, wherein, The memory information includes at least one of an execution instruction address of a process corresponding to the abnormal task and a data access address of the abnormal task, and the determination of the exception type of the abnormal task according to the matching result between the memory information of the abnormal task and the memory boundary mapping table comprises: If the execution instruction address of the process corresponding to the abnormal task is not in an executable instruction address range defined in the memory boundary mapping table, it is determined that the exception type of the abnormal task is the unrecoverable exception; If the data access address of the abnormal task is not in a data access address range defined in the memory boundary mapping table, it is determined that the exception type of the abnormal task is the recoverable exception.

4. The method according to any one of claims 1 to 3, characterized in that, The correction of the data access address of the abnormal task comprises: Modifying a stack top address of a stack corresponding to the abnormal task to an address in the data access address range defined in the memory boundary mapping table.

5. The method according to any one of claims 1 to 3, characterized in that, The at least one of task termination, memory release and hardware resource cleaning on the abnormal task comprises: Stopping a scheduling state of the abnormal task, and removing the abnormal task from a ready queue; and / or, Traversing a task memory mapping table of the operating system, and finding and releasing user memory and kernel memory corresponding to the abnormal task according to an identifier of the abnormal task; and / or, Traversing a hardware resource list of the operating system, and finding and releasing hardware resources occupied by the abnormal task according to the identifier of the abnormal task.

6. The method of claim 1, wherein, The method further comprises: If the exception type of the exception task is a recoverable exception, the data access address of the exception task is sent to the secure domain, the secure domain is instructed to obtain target data from the data access address, and the target data is returned to the non-secure domain.

7. An abnormal task processing apparatus characterized by comprising: The apparatus comprises: an analysis module configured to, when a current task running in a non-secure domain of an operating system is abnormal, jump to an exception analysis module in a secure domain of the operating system to obtain at least one of function call information and memory information of the exception task, determine an exception type of the exception task according to a matching result between the function call information and a function call white list corresponding to the non-secure domain, and / or determine the exception type of the exception task according to a matching result between the memory information of the exception task and a memory boundary mapping table, wherein the exception type comprises a recoverable exception and an unrecoverable exception; a correction module configured to, if the exception type of the exception task is a recoverable exception, correct a data access address of the exception task; a cleaning module configured to, if the exception type of the exception task is an unrecoverable exception, perform at least one of task termination, memory release, and hardware resource cleaning on the exception task.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 5.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 5.

Images