Operating system failure attribution method, apparatus, medium, device, and program product

Abstract

The application discloses an operating system fault attribution method, device, medium, equipment and program product. In response to detecting that an abnormal event occurs in the operating system, fault scene information corresponding to the abnormal event is extracted, and a structured fault scene summary is formed. The fault scene summary at least contains fault type, fault object and key execution path information. At least one preset risk dimension is determined, the fault scene summary is matched with a pre-stored structured intrusion image of a third-party security software subject in the at least one risk dimension, and according to a matching result, an association level between the third-party security software subject and the abnormal event and association evidence are output. The fault scene summary contains multiple dimension information, the multi-dimensional matching of the fault scene summary and the intrusion image can accurately attribute whether the fault scene and the intrusion point are associated, and is favorable for operation and maintenance personnel to quickly locate problems and take targeted troubleshooting measures.

Description

Technical Field

[0001] This application relates to the field of operating system stability diagnosis technology, and in particular to an operating system fault attribution method, apparatus, medium, device and program product. Background Technology

[0002] In Linux systems, third-party security software often deeply intervenes in critical execution paths by loading external kernel module files (ko files), using kernel probes (kprobe) or function tracers (ftrace), modifying the syscall table, registering notifier call chains, or utilizing preloaded environment variables (LD_PRELOAD) and process tracing (ptrace) in user space. Some schemes also utilize permission events from the file system event monitoring interface (fanotify) or user-space notifications in secure computing mode (seccomp usernotification) to convert fast system calls into synchronous blocking paths. These mechanisms can introduce stability risks once they affect core paths such as program execution (exec) loading and high-frequency file access.

[0003] When kernel panics, kernel Oops, hung tasks, or application core dumps occur, engineers can obtain on-site information, but they struggle to quickly determine if highly invasive security mechanisms exist, whether these mechanisms are related to the fault type, and whether the fault directly targets or manipulates the intrusion object or call chain. This leads to a heavy reliance on manual cross-analysis of kernel logs, call stacks, and injection traces for troubleshooting, which is not only costly and inconsistent but also difficult to scale and reuse. Summary of the Invention

[0004] This application provides an operating system fault attribution method to at least partially solve the problems of existing technologies that rely heavily on manual cross-analysis of kernel logs, call stacks and injection traces for troubleshooting operating system faults. This method is not only costly and has poor consistency of conclusions, but also difficult to scale and reuse.

[0005] The technical solution adopted in this application is as follows: This application provides a method for attributing operating system failures, including: In response to the detection of an abnormal event in the operating system, fault scene information corresponding to the abnormal event is extracted and a structured fault scene summary is formed; wherein, the fault scene summary includes at least the fault type, the fault object, and key execution path information; Determine at least one preset risk dimension, match the fault scene summary with the pre-stored structured intrusion profile of the third-party security software subject according to the at least one risk dimension, and output the association level and association evidence between the third-party security software subject and the abnormal event based on the matching result.

[0006] Optionally, before detecting an abnormal event in the operating system, the method further includes: Identify installed third-party security software entities and audit their intrusion behavior into critical execution paths of the operating system; Based on the audit results of the intrusion behavior, a structured intrusion profile of the third-party security software entity is constructed. The structured intrusion profile includes at least one of the following: intrusion target, intrusion method, intrusion level, and potential impact failure type associated with the intrusion behavior.

[0007] Optionally, auditing the third-party security software's intrusion into critical execution paths of the operating system includes: The system obtains the intrusion behavior of the third-party security software entity into the critical execution path of the operating system, and classifies the level of interference of the intrusion behavior into the system execution path. The level includes at least synchronous blocking intrusion and asynchronous blocking intrusion.

[0008] Optionally, before constructing the structured intrusion profile of the third-party security software entity, the method further includes: The audit results are mapped to preset risk dimensions; the risk dimensions include at least blocking amplification risk and call chain extension risk.

[0009] Optionally, the structured intrusion profile also includes a predefined mapping relationship between intrusion types and potential impact fault types; the mapping relationship includes at least: a first mapping between synchronous blocking intrusions and task suspension faults, and a second mapping between execution path rewriting intrusions and kernel crash faults.

[0010] Optionally, matching is performed at least through blocking chain match, matching the fault scene summary with a pre-stored structured intrusion profile of the third-party security software entity for at least one risk dimension, including: Determine whether the blocked waiting object or blocking function recorded in the fault scene summary has a consistent call path relationship with the synchronous blocking point created by the third-party security software entity recorded in the structured intrusion profile.

[0011] Optionally, the association level is output, including: When the matching results show that the fault scene summary directly matches the intrusion object or synchronization blockage point in the structured intrusion profile, the first level is output; when the matching results show a high match in path category, fault type, and time window but no direct match, the second level is output; and / or Output the associated evidence, including: The output contains a chain of evidence explaining why the match occurred.

[0012] Optionally, fault scene information corresponding to the abnormal event is extracted, and a structured fault scene summary is formed, including: Detect the type of fault; Collect fault scene information corresponding to the fault type; Extract time window information related to the fault scene information; Based on the time window information, the fault scene information is normalized to form a fault scene summary.

[0013] This application also provides an operating system fault attribution device, comprising: The fault scene extraction module is used to extract fault scene information corresponding to the abnormal event in response to the detection of an abnormal event in the operating system, and form a structured fault scene summary; wherein, the fault scene summary includes at least the fault type, the fault object, and key execution path information; The matching module is used to determine at least one preset risk dimension, match the fault scene summary with the pre-stored structured intrusion profile of the third-party security software subject for the at least one risk dimension, and output the association level and association evidence between the third-party security software subject and the abnormal event based on the matching result.

[0014] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described operating system fault attribution method.

[0015] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described operating system fault attribution method.

[0016] This application also provides a computer program product comprising a computer program that, when executed by a processor, implements an operating system fault attribution method.

[0017] The above-mentioned technical solution adopted in this application can achieve the following beneficial effects: The operating system fault attribution method provided in this application, in response to detecting an abnormal event in the operating system, extracts fault scene information corresponding to the abnormal event and forms a structured fault scene summary; wherein, the fault scene summary includes at least fault type, fault object, and critical execution path information. At least one preset risk dimension is determined, and the fault scene summary is matched with a pre-stored structured intrusion profile of a third-party security software entity according to the at least one risk dimension. Based on the matching result, the association level and association evidence between the third-party security software entity and the abnormal event are output. The fault scene summary contains multiple dimensions of information. Through multi-dimensional matching of the fault scene summary and the intrusion profile, the method accurately attributes whether there is a correlation between the fault scene and the intrusion point where the third-party security software performs intrusion behavior on the critical execution path of the operating system. This helps maintenance personnel quickly locate the third-party security software entity that committed the intrusion behavior, facilitating subsequent targeted troubleshooting measures. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating an operating system fault attribution method provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of a fault summary generation process. Figure 3 This is an example flow of an operating system fault attribution method provided in an embodiment of this application; Figure 4 This is a schematic diagram of a modular design provided in an embodiment of this application; Figure 5 This application provides a corresponding embodiment. Figure 4 A schematic diagram of the timing interactions of each module; Figure 6 A schematic diagram of an operating system fault attribution device provided in an embodiment of this application; Figure 7 The embodiments provided in this application are related to Figure 1 A schematic diagram of the electronic device corresponding to the method. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] In the daily operation and maintenance of Linux operating systems, third-party security software often uses various mechanisms to deeply and continuously intervene in critical execution paths at the kernel layer, system call layer, execution loading layer, user-space critical library layer, and access decision layer for protection or auditing purposes. For example, these software programs may insert themselves into the kernel path by loading external kernel module files (Kernel Objects, ko), using kernel probes (kprobe) or function tracers (ftrace), or by modifying the syscall table or registering the notifier call chain to extend the core call logic of the system. At the user-space level, their intrusion methods include forcibly injecting dynamic libraries using preloaded environment variables (LD_PRELOAD) or altering the execution flow of critical processes through process tracing system calls (ptrace). In addition, some schemes utilize permission events in the file system event monitoring interface (fanotify) or the user-space notification mechanism of secure computing mode (seccomp user notification) to transform some system calls that should have completed quickly into synchronous blocking paths that must wait for user-space responses. These mechanisms are not necessarily harmful in themselves, but once they touch the critical path of the kernel, the core link of system calls, the loading path of program execution (exec), or the high-frequency file access path, they can easily pose a potential threat to the overall stability of the system.

