Virtualization-based dual-domain security fault handling method, device, equipment and medium
By constructing kernel module dependency trees in both secure and non-secure virtual machine architectures and performing fault degradation processing, the system instability caused by virtual machine module crashes is resolved, enabling fine-grained fault management and secure resource reclamation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KYLIN CORP
- Filing Date
- 2026-03-27
- Publication Date
- 2026-06-09
AI Technical Summary
In a multi-tenant virtualization environment, when a virtual machine module crashes, the impact of the failure can easily spread, leading to system instability. Existing detection and recovery mechanisms lack specificity and accuracy, resulting in a high risk of resource leakage.
By deploying virtual machines in both the security and non-security domains, a kernel module dependency tree is constructed to obtain resource usage information, perform fault degradation assessment and decision-making, terminate related processes, unload faulty modules and release resources, and record the processing results to report to the user layer.
It enables adaptive assessment and refined handling of module crashes in a virtualized environment, limiting the scope of the failure's impact and improving operational stability and observability.
Smart Images
Figure CN122173324A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of virtual system fault handling technology, and in particular to a method, apparatus, device and medium for handling dual-domain security faults based on virtualization. Background Technology
[0002] In systems with high security requirements, such as industrial control, aerospace, and financial systems, there are often two independent systems to handle different security tasks, or two complementary security technologies used within the same system. Currently, this is mainly achieved through Trusted Execution Environments (TEEs). The platform divides the system into a Secure World and a Normal World at the hardware layer. This separation is usually natively supported by the processor, ensuring isolation and the principle of least privilege between the two domains through hardware. Alternatively, virtualization can be used for multi-domain isolation, such as ARM CCA (Confidential Compute) or the research project virtCCA. VirtCCA introduces true virtualization support on top of TrustZone, allowing multiple secure virtual machines to coexist with ordinary virtual machines while maintaining key isolation.
[0003] However, in a single operating system environment, the impact of a crashed module often spreads to the entire system, leading to unrecoverable consequences. In a multi-tenant virtualization environment, multiple virtual machines typically share hardware resources. If a module in a virtual machine crashes and is not handled promptly and effectively, the impact of the crash often spreads to the entire virtual machine or virtualization environment, and may even affect the physical host machine, causing instability to the entire system.
[0004] Fault detection typically relies on static monitoring tools, which cannot perform intelligent analysis and judgment based on the type, priority, and resource dependencies of the crashed module. This is especially problematic in complex environments involving multiple virtual machines and containers. The failure to fully consider the interrelationships between modules and the state of other modules and resources within the virtualization platform at the time of the failure leads to simplistic processes like process termination or system crashes, resulting in a lack of targeted and precise post-fault response. Furthermore, resource reclamation and recovery mechanisms often depend on manual operation or post-incident recovery, which can easily lead to system resource leaks. In severe cases, this can cause abnormal resource allocation across the entire virtualization platform, affecting the operation of other virtual machines and ultimately leading to platform crashes or the leakage of critical data. Summary of the Invention
[0005] This invention provides a virtualization-based dual-domain security fault handling method, apparatus, device, and medium to solve the technical problem of how to accurately and timely handle module crash faults in a virtualized environment with multiple virtual machines.
[0006] In a first aspect, embodiments of the present invention provide a virtualization-based dual-domain security fault handling method, including: S101, deploy secure virtual machines and insecure virtual machines in the secure domain and insecure domain respectively, construct the kernel module dependency tree of the insecure virtual machine in the secure virtual machine according to the kernel module dependency chain, and obtain the resource usage information of each kernel module of the insecure virtual machine. S102, In response to a kernel module crash in an insecure virtual machine, the secure virtual machine performs a fault degradation assessment on the crashed kernel module based on the kernel module dependency tree and the resource usage information of each kernel module, and decides whether to perform fault handling degradation operation. S103, in response to the decision, the fault handling degradation operation, the security virtual machine attempts to clean up system resources of the faulty kernel module based on the kernel module dependency tree and the resource usage information of each kernel module, terminates the process related to the faulty kernel module, unloads the faulty kernel module, and releases the system resources occupied by the faulty kernel module. S104, collect the evaluation decision results and complete operation records of the fault handling degradation operation and report them to the user level.
[0007] Secondly, embodiments of the present invention provide a virtualization-based dual-domain security fault handling device, comprising: The dual-domain building module is used to deploy secure virtual machines and insecure virtual machines respectively in the secure domain and insecure domain, and to build the kernel module dependency tree of the insecure virtual machine in the secure virtual machine, and obtain the resource usage information of each kernel module of the insecure virtual machine. The fault degradation assessment module is used to respond to kernel module crashes in non-secure virtual machines. It attempts to clean up system resources for the kernel module that has crashed, in order to assess the fault degradation and decide whether to perform fault handling degradation operations. The fault handling degradation module is used to respond to fault handling degradation operations, terminate the processes related to the faulty kernel module, unload the faulty kernel module, and release the system resources occupied by the faulty kernel module. The information reporting module is used to collect the evaluation and decision results of fault handling degradation operations and complete operation records and report them to the user level.
[0008] Thirdly, embodiments of the present invention provide an electronic device, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the above-described virtualization-based dual-domain security fault handling method.
[0009] Fourthly, embodiments of the present invention provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the aforementioned virtualization-based dual-domain security fault handling method.
[0010] This invention provides a method, apparatus, device, and medium for handling dual-domain security faults based on virtualization. The method constructs a secure virtual machine based on a virtualization dual-domain security architecture to monitor and manage insecure virtual machines. It forms a kernel module dependency tree for the insecure virtual machines and obtains resource usage information for each module. When a kernel module failure occurs, it evaluates and decides on fault degradation processing operations based on dependencies and resource information. For kernel crash failures that meet the conditions, it performs process termination, module unloading, and resource release degradation processing, and reports the complete processing record to the user layer. This achieves adaptive assessment and refined processing of kernel module crash failures in a virtualization environment, limiting the impact of module crash failures to a minimum, avoiding kernel panic or overall system crashes caused by a single module failure, improving the operational stability of the virtualization platform. Simultaneously, recording and reporting complete processing records provides users with a reference for fault analysis, improving the observability and maintainability of the virtualization platform. Attached Figure Description
[0011] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart of a virtualization-based dual-domain security fault handling method according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of a virtualization-based dual-domain security fault handling method according to Embodiment 2 of the present invention; Figure 3 This is a diagram of the fault handling architecture for virtualized dual-domain security described in the second invention. Figure 4 This is a flowchart of a virtualization-based dual-domain security fault handling method according to Embodiment 3 of the present invention; Figure 5 This is a schematic diagram of the structure of a virtualization-based dual-domain security fault handling device according to Embodiment 4 of the present invention; Figure 6 This is a structural diagram of the electronic device described in Embodiment 5 of the present invention. Detailed Implementation
[0012] The present invention 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, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.
[0013] Example 1 Figure 1 The flowchart below illustrates a virtualization-based dual-domain security fault handling method according to Embodiment 1 of the present invention. It involves dividing the physical hardware into security and non-security domains and deploying secure and non-secure virtual machines accordingly. Based on bidirectional isolation, the method utilizes the higher-privilege secure virtual machine to perform downgrade processing on kernel module crashes of the non-secure virtual machine, thereby reducing the impact of the faulty kernel module. Specifically, the method includes the following steps: S101, deploy secure virtual machines and insecure virtual machines in the secure domain and insecure domain respectively, construct the kernel module dependency tree of the insecure virtual machine in the secure virtual machine according to the kernel module dependency chain, and obtain the resource usage information of each kernel module of the insecure virtual machine.
[0014] Leveraging hardware architecture support, a virtualized dual-domain security architecture can be built on the hardware platform. For example, based on the ARM64 architecture, virtualization extension technologies such as ARM TrustZone or ARM CCA can be used to divide the physical hardware into security and non-security domains. Accordingly, secure virtual machines (VMs) are deployed in the security domain, and partially secure VMs are deployed in the non-security domain. The secure VMs should have higher privileges, able to access and obtain the system status information of the non-security VMs through their system interfaces, but the non-security VMs cannot access any data within the security domain, including that of the secure VMs, thus achieving bidirectional isolation at the physical layer. For example, the secure VMs can periodically read the ` / proc / modules` and ` / sys / module / ` files of the non-security VMs through system interfaces exposed by the non-security VMs, such as shared memory channels or hypercall interfaces provided by the virtualization platform. <mod>The ` / holders / ` directory information is used to obtain a list of all kernel modules loaded in the insecure virtual machine, and the reference relationships between modules (including forward and reverse dependencies), thus constructing a kernel module dependency tree. During initialization or runtime, each kernel module in the insecure virtual machine registers its occupied system resource handles with the secure virtual machine, including: interrupt queuing (IRQ), timers, work queues, DMA buffers, locks, memory barriers, file descriptors, network connections, etc.
[0015] S102, in response to a kernel module crash in an insecure virtual machine, the secure virtual machine performs a fault degradation assessment on the crashed kernel module based on the kernel module dependency tree and the resource usage information of each kernel module, and decides whether to perform fault handling degradation operation.
[0016] When a kernel module in a non-secure virtual machine crashes, the secure virtual machine immediately initiates a fault degradation assessment process based on the received fault report. First, it analyzes the dependencies of the failed kernel module using the kernel module dependency tree to assess the potential chain reactions of uninstalling that module. Then, based on the resource usage information of each kernel module, the secure virtual machine assesses whether degrading that module will result in unremovable system resources, unremovable references, or affect related modules and global resources. It checks whether each system resource it occupies can be safely released to avoid instability caused by the degradation process. If all conditions are met, the degradation process is deemed acceptable, and the fault degradation operation is allowed. If some system resources cannot be removed, some references cannot be removed, or related modules and global resources are affected, the assessment decision is that degradation is not allowed, and a kernel panic will be triggered in the traditional manner.
[0017] It should be noted that insecure virtual machines are mainly used for the deployment of conventional operating systems, including a large number of applications and drivers, and therefore have a wider exposure to module crashes. In contrast, secure virtual machines are small operating systems running in memory, containing very few applications, drivers, and even hardware. Therefore, their exposure to module crashes is much smaller than that of insecure virtual machines, resulting in a very low failure rate. Thus, they can be specifically used in the dual-domain architecture of this embodiment to handle kernel module crashes of insecure virtual machines, thereby reducing the impact of module failures.
[0018] S103, in response to the decision, the fault handling degradation operation, the security virtual machine attempts to clean up system resources of the faulty kernel module based on the kernel module dependency tree and the resource usage information of each kernel module, terminates the process related to the faulty kernel module, unloads the faulty kernel module, and releases the system resources occupied by the faulty kernel module.
[0019] When an assessment determines that a fault handling degradation operation is permitted, the secure virtual machine issues a fault handling instruction to the insecure virtual machine, initiating the degradation process. The secure virtual machine first identifies all processes that call or depend on the faulty kernel module based on the kernel module dependency tree and sends termination signals to these processes. During process termination, the state of each process is checked. Processes in an interruptible state can gracefully exit by sending a SIGTERM signal, allowing them to clean up their resources. For processes in an uninterruptible state (TASK_UNINTERRUPTIBLE), the kernel module unload function can be called to forcibly unload the faulty module. After unloading, all system resources occupied by the faulty kernel module need to be released one by one according to the previously registered resource usage information. After all relevant processes have finished processing, reference counts are adjusted to release references from other kernel modules to the faulty module.
[0020] S104, collect the evaluation decision results and complete operation records of the fault handling degradation operation and report them to the user level.
[0021] After completing the fault handling and degradation operation of the faulty kernel module, a complete log needs to be collected for user-level reference and analysis. The collected information includes: fault assessment decision results (whether degradation is allowed), a complete fault handling and degradation operation log (process processing status, module unloading status, resource release status, etc.), resource cleanup status, and information on resources marked as contaminated. This information can be reported to the user-space management component or operations and maintenance platform via a predefined subscription / publishing mechanism for system administrators to view and analyze. The user level can understand the virtualization platform's operational status based on the reported information and intervene manually when necessary.
[0022] This embodiment monitors and manages insecure virtual machines by constructing secure virtual machines based on a virtualization dual-domain security architecture. It forms a kernel module dependency tree for the insecure virtual machines and obtains resource usage information for each module. When a kernel module failure occurs, it evaluates and decides on failure degradation processing operations based on dependencies and resource information. For kernel crash failures that meet the conditions, it performs degradation processing such as process termination, module unloading, and resource release, and reports the complete processing record to the user layer. This achieves adaptive assessment and refined processing of kernel module crash failures in a virtualization environment, limiting the impact of module crash failures to a minimum, avoiding kernel panic or overall system crash caused by a single module failure, improving the operational stability of the virtualization platform. Simultaneously, recording and reporting complete processing records provides users with a reference for fault analysis, improving the observability and maintainability of the virtualization platform.
[0023] Example 2 Figure 2 This is a flowchart of a virtualization-based dual-domain security fault handling method according to Embodiment 2 of the present invention. This embodiment is based on the above embodiment and optimized. In this embodiment, S102 is specifically optimized as follows: When a kernel module of a non-secure virtual machine crashes, access data to the faulty kernel module is intercepted, and a fault degradation assessment is triggered. The secure virtual machine attempts to clean up system resources based on the kernel module dependency tree and the resource usage information of each kernel module. If the cleanup is successful, it allows for fault handling and degradation operations. If the cleanup of some system resources fails, the system resources that failed to be cleaned up are marked as polluted and the resource pollution information is recorded.
[0024] Accordingly, the virtualization-based dual-domain security fault handling method provided in this embodiment specifically includes: S201. Deploy secure virtual machines and insecure virtual machines in the secure domain and insecure domain respectively. Based on the kernel module dependency chain, construct the kernel module dependency tree of the insecure virtual machine in the secure virtual machine and obtain the resource usage information of each kernel module of the insecure virtual machine.
[0025] Specifically, a secure domain and a non-secure domain are constructed based on ARM64 architecture hardware. A secure virtual machine is deployed in the secure domain, and a non-secure virtual machine is deployed in the non-secure domain. The secure virtual machine can read the kernel module list and module reference relationship of the non-secure virtual machine through the system interface of the non-secure virtual machine, and construct a kernel module dependency relationship tree. When the kernel modules of the non-secure virtual machine are initialized or running, they will register the system resource handles they occupy with the secure virtual machine.
[0026] A dual-domain security architecture, including a secure domain and a non-secure domain, can be implemented on an ARM64 architecture hardware platform. For example, during system startup, the physical hardware is divided into secure and non-secure domains using ARM TrustZone, or virtualization layer support is introduced through ARM CCA (Confidential Compute Architecture). Then, a secure virtual machine (Secure VM) is deployed in the secure domain, containing a security-hardened operating system kernel responsible only for critical tasks such as security management, key storage, and fault monitoring. One or more non-secure virtual machines (NormalVMs) are deployed in the non-secure domain to run ordinary business applications. Secure and non-secure virtual machines interact through a secure communication channel provided by the hypervisor, ensuring that data can only be read by the secure virtual machine, and that non-secure virtual machines cannot access the secure domain in reverse. Figure 3 The diagram shown is a fault handling architecture diagram for virtualized dual-domain security.
[0027] The secure virtual machine periodically sends kernel module information query requests to the insecure virtual machine through a predefined communication interface. The insecure virtual machine kernel responds to the request by returning the contents of the ` / proc / modules` file and ` / sys / modules`. <mod>The ` / holders / ` directory contains module dependency information. Specifically, ` / proc / modules` provides all currently loaded kernel modules and their reference counts; the `used_by_list` field can be used to determine which modules are using the current module (reverse dependency); ` / sys / module / ` <mod>The subdirectories under the / holders / directory directly identify the holder modules (modules that depend on the current kernel module). After receiving this information, the security virtual machine can build a kernel module dependency tree locally, which includes forward and reverse dependencies.
[0028] During the initialization phase, each kernel module in the non-secure virtual machine actively registers its occupied system resource handles with the secure virtual machine through the communication protocol between the kernel module and the secure virtual machine. For example, taking the interrupt number IRQ as an example, after the module calls `request_irq()` to register the interrupt handler function, it sends a registration message to the secure virtual machine through the secure communication channel. The message content includes the interrupt number IRQ, whether the interrupt is shared, the device pointer `dev_id`, MSI / MSI-X information, and the corresponding hardware mask register address. For other types of resources, such as timers, the kernel module registers the timer object pointer and timeout handler function; for work queues, it registers the work queue handle; and for DMA buffers, it registers the buffer address and size. The secure virtual machine can maintain a resource usage table for each kernel module in the non-secure virtual machine based on the registered handles, providing a data foundation for subsequent fault degradation handling assessment.
[0029] Set up status monitoring and exception event capture points at the kernel exception function entry points of non-secure virtual machines to capture kernel module crash failure information and report it to secure virtual machines.
[0030] To promptly capture kernel faults, status monitoring and exception event capture points are set at the entry points of kernel exception functions in the non-secure virtual machine. These points are used to trigger evaluation and decisions for fault degradation handling operations, ensuring that the fault does not directly cause the entire system to crash before initiating the kernel panic process. For example, in the exception vector table of the ARM64 architecture, for exception types that may cause kernel crashes, such as null pointer dereference, data abort, instruction abort, and alignment errors, hook functions are inserted before entering the kernel panic process. These hook functions collect fault information such as CPU state, fault address, and fault module information at the time of the exception, and report the fault module identifier, fault type, and context information at the time of the fault to the secure virtual machine through a secure channel.
[0031] S202: When a kernel module of a non-secure virtual machine crashes, access data to the faulty kernel module is intercepted, and a fault degradation assessment is triggered.
[0032] When a kernel module of a non-secure virtual machine crashes, the aforementioned interception point is triggered, collecting fault information at the time of the exception and reporting it to the secure virtual machine. At this point, to prevent the impact of the fault from escalating, subsequent access data to the faulty kernel module needs to be intercepted to prevent processes from calling the faulty kernel module again, which could cause wider blocking, interruptions, suspensions, or even crashes. Simultaneously, a fault degradation assessment is triggered, using the reported information to analyze whether fault handling and degradation operations can be performed on the faulty kernel module.
[0033] Optionally, a trusted module whitelist can be established in the secure virtual machine to record the identifiers, hash values, and available resource information of kernel modules that are allowed to perform fault handling degradation operations. This whitelist is used to query and compare whether the faulty kernel module is a trusted module that is allowed to perform degradation operations during fault degradation assessment and decision-making.
[0034] By introducing a whitelist mechanism, a trusted module whitelist database is maintained within the secure virtual machine. This database records the identifiers, hash values, and available resource information of kernel modules that are permitted to perform fault handling and degradation operations. The whitelist is maintained based on the security authentication and testing results of kernel modules; only kernel modules that pass rigorous security assessments are added to the whitelist. During the fault degradation assessment process, the secure virtual machine first queries the whitelist to determine if the faulty kernel module is a trusted module. If the faulty kernel module is on the whitelist, a comprehensive assessment can be conducted to decide whether to perform fault handling and degradation operations. If the faulty kernel module is not on the whitelist, degradation processing can be directly disallowed, or the matter can be reported for manual assessment and decision-making, thus avoiding the security risks that might be introduced by performing degradation operations on untrusted modules.
[0035] S203, the secure virtual machine first compares the faulty kernel module with the trusted module whitelist. If the comparison is successful, it performs a fault degradation assessment, including confirming whether the faulty kernel module has unremovable references, whether it has unremovable system resources, and whether it has an impact on related modules and global resources.
[0036] First, the faulty module's identifier is compared with the trusted module whitelist. If the comparison is successful, a fault degradation assessment is performed. The fault degradation assessment includes: first, a module whitelist / blacklist admission check is performed for rapid pre-filtering with zero overhead. The security virtual machine maintains a user-preconfigured module degradation policy table, which categorizes kernel modules into three types: blacklist (deny) indicates core system modules that are not allowed to be downgraded, and a panic is triggered directly when the module crashes; whitelist (allow) indicates non-critical modules that are explicitly allowed to be downgraded, and a next-level assessment is initiated when the module crashes; graylist (default) indicates modules that are not explicitly configured and have the default policy, and a next-level assessment or panic is initiated when the module crashes based on the user-configured global policy. The subsequent processes are triggered by querying whether the faulty kernel module matches the corresponding list.
[0037] The second level of evaluation assesses the impact of the kernel module dependency chain. By traversing the kernel module dependency tree, the scope of the impact propagation after the failure of the faulty kernel module is evaluated, determining whether all affected modules are within the degradable range. A fault impact domain (Blast Radius) is constructed, with the faulty module as the root node. A reverse traversal is performed in the dependency tree, recursively collecting all upper-level modules that directly and indirectly depend on the faulty module, forming a set of affected modules S = {faulty kernel module} ∪ {all modules that directly / indirectly depend on the faulty kernel module}. The impact domain whitelist is then checked. For each module in the affected module set S, the first-level module degradation policy table is queried. If all modules in S are in the whitelist or graylist, and the global policy allows degradation, the third-level evaluation begins. If any module in S is in the blacklist, the evaluation terminates and a panic is triggered. A threshold check for the impact domain size can also be performed. Even if all affected modules are in the whitelist, if the number of affected modules is too large (e.g., exceeding the user-preset threshold N), degradation is deemed not allowed, as large-scale cascading unloading operations themselves introduce system instability.
[0038] Next, the system resource releaseability assessment proceeds to the third level. After passing the first two levels of assessment, the secure virtual machine needs to check the system resources occupied by all modules in the fault-affected module set S, determining whether each resource is safe to release at the current moment. For each type of resource, its current runtime state is checked; release is only allowed if the resource is in a quiescent state (inactive use); if the resource is in an active state (being executed, transferred, or contested), it is determined that it cannot be safely released. For example, for interrupt resources (IRQs), it checks whether the interrupt handler function registered by the faulty kernel module through request_irq() is currently executing. This involves querying each IRQ number registered by the faulty module, checking the status flags of the corresponding interrupt descriptor, and determining whether the interrupt is currently in the IRQS_INPROGRESS state (the interrupt handler is being executed on a CPU). If none of the IRQs are being executed, they can be safely released (first disable_irq to disable the interrupt line, then free_irq to unregister the handler). If any IRQ is being executed, it is marked as needing to wait. A short timeout window (e.g., tens of milliseconds) is set, and the process is rechecked. If the check finds that the interrupt is still being executed after the timeout, it can be determined that it cannot be safely released. For timers (timer_list / hrtimer), check if the timers registered by the faulty kernel module are active (queued in the kernel timer queue waiting to be triggered) and if the timer callback function is executing on a CPU. For timer_list type, check timer_pending() to determine if it is in the waiting queue. For hrtimer type, check hrtimer_active() to determine if it is active and hrtimer_callback_running() to determine if the callback is executing. If the timer is not active or active but the callback is not executing, it can be safely released (synchronously canceled via del_timer_sync() / hrtimer_cancel()). If the timer callback is executing, since the callback function may access the faulty module's code or data segment, forced cancellation may cause a secondary crash, so it is determined that it cannot be safely released. For work queues (workqueue), check if the faulty kernel module created a private work queue (alloc_workqueue) and if the work items submitted by the faulty module are queued or being executed.Specifically, the process checks whether there are any pending work items in the module's registered workqueue and whether any work item's callback function is being executed on a worker thread. If there are no pending and no executing work items, the workqueue can be safely destroyed (destroy_workqueue()). If there are pending work items but no executing ones, the workqueue can be safely canceled and then destroyed (cancel_work_sync() followed by destroy_workqueue()). If a work item is being executed, and the callback function may reference code segments from a faulty module, it cannot be safely interrupted, and therefore it is determined that it cannot be safely released. For DMA buffer checks, it checks whether there are ongoing DMA transfers in the DMA buffer allocated by the faulty kernel module. This involves querying the DMA engine status of the device associated with the faulty module to check for pending DMA descriptors. If the system has IOMMU / SMMU enabled, it checks the corresponding device's IOMMU page table for active address mappings being accessed by the device. If the device's DMA engine is idle and there are no ongoing transfers, the buffer can be safely released (dma_free_coherent() / dma_unmap_single()). If there are ongoing DMA transfers, the buffer must not be released, because releasing the buffer during a DMA transfer would cause the device to continue writing data to the released physical address, resulting in memory corruption. This is more serious than the consequences of the module crash itself, therefore it is determined that the buffer cannot be safely released. For locks / synchronization primitives (mutex / spinlock / semaphore / rwlock), it checks whether the faulty kernel module was holding a lock and had not released it when the crash occurred. Specifically, for a mutex, check if the mutex.owner field points to the execution context related to the faulty module (i.e., whether the crashed thread / process is the current lock holder); for a spinlock (requires the kernel to enable CONFIG_DEBUG_SPINLOCK or CONFIG_LOCKDEP): check the lock's owner and owner_cpu information; using the kernel's lockdep subsystem (lock dependency detection), query the lock held chain of the faulty context; if the faulty kernel module did not hold any locks at the time of the crash, it is determined that there is no deadlock risk; if the faulty kernel module held a lock at the time of the crash but the lock is only used by modules within the fault-affected domain S, it is acceptable (because all modules within S will be unloaded); if the faulty kernel module held a lock at the time of the crash and the lock is contested / waited for by modules outside S, and forcibly releasing the lock would destroy the consistency of the data structure protected by the lock, it is determined that it cannot be safely released.For kernel threads (kthread), the system checks whether the kernel thread created by the faulty kernel module is still running. This is done by checking the thread state (TASK_RUNNING, TASK_INTERRUPTIBLE, etc.) recorded during the resource registration phase using the kernel thread's `task_struct` pointer or PID. If the kernel thread is in an interruptible sleep state (TASK_INTERRUPTIBLE), it can be safely woken up and stopped using `kthread_stop()`. If the kernel thread is in a running state and is executing the faulty module's code, it must wait for the current code path to finish before stopping. A timeout window is set; if it still cannot stop after the timeout, it is considered unsafe to release. If the kernel thread is in an uninterruptible sleep state (TASK_UNINTERRUPTIBLE) and cannot be safely terminated, it is considered unsafe to release. For the notification chain callback, check whether the notifier callback registered by the faulty module is being invoked, that is, check whether the relevant notification chain (such as reboot_notifier_list, netdevice_notifier_list, etc.) is in the notification traversal state; if the notification chain is not currently being traversed, it can be safely unregistered (unregister_*_notifier()); if the notification chain is being traversed and the callback of the faulty module is currently being executed, it is determined that it cannot be safely released. In the third-level assessment, after completing the above item-by-item checks on all resources of all modules in the fault-affected module set S, a final decision is made according to the following rules: Let R_total = the total number of resource items of all modules in S, let R_safe = the number of resource items determined to be safe to release, and let R_unsafe = the number of resource items determined to be unsafe to release; if R_unsafe == 0, then all resources can be safely released, and downgrade operation is allowed; if R_unsafe > 0, then there are unsafe resources, downgrade is not allowed, and a panic is triggered; a strict pass / fail policy (i.e., a veto system) is adopted, and if any resource cannot be safely released, downgrade operation will not be performed, to avoid memory corruption, deadlock, or hardware anomalies that may be caused by any improperly released resource in the kernel space, and to avoid consequences more serious than kernel module crashes.
[0039] S204, in response to the fault handling degradation operation, terminates the process associated with the faulty kernel module, unloads the faulty kernel module, and releases the system resources occupied by the faulty kernel module.
[0040] S205: Collect the evaluation and decision results of fault handling degradation operations and complete operation records, and report them to the user level.
[0041] This embodiment constructs a secure domain and a non-secure domain based on the ARM64 hardware architecture and deploys secure and non-secure virtual machines accordingly. Simultaneously, it sets capture points to capture and promptly report fault information from the non-secure virtual machines. Then, it employs a resource cleanup attempt method to systematically release system resources such as interrupts and timers occupied by the faulty kernel module. Items that fail to be cleaned up are marked as polluted and their reuse is prohibited. Combined with a trusted module whitelist, modules allowed for degradation are queried and compared. This assessment and decision-making process for fault degradation operations achieves accurate prediction of resource recoverability and strict control over untrusted modules. It effectively reduces the risk of resource residue, deadlock, or secondary failures that may be caused by forcibly unloading faulty kernel modules, improves the security and success rate of degradation operations, and enhances the isolation protection capabilities and reliability of fault handling in the virtualization dual-domain architecture.
[0042] Example 3 Figure 4 This is a flowchart of a virtualization-based dual-domain security fault handling method according to Embodiment 3 of the present invention. This embodiment is based on the above embodiment and optimized. In this embodiment, S103 is specifically optimized as follows: In response to a fault handling degradation operation, identify the process associated with the faulty kernel module and send a process termination signal; Check the process status. If the process enters an uninterruptible state, call the security virtual machine to freeze and migrate the process. Then, remove the module reference, unload the faulty kernel module, and reclaim the system resources it occupies.
[0043] Accordingly, the virtualization-based dual-domain security fault handling method provided in this embodiment specifically includes: S301. Deploy secure virtual machines and insecure virtual machines in the secure domain and insecure domain respectively. Based on the kernel module dependency chain, construct the kernel module dependency tree of the insecure virtual machine in the secure virtual machine and obtain the resource usage information of each kernel module of the insecure virtual machine.
[0044] S302 In response to a kernel module crash in an insecure virtual machine, the secure virtual machine attempts to clean up system resources for the crashed kernel module based on the kernel module dependency tree and the resource usage information of each kernel module, in order to conduct a fault degradation assessment and decide whether to perform a fault handling degradation operation.
[0045] S303 is a fault handling degradation operation in response to a decision. It attempts to clean up system resources based on the kernel module dependency tree and the resource usage information of each kernel module, identifies the process associated with the faulty kernel module, and sends a process termination signal.
[0046] Once the secure virtual machine decides to allow the fault handling degradation operation and issues the execution instruction, the non-secure virtual machine enters the execution phase of the fault handling degradation operation. First, based on the kernel module dependency tree, it locates the node corresponding to the faulty kernel module from the constructed kernel module dependency tree to determine its dependencies and identifies all processes associated with the faulty kernel module. It first attempts to send SIGTERM signals to these processes to request graceful termination. The SIGTERM signal allows processes to catch and execute custom cleanup operations, such as closing open file descriptors and releasing dynamically allocated memory, before exiting automatically. Then, it attempts to clean up each resource one by one according to the resource usage table registered by the faulty kernel module. For example, for an interrupt number IRQ, it first masks the hardware interrupt source corresponding to the interrupt number by manipulating hardware registers to prevent new interrupts from arriving; then it waits synchronously to ensure that the currently executing interrupt handler function completes; finally, it attempts to call free_irq() or a similar interface to remove the registration relationship of the interrupt number. If it is a shared interrupt, the entire IRQ cannot be released abruptly; instead, the handler item corresponding to the device's dev_id is unbound to avoid affecting the interrupt handling of other modules. For timers, cleanup attempts include calling interfaces such as del_timer_sync() or hrtimer_cancel() to ensure the timer is canceled and there are no executing callback functions. For work queue resources, cleanup attempts include calling interfaces such as flush_work() and cancel_work_sync(). For lock resources, you can check if any process is waiting for the lock.
[0047] S304, check the process status. If the process enters an uninterruptible state, call the security virtual machine to freeze and migrate the process. Then, remove the module reference, unload the faulty kernel module, and reclaim the system resources it occupies.
[0048] After sending the SIGTERM signal, the system monitors the state changes of each process by checking its task->state field. If a process responds normally and exits within the timeout period, the system continues processing the next process. If a process is detected to have entered an uninterruptible state (TASK_UNINTERRUPTIBLE), it indicates that the process is waiting for certain resources (such as disk I / O, kernel locks, etc.) and cannot respond to the SIGTERM signal. In this case, the situation can be reported to the security virtual machine to request freezing, migration, or other processing of the process. The security virtual machine can decide whether to freeze or migrate the process based on the current system load, process priority, and the impact range of the faulty module.
[0049] An optional implementation of this embodiment is as follows: if the process related to the faulty kernel module is in an uninterruptible state, the freeze function is called to freeze the process and attempt to migrate the process to other processor cores. After the fault is resolved, the freeze is lifted and the process is restored.
[0050] The target process is frozen by calling the kernel's `freeze_task()` function. Once frozen, the process will no longer be scheduled for execution, but its execution context is preserved. The load on the current CPU core is then assessed, and the process can be migrated to a healthy CPU core unaffected by the faulty kernel module. After the faulty module is unloaded and its resources are cleaned up, the system calls the `thaw_process()` function to thaw the process, allowing it to resume execution from the frozen point. If the resources held by the process during the freeze period are not lost due to module unloading, the process can seamlessly resume execution. The migration process must ensure that the process can continue execution on the new core after recovery.
[0051] If process migration fails or the system resources occupied by the faulty kernel module cannot be released, the process will be forcibly terminated and the resources occupied by the process will be completely reclaimed.
[0052] If a process freeze migration fails, such as failing to find a usable healthy CPU core or encountering an anomaly during the migration process, a forced shutdown must be performed to kill the process. This is done by calling `force_sig(SIGKILL)` to send an uncaught termination signal to the process and reclaiming all resources used by the process. If resource cleanup attempts by the faulty module also fail, the same forced process termination and resource reclamation measures are taken. Afterwards, memory pages occupied by the process are released, all file descriptors are closed, network connections are released, and locks are released. The complete release of all resources without any residue can be ensured by traversing the process's `mm_struct`, `files_struct`, and `fs_struct` data structures.
[0053] If all system resources are successfully cleaned, the entire fault handling and degradation process is recorded for reporting. If some system resources fail to be cleaned, the system resources that failed to be cleaned are marked as polluted, and the resource pollution information is recorded.
[0054] If some resource cleanup fails, such as a lock being occupied by another module for a long time and unable to be released, these failed cleanup resource items are marked as polluted and the pollution information is recorded in the resource pollution information table so that the system can prevent the resource from being requested or reused by any module in the future, thus avoiding the spread of pollution.
[0055] S305 collects the evaluation and decision results of fault handling degradation operations and complete operation records and reports them to the user level.
[0056] Specifically, the system collects the evaluation and decision results of fault handling and degradation operations, complete operation records, resource cleanup status, and resource pollution information, and reports them to the user layer through a subscription / publishing mechanism. It also synchronously updates the kernel module dependency tree and resource usage information, and applies for resource prohibition policies based on resource pollution information to prevent the reuse of polluted resources.
[0057] After all fault degradation handling operations are completed, the system collects a complete processing record, including: the evaluation and decision results of the fault degradation operation, fault module information, dependency analysis results, resource cleanup attempt results (which resources were successfully cleaned up, which failed), resource pollution information, process handling records (which processes were gracefully terminated, which were frozen and migrated, and which were forcibly killed), module uninstallation records, and resource reclamation lists. The collected information can be encapsulated and reported to the user layer through a subscription / publishing mechanism. The user layer's monitoring agent can subscribe to relevant topics. When fault handling is complete, the publishing module encapsulates the collected information into structured data (such as JSON format) and publishes it through a secure channel. After receiving the data, the user layer's monitoring agent can choose to display it to the system administrator for manual intervention or store it in a historical database for further analysis. The system can also dynamically update resource management policies based on reported resource pollution information. For resources marked as polluted during resource cleanup attempts, a prohibited application list is established in the resource application module. When any kernel module subsequently attempts to apply for this resource, the resource application interface will check this prohibited list and return an error, preventing the misuse of polluted resources and avoiding potential system stability risks. To ensure that the secure virtual machine always has the latest status of the non-secure virtual machine, it is also necessary to synchronously update the kernel module dependency tree and resource usage information maintained in the secure virtual machine based on the reported fault handling records. For example, if a faulty module is uninstalled, its node is removed from the dependency tree; if some resources are found to be released during the resource cleanup process, the corresponding entries are deleted from the resource usage table, providing an accurate data foundation for subsequent possible fault handling.
[0058] This embodiment employs a tiered approach to processes associated with faulty modules, prioritizing graceful termination via SIGTERM, freezing and migrating uninterruptible processes, and forcibly shutting them down when necessary to ensure complete resource recovery. Simultaneously, a publish / subscribe mechanism reports fault handling results and resource contamination status to the user layer, synchronously updating the kernel module dependency tree and resource usage table, and implementing a policy to prohibit the reuse of contaminated resources. This achieves comprehensive, refined recovery and dynamic closed-loop management of processes, modules, and system states, ensuring the availability of business processes, preventing resource leaks and contamination spread, maintaining healthy system operation, and providing stable performance for virtualization environments with high availability requirements.
[0059] Example 4 Figure 5 This is a schematic diagram of a virtualization-based dual-domain security fault handling device according to Embodiment 4 of the present invention. In this embodiment, the virtualization-based dual-domain security fault handling device includes: The dual-domain construction unit 810 is used to deploy secure virtual machines and insecure virtual machines in the secure domain and insecure domain respectively, and to build the kernel module dependency tree of the insecure virtual machine in the secure virtual machine, and obtain the resource usage information of each kernel module of the insecure virtual machine. The fault degradation assessment unit 820 is used to respond to the kernel module crash in the non-secure virtual machine, attempt to clean up system resources of the kernel module that crashed, perform fault degradation assessment and decide whether to perform fault handling degradation operation. The fault handling degradation unit 830 is used to respond to fault handling degradation operations, terminate the process related to the faulty kernel module, unload the faulty kernel module, and release the system resources occupied by the faulty kernel module. The information reporting unit 840 is used to collect the evaluation decision results and complete operation records of the fault handling degradation operation and report them to the user layer.
[0060] This embodiment deploys secure and insecure virtual machines in the secure and insecure domains respectively through a dual-domain construction module, and constructs a kernel module dependency tree for the insecure virtual machine to obtain resource usage information for each kernel module. A fault degradation assessment module responds to kernel module crashes in the insecure virtual machine, performs fault degradation assessment and makes decisions, and a fault handling degradation module responds to fault handling degradation operations, unloading the faulty kernel module and releasing the system resources it occupies. An information reporting module collects the assessment and decision results and complete operation records of the fault handling degradation operations and reports them to the user layer. This achieves adaptive assessment and refined handling of kernel module crashes in a virtualized environment, limiting the impact of module crashes to a minimum, avoiding kernel panic or overall system crashes caused by a single module crash, improving the operational stability of the virtualization platform. Simultaneously, recording and reporting complete processing records provides users with a reference for fault analysis, improving the observability and maintainability of the virtualization platform.
[0061] The virtualization-based dual-domain security fault handling device provided in the embodiments of the present invention can execute the virtualization-based dual-domain security fault handling method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.
[0062] Example 5 Figure 6 This is a structural diagram of an electronic device according to Embodiment 5 of the present invention. Figure 6 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 6 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.
[0063] like Figure 6 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).
[0064] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.
[0065] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.
[0066] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 6 Not shown; usually referred to as a "hard drive"). Although Figure 6 As not shown, disk drives for reading and writing to removable non-volatile disks (e.g., "floppy disks") and optical disc drives for reading and writing to removable non-volatile optical discs (e.g., CD-ROMs, DVD-ROMs, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.
[0067] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.
[0068] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 6 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 6 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0069] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the virtualization-based dual-domain security fault handling method provided in the embodiments of the present invention.
[0070] Example 6 Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the virtualization-based dual-domain security fault handling method provided in the above embodiments.
[0071] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. 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 computer-readable storage media (a non-exhaustive list) include: 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 document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
[0072] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.
[0073] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0074] Computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0075] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.< / mod> < / mod> < / mod>
Claims
1. A virtualization-based dual-domain security fault handling method, characterized in that, include: S101, deploy secure virtual machines and insecure virtual machines in the secure domain and insecure domain respectively, construct the kernel module dependency tree of the insecure virtual machine in the secure virtual machine according to the kernel module dependency chain, and obtain the resource usage information of each kernel module of the insecure virtual machine. S102, In response to a kernel module crash in an insecure virtual machine, the secure virtual machine performs a fault degradation assessment on the crashed kernel module based on the kernel module dependency tree and the resource usage information of each kernel module, and decides whether to perform fault handling degradation operation. S103, in response to the decision, the fault handling degradation operation, the security virtual machine attempts to clean up system resources of the faulty kernel module based on the kernel module dependency tree and the resource usage information of each kernel module, terminates the process related to the faulty kernel module, unloads the faulty kernel module, and releases the system resources occupied by the faulty kernel module. S104, collect the evaluation decision results and complete operation records of the fault handling degradation operation and report them to the user level.
2. The method according to claim 1, characterized in that, S101 further includes: Based on the ARM64 architecture hardware, a secure domain and a non-secure domain are constructed. A secure virtual machine is deployed in the secure domain, and a non-secure virtual machine is deployed in the non-secure domain. The secure virtual machine can read the kernel module list and module reference relationship of the non-secure virtual machine through the system interface of the non-secure virtual machine, and construct a kernel module dependency relationship tree. When the kernel modules of the non-secure virtual machine are initialized or running, they will register the system resource handles they occupy with the secure virtual machine. Set up status monitoring and exception event capture points at the kernel exception function entry points of non-secure virtual machines to capture kernel module crash failure information and report it to secure virtual machines.
3. The method according to claim 1, characterized in that, S102 further includes: A trusted module whitelist is established in the secure virtual machine to record the identifier, hash value, and available resource information of the kernel modules that are allowed to perform fault handling degradation operations. This whitelist is used to query and compare whether the faulty kernel module is a trusted module that is allowed to perform degradation operations during fault degradation assessment and decision-making.
4. The method according to claim 3, characterized in that, S102 includes: When a kernel module of a non-secure virtual machine crashes, access data to the faulty kernel module is intercepted, and a fault degradation assessment is triggered. The secure virtual machine first compares the faulty kernel module with the trusted module whitelist. If the comparison is successful, it performs a fault degradation assessment, including confirming whether the faulty kernel module has any unremovable references, whether it has any unremovable system resources, and whether it has any impact on related modules and global resources.
5. The method according to claim 1, characterized in that, S103 includes: In response to the decision, the fault handling degradation operation attempts to clean up system resources based on the kernel module dependency tree and the resource usage information of each kernel module, identify the processes associated with the faulty kernel module, and send process termination signals. Check the process status. If the process enters an uninterruptible state, call the security virtual machine to freeze and migrate the process. Then, remove the module reference, unload the faulty kernel module, and reclaim the system resources it occupies.
6. The method according to claim 5, characterized in that, S103 further includes: If the process related to the faulty kernel module is in an uninterruptible state, the freeze function is called to freeze the process and attempt to migrate the process to other processor cores. The freeze is lifted and the process is restored after the fault is resolved. If process migration fails or the system resources occupied by the faulty kernel module cannot be released, the process will be forcibly terminated and the resources occupied by the process will be completely reclaimed. If all system resources are successfully cleaned, the entire fault handling and degradation process is recorded for reporting. If some system resources fail to be cleaned, the system resources that failed to be cleaned are marked as polluted, and the resource pollution information is recorded.
7. The method according to claim 1, characterized in that, S104 further includes: Collect the evaluation and decision results of fault handling and degradation operations, complete operation records, resource cleanup status, and resource pollution information, and report them to the user layer through a subscription / publish mechanism. Synchronously update the kernel module dependency tree and resource usage information, and apply for resource prohibition policies based on resource pollution information to prevent the reuse of polluted resources.
8. A virtualization-based dual-domain security fault handling apparatus, used to implement the virtualization-based dual-domain security fault handling method as described in any one of claims 1-7, characterized in that, include: The dual-domain building module is used to deploy secure virtual machines and insecure virtual machines respectively in the secure domain and insecure domain, and to build the kernel module dependency tree of the insecure virtual machine in the secure virtual machine, and obtain the resource usage information of each kernel module of the insecure virtual machine. The fault degradation assessment module is used to respond to kernel module crashes in non-secure virtual machines. It attempts to clean up system resources for the kernel module that has crashed, in order to assess the fault degradation and decide whether to perform fault handling degradation operations. The fault handling degradation module is used to respond to fault handling degradation operations, terminate the processes related to the faulty kernel module, unload the faulty kernel module, and release the system resources occupied by the faulty kernel module. The information reporting module is used to collect the evaluation and decision results of fault handling degradation operations and complete operation records and report them to the user level.
9. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the virtualization-based dual-domain security fault handling method as described in any one of claims 1-7.
10. A storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the virtualization-based dual-domain security fault handling method as described in any one of claims 1-7.