[0021] When a system subsequently experiences stability failures such as kernel panics, kernel Oops, hungtasks, deadlocks, prolonged freezes, startup anomalies, application core dumps, or critical service failures, engineers, despite typically having access to contextual information about the failure and information about installed security software, still struggle to quickly and accurately answer a series of critical questions. They find it difficult to directly determine whether highly invasive security mechanisms exist on critical paths, nor can they clearly identify any technical connection between such mechanisms and the current failure type. Furthermore, they struggle to determine whether the failure directly or indirectly triggered intrusions, blocking chains, or callback paths of security software, thus making it difficult to decide whether a particular third-party security software should be considered a contributing factor, a potential root cause, or a high-risk disruptive element. As a result, the existing troubleshooting process relies heavily on the personal experience of engineers, often requiring manual cross-comparison of kernel logs, module lists, call chains, blocking scenarios, user-mode injection traces, and system configurations to find clues. This leads to high costs for the entire analysis process, poor consistency of the conclusions, and difficulty in achieving large-scale reuse.

[0022] While existing solutions can detect the presence of external kernel modules, dynamic library injections, callback registrations, or access control mechanisms in a system to some extent, they mostly remain at the level of detecting "whether they exist." They are unable to further answer what stability issues these intrusion behaviors will affect, nor can they form reusable and interpretable attribution criteria.

[0023] Furthermore, while existing fault analysis solutions can preserve some fault context when panics, oops, hung tasks, deadlocks, prolonged freezes, startup anomalies, application core dumps, or critical service failures occur—such as kernel logs, call stacks, blocked thread information, coredump summaries, or module snapshots—these solutions are typically disconnected from the historical intrusion behavior of third-party security software. Even if third-party module symbols, callback chains, blocked wait objects, or rewritten execution paths appear in the fault context, engineers still need to manually compare module lists, call chains, blocking relationships, and system configurations. This results in low analysis efficiency, high interpretation costs, and a strong reliance on individual engineer experience.

[0024] Furthermore, existing comprehensive troubleshooting methods that rely on manual experience often encounter the following problems when multiple third-party security software entities, multiple intrusion points, and multiple candidate root causes exist simultaneously in the system: First, it is difficult to uniformly measure the interference level of different intrusion behaviors, and it is easy to confuse read-only observation behaviors with synchronous blocking behaviors; second, it is difficult to precipitate the effective experience discovered in a single troubleshooting session into reusable structured rules; third, it is difficult to provide a unified, automatic, and interpretable correlation level output for "whether it directly hits the intrusion object," "whether it hits the blocking chain," and "whether it only manifests as type matching and temporal proximity." Therefore, existing technologies are insufficient to meet the business needs of large-scale, standardized, and low-cost stability attribution.

[0025] To facilitate understanding of the technical solution of this application, some key concepts involved in this application will be explained below.

[0026] Linux: A Unix-like operating system kernel and the common operating environment for its distributions.

[0027] ko: Kernel Object, a loadable module file in the Linux kernel.

[0028] taint: A Linux kernel pollution marker used to characterize whether the kernel has loaded non-standard modules, experienced a serious exception, or is in an untrusted state.

[0029] kprobe: A dynamic probe mechanism in the Linux kernel, used to insert probe processing logic at a specified kernel instruction address.

[0030] kretprobe: A return probe mechanism in the Linux kernel, used to insert probe processing logic when the target function returns.

[0031] ftrace: A Linux kernel function tracing framework that can be used for function call observation, jump redirection, or hook-like operations.

[0032] LSM: Linux Security Modules, a framework for attaching security policy logic at security-sensitive operation points.

[0033] syscall table: The system call table is used to maintain the mapping relationship between system call numbers and the entry points of the handler functions.

[0034] Notifier call chain: A kernel notification chain mechanism used to broadcast notifications to registered callbacks when a specific event occurs.

[0035] binfmt: Linux executable file format handling registration mechanism, used to determine how to handle different format objects during the execution loading phase.

[0036] fanotify: Linux file access notification mechanism; the permission event can synchronously block the call path and wait for user-space feedback during the access decision phase.

[0037] LD_PRELOAD: The dynamic linker preloading mechanism, which can load specified shared libraries at process startup to replace or intercept existing function calls.

[0038] libc: The C runtime library, which is the foundation for a large number of critical function calls in user space.

[0039] ptrace: A Linux process tracing mechanism that can be used for debugging, injection, pausing, or controlling target processes.

[0040] seccomp user notification: The Linux seccomp user-space notification mechanism can forward specific system call decisions to user-space processing.

[0041] panic: A fatal exception state triggered by the Linux kernel when it detects an unrecoverable error.

[0042] oops: Abnormal diagnostic information output when a serious error occurs in the Linux kernel but it does not immediately terminate completely.

[0043] Hung task: An abnormal phenomenon in the Linux kernel where a task remains in an uncompleted, blocked state for an extended period.

[0044] coredump: A memory dump of information generated when a process crashes abnormally, used to preserve the fault scene.

[0045] Intrusion auditing: The process of detecting and recording whether third-party security software interferes with the critical execution path of the operating system through methods such as modules, callbacks, redirection, interception, blocking, or replacement.

[0046] Intrusion profile: A structured description of the intruder, intrusion level, intrusion target, intrusion method, intrusion intensity, potential impact range of failures, and risk level of third-party security software intrusion.

[0047] Association Definition: When a stability problem occurs, the fault scene is matched with the intrusion profile, and a graded judgment is output, such as clear association, highly suspicious or possible.

[0048] The technical solutions provided by various embodiments of this application are described in detail below with reference to the accompanying drawings. For ease of description, a server is used as the execution subject in the following description. Of course, in other embodiments, the execution subject may also be an electronic device, or a diagnostic system composed of a lightweight kernel-side acquisition module and a user-mode analysis process.

[0049] Figure 1 This is a flowchart illustrating an operating system fault attribution method provided in an embodiment of this application. Figure 1 As shown, the method may include the following steps.

[0050] S200: In response to detecting an abnormal event in the operating system, extract the fault scene information corresponding to the abnormal event and form a structured fault scene summary; wherein, the fault scene summary includes at least the fault type, fault object and key execution path information.

[0051] Servers can detect abnormal events in various ways. For example, they can detect panics or oops through kernel anomaly monitoring mechanisms, hung tasks through task monitoring mechanisms, wait cycles through deadlock detection logic, critical service anomalies through service monitoring mechanisms, and application core dumps through application crash collection mechanisms. This step can proceed as long as it triggers the extraction of fault scene information.

[0052] When extracting fault scene information, the server prioritizes first determining the fault type of the abnormal events. For example, abnormal events are categorized into panic, oops, hung task, deadlock, prolonged lag, startup anomaly, critical service anomaly, or application core dump, etc. Different categories correspond to different focuses of scene extraction.

[0053] For panic or oops exceptions, the server can extract the abnormal CPU, abnormal process, error address, key stack frame, related module name, symbol information, and kernel log fragments, and extract path summaries related to the key execution path from them. For example, if the panic stack contains symbols from an out-of-tree module and the target function being hooked, this information can be included in the key execution path information.

[0054] For hung tasks or deadlock-type exceptions, the server can focus on extracting blocked threads, waiting objects, waiting functions, lock chains, call stacks, wait durations, and blocking chain summaries. For example, if multiple tasks are blocked in fanotify-related waiting functions, or if the waiting object points to the response chain of a user-space decision daemon, this information can serve as key execution path information and blocking characteristics in the fault scene summary.

[0055] For application core dump exceptions, the server can extract the crashed process, crash function, signal type, shared library mapping, execution context, critical thread stack, and relevant injection traces at the time of the exception. For example, if a preloaded shared library exists in the process mapping and the crash function is adjacent to the path of a replaced critical library function, the shared library mapping and the crash function can be included in the fault context summary.

[0056] For startup anomalies or critical service anomalies, the server can extract module loading information during the startup phase, execution loading path information, critical service status, failure phase identifiers, and system state snapshots before and after the anomaly. For example, if startup failures are concentrated in the exec loading phase, and there were prior changes to binfmt registration or intervention of startup packaging logic in that phase, this information can be categorized as critical execution path information.

[0057] In some embodiments, in addition to the on-site information of the fault itself, the server also extracts time window information related to the abnormal event. For example, module loading, callback registration, configuration rewriting, injection events, or profile change records within a preset time period before the fault occurred can be included in the fault on-site information for subsequent matching to determine time proximity. This preset time period can be set to several seconds, several minutes, or other time ranges depending on the actual scenario. Correspondingly, the structured fault on-site summary also includes time window information. The time window information includes: changes in intrusion behavior, module loading, callback registration, or injection events related to the third-party security software entity within a preset time period before the abnormal event occurred. In this embodiment, the time window information in the summary can identify changes in intrusion behavior (new loading, new registration, new injection, etc.) within the time window before the fault occurred, for subsequent time proximity matching.

[0058] When generating a structured summary of the fault scene, the server retains at least the fault type, the fault object, and key execution path information. Here, the fault object can be one or more of the following: an abnormal module, an abnormal process, an abnormal thread, a crashed function, a waiting object, or an abnormal service. Key execution path information can be a stack summary, a path summary, a blocking function, a waiting object, key symbols, shared library hits, callback chain hits, or other information that can represent path characteristics.

[0059] To facilitate understanding, the following examples illustrate how fault scene summaries are formed under different fault types.

[0060] Example 1: In a task suspension scenario, the server detects that multiple tasks are in an uncompleted blocked state for an extended period. The server extracts the wait functions, wait objects, and call stacks of each blocked thread, finding that multiple threads are stuck at the `fanotify` wait point on the same file access path for more than a preset duration. At this point, the server can generate the following fault scene summary: the fault type is a task suspension fault; the fault object is a set of blocked threads or a target file access object; and the key execution path information includes the `fanotify` related wait functions, the blocking chain summary, and the corresponding call stack summary.

[0061] Example 2: In a kernel crash scenario, the server extracts a key stack frame from the panic log containing third-party module symbols and the rewritten target function. At this point, the server can generate the following fault scene summary: the fault type is a kernel crash, the fault object is the thread or exception function corresponding to the crashed CPU, and the key execution path information includes the panic stack summary, the hit module symbols, and the target function path.

[0062] Example 3: In a core dump scenario of an application, the server detects that the crashed process has loaded a preloaded shared library, and the crashing function is adjacent to the wrapper paths of critical functions such as `open` or `execve`. In this case, the server can generate the following fault scene summary: the fault type is an application core dump type fault, the fault object is the crashed process, and the key execution path information includes shared library mappings, the crashing function, the execution context, and a summary of the key call chain.

[0063] S202: Determine at least one preset risk dimension, match the fault scene summary with the pre-stored structured intrusion profile of the third-party security software subject according to the at least one risk dimension, and output the association level and association evidence between the third-party security software subject and the abnormal event based on the matching result.

[0064] This step is the core of this application's automatic attribution mechanism. The server is not directly identified as causing the abnormal event simply because a third-party security software entity exists in the system. Instead, the degree of correlation is determined through multi-dimensional matching between the fault scene summary and the structured intrusion profile.

[0065] The operating system fault attribution method provided in this application, in response to detecting an abnormal event in the operating system, extracts fault scene information corresponding to the abnormal event and forms a structured fault scene summary; wherein, the fault scene summary includes at least fault type, fault object, and critical execution path information. At least one preset risk dimension is determined, and the fault scene summary is matched with a pre-stored structured intrusion profile of a third-party security software entity according to the at least one risk dimension. Based on the matching result, the association level and association evidence between the third-party security software entity and the abnormal event are output. The fault scene summary contains multiple dimensions of information. Through multi-dimensional matching of the fault scene summary and the intrusion profile, the method accurately attributes whether there is a correlation between the fault scene and the intrusion point where the third-party security software performs intrusion behavior on the critical execution path of the operating system. This helps maintenance personnel quickly locate the third-party security software entity that committed the intrusion behavior, facilitating subsequent targeted troubleshooting measures.

[0066] In some embodiments, before detecting an abnormal event in the operating system, the server needs to pre-build a structured intrusion profile of the third-party security software entity for subsequent real-time matching tasks. Specifically, prior to step S200 above, the operating system failure attribution method of this application may further include the following steps S204 and S206.

[0067] S204: Identify installed third-party security software entities and audit the intrusion behavior of said third-party security software entities into the critical execution paths of the operating system.

[0068] In operating system stability attribution scenarios, servers can periodically perform runtime audit tasks, or this step can be performed after system startup, module loading, configuration changes, or at preset detection times. The purpose of this step is to first answer "What third-party security software entities are in the system?", and then answer "Have these entities committed intrusive acts on critical execution paths?"

[0069] When identifying third-party security software entities, the server can perform discovery from multiple sources. In some embodiments, the server can scan loaded out-of-tree kernel modules, non-default modules, or modules marked with kernel pollution to identify kernel-level entities; it can scan user-mode daemons, resident services, startup wrapper processes, and injector processes to identify user-mode entities; and it can further examine shared library preload configurations, dynamic linker replacement configurations, startup link rewriting traces, and package information related to vendor identifiers to supplement the entity identification results.

[0070] In some embodiments, the server may use at least one of the following as the subject identifier: module name, process name, shared library name, service name, package identifier, and vendor identifier, and establish a correspondence between the subject identifier and the subject category. For example, the module name may correspond to the kernel module category, the daemon name may correspond to the user-space daemon category, and the shared library name may correspond to the dynamic library category. This facilitates the subsequent unification of intrusion behaviors at different levels under the same third-party security software subject.

[0071] When auditing intrusion behavior, the server can establish an audit scope around critical execution paths. This audit scope can cover at least one or more of the following: out-of-tree kernel modules, unsigned modules, kernel entities using kprobe, kretprobe, ftrace or similar dynamic instrumentation mechanisms, entities modifying system call tables or other critical dispatch tables, entities registering sensitive notification chains, entities capturing sensitive addresses using symbol resolution capabilities, entities registering executable format processing mechanisms or intercepting execution loading chains, entities registering fanotify permission events or seccomp user-space notifications, entities affecting critical function paths using LD_PRELOAD or other shared library injection methods, and entities performing ptrace injection, proxy wrapping, environment rewriting, or critical library replacement on critical processes.

[0072] S206: Based on the audit results of the intrusion behavior, construct a structured intrusion profile of the third-party security software entity.

[0073] After obtaining the audit results of intrusion behavior, the server does not stop at the level of the original log list. Instead, it aggregates, normalizes, and structures multiple intrusion behaviors corresponding to the same third-party security software entity to form a structured intrusion profile. This allows the scattered module callback, injection, blocking, and path rewriting information to be uniformly transformed into a reusable profile result.

[0074] The structured intrusion profile includes at least one or more of the following fields: subject identifier, subject category, intrusion level, intrusion target, intrusion method, and potential impact failure type associated with the intrusion behavior. The server can then record at least one of these fields for each intrusion behavior to construct a structured intrusion profile.

[0075] In some embodiments, the subject identifier includes module name, process name, shared library name, service name, vendor name, or package identifier. Subject categories include kernel modules, user-mode daemons, dynamic libraries, injectors, or execution interceptors. Intrusion levels include kernel layer, system call layer, execution loading layer, user-mode library layer, or access decision layer. Intrusion targets include specific system calls, kernel symbols, notifier chains, executable file format types (binfmt type), C runtime library (libc) functions, file access events, or target processes. Intrusion methods include hooking, replacing, registering, redirecting, intercepting, or blocking.

[0076] In some embodiments, the structured intrusion profile may further include intrusion intensity, basic risk weight, evidence index, most recent occurrence time, persistent status, or historical changes. The evidence index may include the source file, registration location, symbol name, rule hit number, or snapshot number.

[0077] In some embodiments, intrusion profiling can be implemented using an explicit rule model, a scoring model, a graph model, or a hybrid rule-and-scoring model. This application does not limit the specific construction method of the intrusion profiling, as long as it can express the structured relationship between the intruding entity and the fault type.

[0078] In some embodiments, a structured intrusion profile includes at least one of the following: intrusion target, intrusion method, intrusion level, and potential impact failure type associated with the intrusion behavior. For example, if an entity intercepts high-frequency file access paths via a fanotify permission event, the intrusion target could be the target directory or related access event, the intrusion method could be Block or Intercept, the intrusion level could be the access decision layer, and the potential impact failure type could include task suspension failures or long-term freeze failures. If an entity modifies a system call dispatch table, the intrusion target could be the corresponding system call entry point, the intrusion method could be Replace or Redirect, the intrusion level could be the system call layer, and the potential impact failure type could include kernel crash failures or oops failures.

[0079] In some embodiments, considering that different intrusion behaviors have different degrees of interference with the system execution path, the server obtains the intrusion behavior of the third-party security software entity on the critical execution path of the operating system, and classifies the level according to the degree of interference of the intrusion behavior on the system execution path. The level includes at least synchronous blocking intrusion and asynchronous blocking intrusion.

[0080] Synchronous blocking intrusion refers to inserting synchronous waiting points into the critical execution path of a system, requiring a response from external logic before execution can continue. This can involve introducing synchronous waiting into the existing execution path, causing system calls, file accesses, execution loading, or decision-making processes that should complete quickly to wait for results from user space or external logic before proceeding. For example, an entity might use the fanotify permission event to intercept access to a critical directory, requiring the access thread to wait for a permission result from the user-space daemon. Another example is an entity using seccomp user-space notifications to forward a specified system call to a user-space review process before deciding whether to continue execution. These types of behaviors can be classified as synchronous blocking intrusions.

[0081] In some embodiments, asynchronous blocking intrusions can further include call chain extension, path rewriting, address hijacking, and read-only observation. For example, actions that only add callbacks to the notification chain without blocking the original execution path can be classified as call chain extension; actions that replace the original processing function with other processing functions, modify the system call entry point, or change the execution loading decision logic can be classified as path rewriting or address hijacking; actions that only record events without changing the execution result can be classified as read-only observation.

[0082] For example, in some embodiments, the server detects that a third-party security software entity has loaded an external module and redirected a target function in a critical file access path using ftrace. The server can record this intrusion as the target function name, the intrusion method as path rewriting, the intrusion level as the kernel layer, and the interference level as asynchronous blocking intrusion. As another example, if the server detects that a third-party security software entity has registered a fanotify permission event on a high-frequency file access directory, and the access process requires confirmation from a user-space daemon, the server can record this intrusion method as interception and blocking, and the interference level as synchronous blocking intrusion.

[0083] In some embodiments, before constructing a structured intrusion profile, the server may also map the audit results to a preset risk dimension, which includes at least the risk of blocking amplification and the risk of call chain expansion.

[0084] The blocking amplification risk characterizes the risk of transforming an execution path that could originally return quickly from kernel mode into a synchronous path that relies on user-mode responses. The call chain extension risk characterizes the latency and race conditions introduced by adding external callbacks or additional logic to the existing execution path. In some embodiments, blocking amplification risk can characterize the degree to which synchronous blocking intrusions on high-frequency paths may lead to amplified waiting, amplified queuing, thread backlog, or task suspension. For example, the risk of a fanotify permission event is relatively low if it operates on a low-frequency directory access path; however, if it operates on an execution loading path or a high-frequency file access path, the blocking amplification risk can be mapped to a higher value. The call chain extension risk characterizes the impact of additional callbacks, notification chain extensions, or multi-layered wrapping on the complexity of the system call chain, the scope of fault propagation, and the difficulty of debugging. For example, registering additional logic on a panic notification chain, module notification chain, or network device notification chain may introduce additional call stack bloat and anomaly propagation risks.

[0085] In practice, the server can configure discrete levels or numerical scores for different risk dimensions. For example, it can be mapped to three levels: low, medium, and high, or to a score range of 0 to 100. The risk dimension mapped by this audit result is used to determine the matching result. For example, the risk dimension can serve as a supplementary field in the structured intrusion profile, or as a weighted reference in subsequent matching and sorting.

[0086] In some embodiments, the structured intrusion profile also includes a predefined mapping between intrusion types and potentially impactful fault types. This mapping includes at least: a first mapping between synchronous blocking intrusions and task suspension faults, and a second mapping between execution path rewriting intrusions and kernel crash faults.

[0087] Synchronous blocking intrusions correspond to task suspension failures because the essence of these intrusions is synchronous blocking, meaning external waiting prevents the system from proceeding on its own. Execution path rewriting intrusions correspond to kernel crash failures because the essence of these intrusions is path rewriting, meaning the original kernel logic is replaced or execution is redirected to untrusted or flawed third-party code.

[0088] In some embodiments, the server can pre-maintain a set of mapping rules: when the intrusion type is a synchronous blocking intrusion, and the intrusion object is located in the execution loading path, file access path, or access decision path, a high-correlation mapping is established between it and task suspension failures, long-term freeze failures, or execution blocking failures; when the intrusion type is an execution path rewriting intrusion, and the intrusion level is at the kernel level or system call level, a high-correlation mapping is established between it and kernel crash failures, oops failures, or deadlock failures. Furthermore, when the intrusion type is shared library replacement or process injection, a mapping can also be established with user-mode crash failures or execution exception failures.

[0089] In some embodiments, synchronous blocking intrusions may include fanotify permission events, seccomp user notifications, etc. The task suspension failures associated with these synchronous blocking intrusions may be hung task, exec blocking, or long-term lag.

[0090] In some embodiments, kernel crashes can be further subdivided into kernel crash subclasses, process crash subclasses, and startup failure subclasses. Path rewriting intrusions may include syscall table rewriting, kprobe instrumentation, and address hijacking. These path rewriting intrusions are associated with kernel crash subclasses, such as panic, oops, and deadlock. Path rewriting intrusions may include LD_PRELOAD, libc replacement, and ptrace injection. These path rewriting intrusions are associated with process crash subclasses, such as coreedump and exec exceptions. Path rewriting intrusions may include binfmt registration and startup link hijacking. These path rewriting intrusions are associated with startup failure subclasses, such as startup exceptions and service start-up failures.

[0091] It should be noted that the above mapping relationship can be achieved through manually preset rules, historical case statistics, expert experience summarization, or a combination of rules and scoring. By setting the mapping relationship in the above embodiments, the system can quickly trace back to the most relevant intrusion object from the fault type after a fault occurs, instead of indiscriminately investigating all security software behaviors. This makes fault diagnosis more targeted and improves troubleshooting efficiency.

[0092] To enhance feasibility, an optional data organization method is presented below. The server can maintain a profile object for each third-party security software entity. This profile object may include fields such as: entity identifier, entity category, intrusion level set, intrusion object set, intrusion method set, risk dimension results, potential impact failure type set, predefined mapping relationships, evidence index, recent occurrence time, and persistent existence status. The field names are not limited; they only need to express the semantics of the structured intrusion profile.

[0093] In some embodiments, when system stability issues occur, the following methods can be adopted: Figure 2 The process shown extracts fault scene information corresponding to abnormal events and forms a structured fault scene summary. That is, the above S200 can further include S2001-S2004.

[0094] S2001: Detect fault type.

[0095] Fault types can include panic, oops, hung task, deadlock, long-term freeze, startup exception, critical service exception, or application coredump, etc.

[0096] S2002: Collect fault site information corresponding to the fault type.

[0097] For panic and oops, abnormal CPU, abnormal process, kernel call stack, related module name, error address and symbol information can be extracted; for hung task or deadlock, blocked thread, waiting object, lock chain, call stack and waiting duration can be extracted; for coredump, crashed process, shared library mapping, crashed function, signal type and execution context can be extracted; for startup exception, early module loading information, exec path information, critical service status and failure stage can be extracted.

[0098] S2003: Extract time window information related to the fault scene information.

[0099] The time window information can be the intrusion behavior changes, module loading, callback registration, configuration rewriting or injection events within a preset time before the failure occurs.

[0100] S2004: Based on the time window information, normalize the fault scene information to form a fault scene summary.

[0101] The fault scene summary includes at least the fault type, object identifier, path summary, blockage point or stack summary, time window, and available evidence index. Based on the time window information, the fault scene summary within a unit of time can be determined, so that it can be compared in the subsequent matching stage based on the fault scene summary in a unified format.

[0102] In some embodiments, the matching in step S202 above can be based on one or more of object matching, path matching, blocking chain matching, type matching, time window matching, and risk dimension matching.

[0103] Object hit refers to whether the fault objects recorded in the fault scene summary are consistent with or correspond to the intrusion objects in the structured intrusion profile. For example, if a module name, shared library name, key function name, notification chain object name, or target directory name appears in the fault scene, and these objects are the same as or can be mapped to the intrusion objects in the profile, it can be considered an object hit.

[0104] Path hit refers to whether the key execution path information in the fault scene summary falls within the scope of the intrusion path described in the structured intrusion profile. For example, a panic stack frame hitting the hooked target function path, a startup failure path hitting the intercepted exec loading path, and a critical library function path adjacent to the crashed function being replaced can all be considered path hits.

[0105] A blocking chain hit refers to whether the waiting objects in a hung task, deadlock, or stagnation scenario are related to fanotifypermission, user-mode decision daemons, or synchronization check logic.

[0106] Type matching refers to whether the fault type in the fault scene summary matches the potential impact fault type or predefined mapping relationship in the structured intrusion profile. For example, if the profile shows a high correlation between synchronous blocking intrusions and task suspension faults, and the fault type in the current fault scene summary is a task suspension fault, then this can be considered type matching.

[0107] Temporal proximity refers to whether there are new loadings, new registrations, new injections, or configuration changes of relevant entities before the failure occurs.

[0108] Exclusivity refers to the existence of stronger non-security software candidate root causes. In some embodiments, the fault scene summary is matched with a structured intrusion profile, including an exclusiveness assessment. The server then determines whether there are candidate root causes that are more correlated with the abnormal event and are not from third-party security software entities. If not, the correlation level of the third-party security software entity is increased. In this embodiment, the exclusiveness-based reverse check for other non-security software causes can better explain the fault, thus avoiding blind attribution and improving the accuracy and efficiency of fault attribution.

[0109] Time window matching refers to whether there are any new loading, registration, injection, configuration rewriting, or other intrusion behaviors related to the third-party security software within a preset time window before the occurrence of the abnormal event. If so, it indicates that the software and the abnormal event have a higher temporal proximity.

[0110] In some embodiments, in step S202 above, matching is performed at least through blocking chain match. Matching the fault scene summary with the structured intrusion profile includes: determining whether the blocking waiting object or blocking function recorded in the fault scene summary has a consistent call path relationship with the synchronization blocking point created by the third-party security software entity recorded in the structured intrusion profile.

[0111] The consistent call path relationship here can be understood as a direct correspondence, contiguous proximity, or traceability to the same blocking mechanism between the blocked path in the fault scene and the synchronous blocking point in the profile. For example, if the blocking function recorded in the fault scene summary is a fanotify wait function, and the structured intrusion profile records that the third-party security software entity registered a fanotify permission event and created a synchronous blocking point on the same file access path, then a blocking chain match can be established. Similarly, if a thread is blocked in the fault scene waiting for a user-mode decision to return, and the profile records that the entity created a system call blocking point through the seccomp user-mode notification mechanism, then a consistent relationship can be established between the two through call path tracing.

[0112] In some embodiments, the server may employ one or more of the following matching methods.

[0113] Method 1, based on equality matching. This involves directly comparing the object name, function name, path identifier, and module name in the fault scene summary with the corresponding fields in the profile. This method is simple to implement and suitable for directly matching scenarios.

[0114] Method two is based on topology tracing and matching. This means that when fields are not completely identical, but can be proven to be on the same execution path through call chain backtracking, path relationships, symbol mapping, or registration source relationships, a match is determined. For example, if the fault scene shows a waiting function A, while the profile records a blocking point B created by that entity, and if A calls B or B is located on the upstream critical path of A, then a path match can be determined.

[0115] Method 3 is based on multi-dimensional scoring matching. The server can assign weights to object matching, path matching, blocking chain matching, type matching, and time window matching, and calculate a comprehensive matching score. When the score is higher than a preset threshold, it is determined that there is a high correlation; when the score is in the middle range, it is determined that it is highly suspicious; when the score is low, it is determined that there is a possibility or low correlation. This method is particularly suitable for scenarios where the evidence is not entirely direct, but multiple weak pieces of evidence are superimposed.

[0116] For example, in a Class A system, a third-party security software entity intercepts the execution of the loading path via a fanotify permission event. Subsequently, the system experiences task hangs under high load. After extracting the fault summary, the server finds that multiple threads are blocked on wait functions related to the fanotify response, with the wait objects pointing to the same access decision point on the same path, and the entity had recently updated the relevant policy configuration shortly before the fault occurred. In this case, the server can simultaneously match the blocking chain, type, and time window, and increase the association level between this entity and the abnormal event.

[0117] When outputting the association level, in some embodiments, the first level is output when the matching result shows that the fault scene summary directly matches the intrusion object or synchronization blockage point in the structured intrusion profile; the second level is output when the matching result shows that the path category, fault type and time window match but there is no direct match.

[0118] The first level indicates a high degree of correlation. For example, it can be understood as explicit correlation, direct correlation, or high-confidence correlation. This usually means that the intrusion target, synchronization blockage point, critical symbol, or direct path hit corresponding to the third-party security software has appeared at the fault site.

[0119] The second level can represent the result of the second highest degree of correlation. For example, it can be understood as highly suspicious or relatively correlated. This type of situation usually means that although there is no specific intrusion object or synchronization blockage point directly present in the fault scene, the path category, fault type, time window, and profile characteristics are highly consistent, and there is a lack of stronger candidate root causes.

[0120] In some embodiments, the server can further extend to other levels, such as possible, low relevance, or no obvious correlation, to accommodate richer engineering output requirements. This is provided that the basic division logic between the first and second levels satisfies the above conditions.

[0121] In some embodiments, the associated evidence can be a chain of evidence containing a description of the matching reason. That is, when outputting associated evidence, the server outputs the associated evidence in the form of a chain of evidence containing a description of the matching reason. This chain of evidence may include, but is not limited to: the candidate third-party security software entity identifier, the hit intrusion object, the hit blocking function or blocking waiting object, the hit call path relationship, the hit fault type mapping, the time window hit description, the risk dimension description, and the suggested troubleshooting actions.

[0122] For example, in a hung task scenario, the server's output evidence may include the following: the candidate subject is a third-party daemon process and its associated modules; the hit intrusion object is the target file access path; the hit synchronous blocking point is the fanotify permission event waiting point; the hit fault evidence is that multiple blocked threads stay in the same waiting function for more than a threshold; the matching reason is explained as "the blocking function at the fault scene has a consistent call path relationship with the synchronous blocking point in the profile, and the fault type is consistent with the task suspension fault mapping corresponding to the synchronous blocking intrusion"; the suggested troubleshooting action is to temporarily disable the blocking strategy and then reproduce and verify it.

[0123] For example, in a panic scenario, the evidence output by the server may include: the candidate subject is a module outside the tree; the target of the intrusion is a critical kernel function; the evidence of the fault is the presence of the module's symbol and the rewritten target function in the panic stack; the reason for the match is explained as "the fault scene directly hits the intrusion object, and the execution path rewriting type intrusion is consistent with the kernel crash type fault mapping"; the suggested troubleshooting action is to first uninstall the module and then re-verify.

[0124] To further illustrate the feasibility of this application, several typical embodiments are given below.

[0125] Example 1: Attribution example of a task suspension failure caused by synchronous blocking intrusion.

[0126] The server detected during runtime that a third-party security software entity consisted of a user-space daemon and a kernel coordinating component. Audit results showed that this entity registered fanotify permission events on critical directories, creating a synchronous blocking intrusion on high-frequency file access paths. When constructing a structured intrusion profile, the server recorded the intrusion target as the target directory access event, the intrusion methods as Intercept and Block, the intrusion level as the access decision layer, and the potential impact failure types as task suspension failures. A mapping relationship was established between synchronous blocking intrusions and task suspension failures.

[0127] Subsequently, the server detected a task suspension exception. The fault scene information showed that multiple threads were blocked for an extended period on wait functions related to the `fanotify` response, and the blocked wait objects could be traced back to the same file access path. After generating a fault scene summary, the server matched it against the structured intrusion profile. It found that both the blocked wait objects and the blocking functions had consistent call path relationships with the synchronization blocking points in the profile, thus directly matching the blocking chain. Based on this, the server output a first-level error and outputs the synchronization blocking point of the entity, the matched wait function, the faulty thread stack summary, and an explanation of the matching reason in the form of an evidence chain.

[0128] Example 2: An example of attribution for kernel crash-type failures caused by execution path rewriting intrusion.

[0129] The server detected that a third-party security software entity loaded an external kernel module and redirected the target function in the critical path of kernel file access using ftrace. The server audited this intrusion and determined it to be an execution path rewriting intrusion, targeting the target function at the kernel level, with potential impact types including kernel crashes. The server further mapped this audit result to call chain extension risks and execution path rewriting risks, incorporating them into a structured intrusion profile.

[0130] The system subsequently panicked. The server extracted key stack frames from the panic logs and found that the module symbol and target function from outside the tree directly appeared in the stack. After generating a fault scene summary, the server found that the faulty object and key execution path information directly matched the intrusion object in the structured intrusion profile, and the fault type was consistent with the predefined mapping in the profile. Therefore, the server output a first-level alert and output related evidence including module symbol hits, target function hits, panic stack summaries, and explanations of the matching reasons.

[0131] Example 3: Attribution example of a shared library injection causing a core dump failure in the application.

[0132] During runtime, the server detected that a third-party security software entity injected into a shared library through pre-loaded configuration, intruding into the user-space critical library path. The server audit revealed that the intrusion targets included the paths of the `open` and `execve` functions, the intrusion method was `Replace`, and the intrusion level was the user-space critical library layer. When constructing a structured intrusion profile, the server can categorize potential impact fault types as application core dump faults and execution exception faults.

[0133] When a core dump of an application occurs in a business process, the server extracts shared library mappings, crashed functions, and execution contexts. It finds that preloaded shared libraries are located in the process mapping, and the crashed function is adjacent to the path of the replaced critical function. While there may not be a direct match with fields exactly identical to those in the process profile, the path category, fault type, and time window show a high degree of similarity. Based on this, the server can output a second-level alert, and output the shared library mapping match, crashed function proximity, fault type compatibility, and time window description as corroborating evidence.

[0134] In addition to the embodiments described above, the method of this application can also be applied to various scenarios such as startup anomalies caused by binfmt interception, OOPs caused by syscall dispatch table rewriting, and amplification of anomaly propagation due to notification chain expansion. In different scenarios, the server can follow a unified logic of "identifying the subject - auditing intrusion behavior - constructing a structured intrusion profile - extracting a summary of the fault scene - multi-dimensional matching - outputting the association level and related evidence" to achieve standardized attribution.

[0135] It should be noted that in the engineering implementation, the server can either continuously maintain the intrusion profile using a persistent daemon approach, or obtain audit results using scheduled snapshots, event subscriptions, offline image parsing, or a hybrid approach. Fault scene extraction can be performed in real-time after an anomaly occurs, or key summaries can be pre-stored using a lightweight caching mechanism. Matching can be implemented using a rule engine, a scoring model, or a combination of both. None of these changes affect the core technical concept of this application.

[0136] based on Figure 1 The method described first identifies the installed third-party security software entity and audits its intrusion behavior into the critical execution paths of the operating system. Then, based on the audit results of the intrusion behavior, a structured intrusion profile of the third-party security software entity is constructed. When an abnormal event is detected in the operating system, the fault scene information corresponding to the abnormal event is extracted and a structured fault scene summary is formed. Finally, the fault scene summary is matched with the structured intrusion profile, and the correlation level and correlation evidence between the third-party security software entity and the abnormal event are output according to the matching results.

[0137] The above method allows for the unified aggregation of scattered intrusion detection results into a reusable, structured intrusion profile. After a fault occurs, the fault scene is automatically matched with the intrusion profile. This goes beyond simply identifying the presence of third-party security software in the system; it further determines whether the third-party security software has a technical connection to the current anomaly, the degree of that connection, and the basis for that connection. This reduces the cost of manual cross-analysis and improves the accuracy, consistency, and interpretability of fault attribution.

[0138] Figure 3 This is an example flowchart of an operating system fault attribution method provided in an embodiment of this application. See below for reference. Figure 3 The fault attribution method of this application will be further explained.

[0139] like Figure 3As shown, after the system starts, the diagnostic service of the fault attribution method immediately enters normal operation. First, the server traverses the / proc / modules file, scans the process directory tree under the / proc file system and system service unit files, and identifies the entities related to third-party security software that have been installed or loaded, including external kernel modules (external ko), user-space daemons, dynamic libraries injected through LD_PRELOAD (dynamic linker preloading), and security components registered in the form of systemd services.

[0140] After identifying the entities, the server audits each entity's intrusion behavior into critical operating system execution paths. Specifically, the system checks whether these entities have inserted probe logic into critical kernel functions using kprobe (kernel dynamic probe), kretprobe (kernel return probe), or ftrace (kernel function tracing framework); whether they have modified the entry points of processing functions in the syscall table; whether they have registered callback functions on sensitive kernel notification chains; whether they have registered custom executable file format handlers (binfmt) to interfere with the exec (execution loading) path; whether they have set fanotify (file access notification mechanism) synchronization permission events or enabled the seccomp (secure computing mode) user-space notification mechanism; and whether they have modified the execution path of critical user-space processes through the LD_PRELOAD environment variable or the ptrace system call.

[0141] After the audit is completed, the server maps each discovered intrusion behavior to a preset risk dimension. Mechanisms such as fanotify synchronization permission events are mapped as blocking amplification risks; kprobe instrumentation on the scheduling core function is mapped as call chain extension risks; and replacement of the system call table is mapped as execution path rewriting risks. Based on these mapping results, the server constructs a structured intrusion profile for each third-party security software entity. The profile records the entity identifier, entity category, intrusion level, intrusion target, intrusion method, intrusion strength, a set of potential impact fault types, and a basic risk score calculated based on preset weights for the intrusion method and risk dimension.

[0142] During healthy system operation, the diagnostic service of the fault attribution method continuously monitors for any stability anomalies. If no anomalies are detected, the currently constructed intrusion profile is saved to local storage for matching in the event of a subsequent fault. Then, the current audit cycle ends and the next cycle begins.

[0143] If an abnormal event is detected in the system, such as a "hung task" alert in the kernel log, the fault scene extraction process is immediately triggered. The server first determines that the fault type is a "hung task," then collects the kernel call stack of the corresponding process, the wait objects and lock links of the blocked threads, the shared library memory mapping information of the process, and extracts module loading and injection event records within a preset time window before the fault occurred. After parsing and normalization, the above information forms a structured fault scene summary containing the fault type, fault object identifier, critical path summary, blocking point information, and time window.

[0144] After the fault scene summary is generated, the server performs a multi-dimensional match against all stored intrusion profiles. First, object match is performed to determine if the hung task process belongs to the range of affected processes recorded in a particular intrusion profile. Next, path match is performed to check if the intrusion object recorded in the intrusion profile appears in the kernel call stack of the hung task process. Then, blocking relationship match is performed to determine if the process's blocking wait point forms the same call path as the synchronous blocking mechanism recorded in the intrusion profile. Simultaneously, the server also performs type match and time proximity match to check if the fault type belongs to the predefined set of highly correlated fault types in the intrusion profile, and whether there were any new registrations or configuration changes of related intrusion subjects before the fault occurred.

[0145] After matching is complete, the server performs a weighted calculation on the matching results across each dimension to determine the association level. If a blocking relationship match is successful, meaning the call stack of the hung task process shows that it is blocked on a fanotify synchronization permission event processing path registered by a certain security software, the server determines it to have hit a high-risk blocking path and outputs a clear association conclusion. Subsequently, the system generates a complete chain of evidence containing the candidate security software entity name, the matched fanotify monitoring point information, the matched blocking thread stack evidence, the association rule description, and the risk level. Simultaneously, it extracts corresponding troubleshooting suggestions from a pre-built knowledge base, explicitly recommending uninstalling the relevant kernel module or contacting the security software vendor for an updated version.

[0146] If the matching results show that there is only an object match but lack evidence of path match and blocking relationship, the server determines that there is a possibility, outputs a low-risk conclusion and records the candidate subject and supporting evidence for operation and maintenance personnel to refer to and investigate. Figure 3 The fault attribution process shown here has now ended.

[0147] The following is a data structure example of the operating system fault attribution method of this application. This data structure example is only an exemplary implementation method, and this application is not limited to specific field names, encoding forms or storage methods.

[0148] struct intrusion_audit_record{ u64 record_id; / / Audit record identifier u64 timestamp_ns; / / Record timestamps char subject_name

[128] ; / / Subject name u32 subject_type; / / Subject type u32 intrusion_layer; / / Intrusion layer char target_name

[128] ; / / Intrusion target u32 intrusion_mode; / / Hook / Replace / Register / Block, etc. u32 intrusion_strength; / / Intrusion strength u32 source_type; / / Source type }; struct intrusion_profile{ u64 profile_id; / / Profile identifier char subject_name

[128] ; / / Subject name u32 base_risk_score; / / Base risk score u64 fault_type_bitmap; / / Collection of fault types u32 key_path_class; / / Key path category u32 evidence_count; / / Number of pieces of evidence }; struct fault_scene_summary{ u32 fault_type; / / Fault type char object_name

[128] ; / / Fault object char stack_digest

[256] ; / / Stack digest char wait_point

[128] ; / / Blocking point or waiting object u64 time_window_start_ns; / / Start point of the time window u64 time_window_end_ns; / / End point of the time window }; struct correlation_result{ char subject_name

[128] ; / / Candidate subject u32 relation_level; / / Relationship level u32 matched_rule_id; / / Matching rule u32 matched_count; / / Number of matches char risk_summary

[256] ; / / Risk description char suggestion

[256] ; / / Troubleshooting suggestion }; In some embodiments, this application Figure 1 Operating system failure attribution methods can be modularly encapsulated, such as... Figure 4 As shown, the system can be designed as follows: Intrusion Target Discovery Module 901, Intrusion Behavior Audit Module 902, Risk Dimension Mapping Module 903, Intrusion Profile Construction Module 904, Fault Detection and On-Site Extraction Module 905, Fault On-Site Extraction Module 906, Association Matching Module 907, Association Delineation Module 908, and Result Output Module 909. Specifically, the Intrusion Target Discovery Module 901, Intrusion Behavior Audit Module 902, and Risk Dimension Mapping Module 903 form the intrusion discovery and auditing chain; the Intrusion Profile Construction Module 904, Fault Detection and On-Site Extraction Module 905, and Fault On-Site Extraction Module 906 form the profile construction and fault collection chain; and the Association Matching Module 907, Association Delineation Module 908, and Result Output Module 909 form the association delineation and result output chain. The functions of each module are as follows.

[0149] Intrusion Target Discovery Module 901: Used to discover third-party security software-related entities in the system, including external kernel modules (external ko), user-mode daemons, dynamic libraries, pre-loaded configurations, injection processes, registration services, and related vendor identifiers. For example, in one embodiment, it can be used to identify external ko, user-mode daemons, dynamic libraries, pre-loaded configurations, and registration services.

[0150] Intrusion behavior audit module 902: Used to identify whether the subject hooks, replaces, registers, redirects, intercepts, or synchronously blocks critical execution paths, and generates audit logs. For example, in one embodiment, it can be used to audit behaviors such as kernel probes (kprobe), system call tables (syscall table), notifiers, binary execution formats (binfmt), file access notifications (fanotify), preloading, and process tracing (ptrace).

[0151] Risk Dimension Mapping Module 903: Maps execution path rewriting risk, blocking amplification risk, and call chain extension risk.

[0152] Intrusion Profiling Module 904: Used to build a structured intrusion profile based on audit records, forming the intrusion subject, intrusion level, intrusion target, intrusion method, intrusion intensity, potential impact failure type, and basic risk score required for subsequent attribution.

[0153] Fault Detection and On-Site Extraction Module 905: Detects kernel panic, kernel oops, hung task, deadlock, startup exception, and kernel dump.

[0154] The fault scene extraction module 906 is used to extract the panic stack, oops stack, hungtask stack, deadlock wait chain, watchdog scene, coredump summary, abnormal process, trigger time window, and related system states after detecting a stability anomaly. For example, in one embodiment, it can be used to extract the call stack, blocking chain, wait object, shared mapping window, and time window.

[0155] The association matching module 907 is used to match the fault scene with the intrusion profile according to object hit, path hit, callback hit, blocking relationship, time proximity and fault type adaptation relationship.

[0156] Association Determination Module 908: Used to output a conclusion of explicit association, highly suspicious, or possible association based on the matching results, and provide evidence of association. For example, in one embodiment, it can be used to output a conclusion of explicit association, highly suspicious, possible association, or low correlation.

[0157] Result output module 909: Used to generate structured diagnostic results, outputting candidate subjects, hit intrusion points, hit evidence, correlation level, risk description, and troubleshooting suggestions to a local reporting, logging system, or operations and maintenance platform. For example, in one embodiment, it can be used to output candidate subjects, hit evidence, risk level, and troubleshooting suggestions for third-party security software.

[0158] Figure 5 This application provides a corresponding embodiment. Figure 4 A schematic diagram of the timing interactions of each module.

[0159] like Figure 5 As shown, after the process starts, the intrusion object discovery module first scans the system for third-party modules, processes, dynamic libraries, preloaded items, and registration behaviors, and transfers any suspicious objects to the intrusion behavior auditing module. Upon receiving the objects, the auditing module internally audits the intrusion methods on critical paths, focusing on identifying four typical intrusion techniques: Hook hijacking, Replace function or symbol substitution, illegal Register callbacks or drivers, and Block blocking critical paths. After the audit is completed, the auditing module submits the complete intrusion audit log to the intrusion profiling module. This module internally summarizes the information, constructs an intrusion profile, and establishes a mapping relationship between intrusion types and fault types. For example, certain types of hooks are prone to causing panics, and certain types of blocks are prone to causing hung tasks, thus providing a basis for predicting subsequent fault associations.

[0160] The sequence diagram then follows a conditional branch, leading to two different paths depending on the system's current state. During normal system operation, the intrusion profile construction module directly sends the constructed intrusion profile and risk summary to the result output module for storage. This means that even if no faults occur at present, the system will continuously archive detected intrusion behaviors as potential risks, preserving traceable historical evidence for any subsequent anomalies.

[0161] During the stability anomaly detection phase, the core fault root cause localization process begins. At this stage, the fault scene extraction module first internally captures the fault scene, covering various typical stability anomalies such as panic (kernel panic), oops (illegal kernel access), hung tasks (tasks not scheduled for extended periods), deadlock, startup anomalies, and coredump (user-space process crash dump). It then submits the compiled fault scene summary to the correlation identification module. Simultaneously, the intrusion profile construction module provides the correlation identification module with previously constructed and saved intrusion profiles and historical evidence. After receiving inputs from both sides, the correlation identification module internally performs multi-dimensional correlation matching, specifically including four dimensions: object hit, path hit, blocking relationship, and temporal proximity, to determine whether a causal relationship exists between the intrusion behavior and the fault. After matching is complete, the correlation identification module outputs the final conclusion to the result output module, including four items: correlation level, hit evidence, candidate responsible parties, and troubleshooting suggestions.

[0162] Understandable, based on Figure 5The method shown allows for quick identification of which third-party module caused the system anomaly without starting from scratch when a fault occurs. It simply involves matching the current situation with existing profiles.

[0163] This application also provides an operating system fault attribution device, such as... Figure 6 As shown. The device includes the following modules.

[0164] The fault scene extraction module 600 is used to extract fault scene information corresponding to the abnormal event in response to the detection of an abnormal event in the operating system, and form a structured fault scene summary; wherein, the fault scene summary includes at least the fault type, the fault object, and key execution path information; The matching module 602 is used to determine at least one preset risk dimension, match the fault scene summary with the pre-stored structured intrusion profile of the third-party security software subject for the at least one risk dimension, and output the association level and association evidence between the third-party security software subject and the abnormal event based on the matching result.

[0165] Optionally, the device further includes an audit module 604 and a profile building module 606.

[0166] The audit module 604 is used to identify installed third-party security software entities and audit their intrusion behavior into critical execution paths of the operating system. The profile construction module 606 is used to construct a structured intrusion profile of the third-party security software entity based on the audit results of the intrusion behavior. The structured intrusion profile includes at least one of the following: intrusion target, intrusion method, intrusion level, and potential impact failure type associated with the intrusion behavior.

[0167] Optionally, the audit module 604 is specifically used to obtain the intrusion behavior of the third-party security software entity into the critical execution path of the operating system, and classify the level according to the degree of interference of the intrusion behavior into the system execution path, wherein the level includes at least synchronous blocking intrusion and asynchronous blocking intrusion.

[0168] Optionally, the profile building module 606 is specifically used to map the audit results to a preset risk dimension, wherein the risk dimension includes at least blocking amplification risk and call chain extension risk, and the risk dimension mapped by the audit results is used to determine the matching results.

[0169] Optionally, the structured intrusion profile further includes a predefined mapping relationship between intrusion types and potentially impactful fault types. This mapping relationship includes at least: a first mapping between synchronous blocking intrusions and task suspension faults, and a second mapping between execution path rewriting intrusions and kernel crash faults.

[0170] Optionally, matching can be performed at least through blocking chain match. Specifically, the matching module 602 is used to determine whether the blocking waiting object or blocking function recorded in the fault scene summary has a consistent call path relationship with the synchronous blocking point created by the third-party security software entity recorded in the structured intrusion profile.

[0171] Optionally, the matching module 602 is specifically used to output a first level when the matching result shows that the fault scene summary directly hits the intrusion object or synchronous blockage point in the structured intrusion profile, output a second level when the matching result shows that the path category, fault type and time window are highly matched but there is no direct hit, and / or output an evidence chain containing a description of the matching reason.

[0172] Optionally, the matching module 602 is specifically used to detect the fault type, collect fault scene information corresponding to the fault type, extract time window information related to the fault scene information, and normalize the fault scene information according to the time window information to form a fault scene summary.

[0173] based on Figure 6 The device shown contains multi-dimensional information in the fault scene summary. By matching the fault scene summary with the multi-dimensional intrusion profile, it can accurately determine whether there is a correlation between the fault scene and the intrusion point where the third-party security software performs intrusion behavior on the critical execution path of the operating system. This helps maintenance personnel to quickly locate the third-party security software that has committed the intrusion behavior, which facilitates subsequent targeted troubleshooting measures.

[0174] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 1 The provided operating system failure attribution method.

[0175] This instruction manual also provides Figure 7 The diagram shows a schematic structural representation of the electronic device. Figure 7 As shown, at the hardware level, this electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above. Figure 1 The operating system fault attribution method described herein. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0176] This application also provides a computer program product comprising a computer program that is implemented when executed by a processor. Figure 1 The provided operating system failure attribution method.

[0177] Improvements in a technology can be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology can now be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement in methodology cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0178] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0179] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0180] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0181] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0182] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0183] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0184] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0185] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0186] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0187] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0188] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, product, or apparatus that includes said element.

[0189] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0190] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0191] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0192] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this application.

Claims

1. A method for attributing operating system failures, characterized in that, include: In response to the detection of an abnormal event in the operating system, fault scene information corresponding to the abnormal event is extracted and a structured fault scene summary is formed, wherein the fault scene summary includes at least the fault type, the fault object, and key execution path information; Determine at least one preset risk dimension, match the fault scene summary with the pre-stored structured intrusion profile of the third-party security software subject according to the at least one risk dimension, and output the association level and association evidence between the third-party security software subject and the abnormal event based on the matching result.

2. The method as described in claim 1, characterized in that, Prior to detecting an abnormal event in the operating system, the method further includes: Identify installed third-party security software entities and audit their intrusion behavior into critical execution paths of the operating system; Based on the audit results of the intrusion behavior, a structured intrusion profile of the third-party security software entity is constructed. The structured intrusion profile includes at least one of the following: intrusion target, intrusion method, intrusion level, and potential impact failure type associated with the intrusion behavior.

3. The method as described in claim 2, characterized in that, Auditing the intrusion behavior of the third-party security software entity into the critical execution paths of the operating system, including: The system obtains information about the intrusion behavior of the third-party security software into the critical execution paths of the operating system. The levels of interference with the system execution path caused by the intrusion behavior are classified into at least synchronous blocking intrusion and asynchronous blocking intrusion.

4. The method as described in claim 2, characterized in that, Before constructing the structured intrusion profile of the third-party security software entity, the method further includes: The audit results are mapped to preset risk dimensions, wherein the risk dimensions include at least blocking amplification risk and call chain extension risk, and the risk dimensions mapped to the audit results are used to determine the matching results.

5. The method as described in claim 1, characterized in that, The structured intrusion profile also includes a predefined mapping relationship between intrusion types and potential impact fault types; the mapping relationship includes at least: a first mapping between synchronous blocking intrusions and task suspension faults, and a second mapping between execution path rewriting intrusions and kernel crash faults.

6. The method as described in claim 1, characterized in that, Matching is performed at least through blocking chain matching, matching the fault scene summary with a pre-stored structured intrusion profile of the third-party security software entity for at least one risk dimension, including: Determine whether the blocked waiting object or blocking function recorded in the fault scene summary has a consistent call path relationship with the synchronous blocking point created by the third-party security software entity recorded in the structured intrusion profile.

7. The method as described in claim 1, characterized in that, The output of the association level includes: When the matching results show that the fault scene summary directly matches the intrusion object or synchronization blockage point in the structured intrusion profile, the first level is output; when the matching results show that the path category, fault type, and time window match but there is no direct match, the second level is output; and / or Output the associated evidence, including: The output contains a chain of evidence explaining why the match occurred.

8. The method as described in claim 1, characterized in that, Extract the fault scene information corresponding to the abnormal event and form a structured fault scene summary, including: Detect the type of fault; Collect fault scene information corresponding to the fault type; Extract time window information related to the fault scene information; Based on the time window information, the fault scene information is normalized to form a fault scene summary.

9. An operating system fault attribution device, characterized in that, include: The fault scene extraction module is used to extract fault scene information corresponding to the abnormal event in response to the detection of an abnormal event in the operating system, and form a structured fault scene summary; wherein, the fault scene summary includes at least the fault type, the fault object, and key execution path information; The matching module is used to determine at least one preset risk dimension, match the fault scene summary with the pre-stored structured intrusion profile of the third-party security software subject for the at least one risk dimension, and output the association level and association evidence between the third-party security software subject and the abnormal event based on the matching result.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1 to 8.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 8.

Images