Kernel probe generation method, apparatus, computer equipment and storage medium

Abstract

This application discloses a kernel probe generation method, apparatus, computer device, and storage medium, relating to the field of operating system kernel monitoring technology. The method includes: responding to a kernel probe generation request, obtaining a target metadata file corresponding to the current operating system kernel; determining a target declarative policy file; determining a target program logic file corresponding to the target declarative policy file; and generating probe code based on the target program logic file and the target metadata file to obtain a kernel probe program. This application, by combining the target metadata file and the target declarative policy file, can dynamically generate probe program source code adapted to the current kernel version. This source code generation function decouples the kernel probe development logic from underlying kernel knowledge, eliminating the need for developers to deeply understand the kernel's internal data structures and version differences, thus lowering the development threshold. It supports not only specific operating systems or probe types but also the general Linux kernel and various probe types.

Description

Technical Field

[0001] This disclosure generally relates to the field of operating system kernel monitoring technology, and in particular to a kernel probe generation method, apparatus, computer device, and storage medium. Background Technology

[0002] Operating system kernel monitoring can help quickly locate performance bottlenecks and root causes of faults by tracing the system's running trajectory, monitor the usage of core resources such as the Central Processing Unit (CPU) and memory in real time, dynamically adjust load balancing strategies, and promptly send out potential security threats by monitoring data such as network browsing and program behavior. Therefore, how to implement operating system kernel monitoring is particularly important.

[0003] Traditional operating system kernel monitoring (such as security auditing and performance analysis) relies on developers manually writing kernel probe programs, which requires developers to have in-depth knowledge of operating system kernels; moreover, these kernel probe programs are written for fixed kernel versions, and cross-kernel version adaptation costs are high; in addition, these kernel probe programs use full monitoring mode, which leads to excessive performance overhead when the kernel probe programs run, while fine-grained monitoring requires customized coding and is difficult to adjust dynamically. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a kernel probe generation method, device, computer equipment and storage medium that can dynamically generate probe program source code adapted to the current kernel version by combining target metadata file and target declarative policy file. Through this source code generation function, the kernel probe development logic can be decoupled from the underlying kernel knowledge, and developers do not need to have an in-depth understanding of the kernel's internal data structure and version differences, thus lowering the development threshold. It not only supports specific operating systems or probe types, but also supports general Linux kernels and multiple probe types.

[0005] Firstly, this application provides a kernel probe generation method. The method includes:

[0006] In response to a kernel probe generation request, the target metadata file corresponding to the current operating system kernel is obtained; the target metadata file includes the mapping relationship between the current kernel version identifier and the layout of key data structures in the current kernel header file, the function symbol addresses in the current kernel symbol table, and the event parameter information in the current monitoring point information.

[0007] Determine the target declarative policy file; the target declarative policy file is used to enable the final generated kernel probe program to have runtime event filtering capabilities;

[0008] The target program logic file corresponding to the target declarative policy file is determined, and probe code is generated based on the target program logic file and the target metadata file to obtain the kernel probe program.

[0009] In conjunction with the first aspect, in one possible implementation, obtaining the target metadata file corresponding to the current operating system kernel includes:

[0010] Determine whether the current version identifier matches the kernel version identifier in the most recently updated metadata file;

[0011] If the current version identifier matches the kernel version identifier, then the most recently updated metadata file is determined as the target metadata file;

[0012] If the current version identifier does not match the kernel version identifier, then the target metadata of the current operating system kernel is collected, and the mapping relationship is constructed based on the target metadata and the current version identifier to obtain the target metadata file.

[0013] In conjunction with the first aspect, in one possible implementation, determining the target program logic file corresponding to the target declarative strategy file includes:

[0014] In the case where the target declarative strategy file includes probe type declaration fields, monitoring point declaration fields, monitoring point acquisition parameter declaration fields, and parameter value acquisition condition declaration fields,

[0015] The probe type declaration field, the monitoring point declaration field, the monitoring point acquisition parameter declaration field, and the parameter value acquisition condition declaration field are respectively parsed using program-understandable logic.

[0016] Based on the parsed program understandable statements, the target program logic file is obtained.

[0017] In conjunction with the first aspect, in one possible implementation, the step of generating probe code based on the target program logic file and the target metadata file to obtain the kernel probe program includes:

[0018] Based on the pre-set correspondence between probe types and predefined probe code templates, determine the target predefined probe code template corresponding to the probe type declaration field;

[0019] Obtain the symbol address of the monitoring point in the current operating system kernel from the monitoring point declaration field in the target metadata file, and determine the symbol address code based on the program understandable statement corresponding to the monitoring point declaration field;

[0020] Based on the program-understandable statements corresponding to the parameter value collection condition declaration field, the parameter value collection condition declaration field is parsed and converted into target filtering logic code;

[0021] The parameter type information, data structure layout, and parameter field offset of each parameter to be collected in the monitoring point collection parameter declaration field are obtained from the target metadata file. Based on the program-understandable statements corresponding to the monitoring point collection parameter declaration field, the parameter type information, the parameter data structure layout, and the parameter field offset are parsed and converted into target parameter value collection code.

[0022] The kernel probe program is generated by concatenating the target predefined probe code template, the symbol address code, the target filtering logic code, and the target parameter value acquisition code.

[0023] In conjunction with the first aspect, in one possible implementation, the step of parsing and converting the parameter value acquisition condition declaration field into target filtering logic code based on the program-understandable statement corresponding to the parameter value acquisition condition declaration field includes:

[0024] If the event ID of the monitoring point in the current operating system kernel is obtained from the target metadata file, and the event ID is pre-bound to the list of parameters to be collected in the parameter declaration field of the monitoring point, the number of parameters to be collected in the list of parameters to be collected is compared with the number of key data structures in the target metadata file;

[0025] If the number of parameters to be collected is less than or equal to the number of key data structures, then the parameter value collection condition declaration field is parsed and converted into the target filtering logic code according to the program-understandable statement corresponding to the parameter value collection condition declaration field.

[0026] In conjunction with the first aspect, in one possible implementation, the method further includes:

[0027] Determine whether the current kernel header file supports header file parsing operations;

[0028] If the current kernel header file supports the header file parsing operation, then the layout of the key data structure is parsed from the current kernel header file;

[0029] If the current kernel header file does not support the header file parsing operation, the layout of the key data structure is extracted using the debug information format.

[0030] In conjunction with the first aspect, in one possible implementation, the determination of the target declarative strategy file includes:

[0031] In response to human-computer interaction commands, the system obtains the probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions selected by the user in the editable software.

[0032] The target declarative policy file is generated by declaring the policy for the probe type, the monitoring point, the monitoring point acquisition parameters, and the parameter value acquisition conditions.

[0033] Secondly, this application also provides a kernel probe generation apparatus, the apparatus comprising:

[0034] The metadata file determination unit is used to obtain the target metadata file corresponding to the current operating system kernel in response to the kernel probe generation request; the target metadata file includes the mapping relationship between the current kernel version identifier and the layout of key data structures in the current kernel header file, the function symbol addresses in the current kernel symbol table, and the event parameter information in the current monitoring point information;

[0035] A policy declaration determination unit is used to determine the target declarative policy file; the target declarative policy file is used to ensure that the finally generated kernel probe program has time filtering capabilities at runtime;

[0036] The kernel probe generation unit is used to determine the target program logic file corresponding to the target declarative policy file, and generate probe code based on the target program logic file and the target metadata file to obtain the kernel probe program.

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

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

[0039] This application provides a kernel probe generation method, apparatus, computer device, and storage medium. The kernel probe generation method first obtains the target metadata file corresponding to the current operating system kernel. The target metadata file includes the mapping relationship between the current kernel version identifier and the layout of key data structures in the current kernel header file, the function symbol addresses in the current kernel symbol table, and the event parameter information in the current monitoring point information. It also determines a target declarative policy file, which enables the final generated kernel probe program to have runtime event filtering capabilities. Then, probe code is generated based on the target program logic file corresponding to the target declarative policy file and the target metadata file. In this way, by combining the target metadata file and the target declarative policy file, probe program source code adapted to the current kernel version can be dynamically generated. This source code generation function decouples the kernel probe development logic from the underlying kernel knowledge, eliminating the need for developers to deeply understand the kernel's internal data structures and version differences, thus lowering the development threshold. It supports not only specific operating systems or probe types but also general Linux kernels and multiple probe types. Attached Figure Description

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

[0041] Figure 1 This is one of the flowcharts illustrating a kernel probe generation method in one embodiment;

[0042] Figure 2 This is a schematic diagram illustrating the metadata file determination process in one embodiment;

[0043] Figure 3 This is a second flowchart illustrating a kernel probe generation method in one embodiment;

[0044] Figure 4 This is the third flowchart of a kernel probe generation method in one embodiment;

[0045] Figure 5 This is the fourth flowchart illustrating a kernel probe generation method in one embodiment;

[0046] Figure 6 This is a schematic diagram of the adaptive probe code generation process in one embodiment;

[0047] Figure 7 This is the fifth flowchart illustrating a kernel probe generation method in one embodiment;

[0048] Figure 8 This is the sixth flowchart illustrating a kernel probe generation method in one embodiment;

[0049] Figure 9This is the seventh flowchart illustrating a kernel probe generation method in one embodiment;

[0050] Figure 10 This is a structural block diagram of a kernel probe generation device in one embodiment;

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

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

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

[0054] First, the relevant terms used in this application will be explained:

[0055] kprobe: The Linux kernel's dynamic tracing mechanism, which allows breakpoints to be inserted at any instruction in a kernel function. When that instruction is executed, a custom handler (to collect data, modify behavior, etc.) can be executed.

[0056] eBPF: An in-kernel sandbox virtual machine technology (Extended Berkeley Packet Filter) that allows userspace programs to safely and efficiently load and execute custom code into kernel space without modifying the kernel or loading kernel modules.

[0057] Android: A mobile operating system framework based on the Linux kernel.

[0058] Tracepoints: Static hooks pre-defined in the kernel code, used to trigger tracing when a specific event occurs.

[0059] Ftrace: A powerful built-in tracing framework in Linux (Function Tracer) used for function tracing, event tracing, etc.

[0060] JSON: Lightweight data interchange format.

[0061] linux-headers: Contains header files from the Linux kernel source code used to compile kernel modules and user-space programs.

[0062] man: A manual tool that allows you to view detailed usage instructions for a given function, command, or configuration file.

[0063] bpftrace: A high-level tracing language and tool based on eBPF, which can be used to quickly obtain probe point information of the current system.

[0064] Clang AST parser: An abstract syntax tree access interface provided by the Clang compiler, which can parse source code structure.

[0065] LSM: Linux Security Models, a security framework for the Linux kernel that allows different security modules to be loaded to enforce access control on critical kernel paths such as file access, process creation, and network operations.

[0066] YAML: A data serialization format used for storing and transmitting structured data, which is more concise than JSON.

[0067] XML: A markup language used for storing and transmitting structured data.

[0068] DWARF: A standard format for debugging information (Debugging With Attributed Record Formats) that stores a wealth of information about the source code, such as variable names, types, structures, line numbers, address mappings, and so on.

[0069] Operating system kernel monitoring can help quickly locate performance bottlenecks and root causes of failures by tracing the system's running trajectory, monitor the usage of core resources such as CPU and memory in real time, dynamically adjust load balancing strategies, and promptly send out potential security threats by monitoring data such as network browsing and program behavior. Therefore, how to implement operating system kernel monitoring is particularly important.

[0070] Traditional operating system kernel monitoring (such as security auditing and performance analysis) relies on developers manually writing kernel probe programs, which requires developers to have in-depth knowledge of operating system kernels; moreover, these kernel probe programs are written for fixed kernel versions, and cross-kernel version adaptation costs are high; in addition, these kernel probe programs use full monitoring mode, which leads to excessive performance overhead when the kernel probe programs run, while fine-grained monitoring requires customized coding and is difficult to adjust dynamically.

[0071] For example, a prior art patent application (publication number CN118567628A) proposes a method for automatically generating eBPF programs of the Tracepoints program type on the Android system. This method provides a human-computer interaction module that displays subsystems / mount points for user selection, and then generates code through kernel-mode and user-mode program generators. This method focuses only on the specific program type of Tracepoints in the Android system, selecting preset monitoring points through human-computer interaction; however, it lacks the ability for users to define fine-grained monitoring strategies (such as conditional filtering) and does not mention an adaptive adaptation mechanism to handle changes in data structures across kernel versions. Therefore, it has limitations in terms of versatility, flexibility, and cross-version compatibility.

[0072] Another existing patent application (publication number CN116932325A) proposes a system monitoring method based on the Linux kernel's Ftrace function. By automatically generating Ftrace event syntax and embedding it into the kernel probe file, it can achieve kernel-level monitoring of system calls (such as file reading and writing, command execution) without writing additional code. However, this method lacks the ability to implement fine-grained monitoring strategies and cannot specify the parameters and granularity of the data collection.

[0073] Another existing patent application (publication number CN110716873A) proposes a method for building a hardware compatibility knowledge base. This method uses static analysis of kernel header files and dynamic kprobe instrumentation to monitor driver modules, collecting hardware driver dependencies on the kernel (such as function signatures and structure definitions), thus supporting compatibility testing of domestic operating systems. However, this method relies on the effectiveness of the knowledge base and cannot cover future kernel changes.

[0074] To address the aforementioned technical issues, this application proposes a kernel probe generation method, computer device, and storage medium. By combining the target metadata file and the target declarative policy file, it is possible to dynamically generate probe program source code adapted to the current kernel version. This source code generation function can decouple the kernel probe development logic from the underlying kernel knowledge, eliminating the need for developers to deeply understand the kernel's internal data structures and version differences, thus lowering the development threshold. It not only supports specific operating systems or probe types but also supports the general Linux kernel and various probe types.

[0075] The following is combined Figures 1 to 11This application describes a kernel probe generation method, apparatus, computer device, and storage medium. The kernel probe generation method can be executed by a computer device with an operating system installed, such as a personal computer, server, embedded system, or other devices. This application does not specifically limit this. Furthermore, the kernel probe generation method can also be applied to a kernel probe generation device installed in a computer device, which can be implemented through software, hardware, or a combination of both. The following description uses a computer device as an example to illustrate the kernel probe generation method.

[0076] To facilitate understanding of the kernel probe generation method provided in this application, the following examples will provide a detailed description of the method. It is understood that these examples can be combined with each other, and similar concepts or processes may not be repeated in some embodiments.

[0077] Reference Figure 1 This is a flowchart illustrating the kernel probe generation method provided in an embodiment of this application, as shown below. Figure 1 As shown, the kernel probe generation method includes the following steps 101 to 103.

[0078] Step 101: In response to the kernel probe generation request, obtain the target metadata file corresponding to the current operating system kernel; the target metadata file includes the mapping relationship between the current kernel version identifier and the layout of key data structures in the current kernel header file, the function symbol addresses in the current kernel symbol table, and the event parameter information in the current monitoring point information.

[0079] The kernel probe generation request carries the probe type for which the kernel probe program needs to be generated, and this kernel probe generation request is a request that the user inputs to the computer device when they need to generate a kernel probe program of that probe type.

[0080] It is understandable that when the function symbol address in the current kernel symbol table and the event parameter information in the current monitoring point information are collectively referred to as probe point information, the above target metadata file includes the mapping relationship between the current kernel version identifier and the key data structure layout and probe point information.

[0081] Specifically, the operating system kernel of a computer device can have pre-developed automated processing scripts. These scripts are used to accurately parse the field offsets, field types, and field sizes of key data structures from the current kernel header file. Combined with pre-defined auxiliary tools, they scan the function symbol addresses in the current kernel symbol table and parse available probe points and their parameter signatures. They also scan the directory of current monitoring point information and parse event parameter information. Afterward, all the information parsed by the automated processing scripts is output to a file in a specified format, thus obtaining the target metadata file corresponding to the current operating system kernel. This target metadata file is the basis for version adaptation. The specified format here refers specifically to the specified mapping relationship format.

[0082] It should be noted that there is at least one critical data structure that is precisely parsed from the current kernel header file, and each critical data structure can be one of other data structures such as the kernel process management structure, file system structure, memory management structure, and general data structure; the field offset of each critical data structure is specifically the offset of the field within the corresponding critical data structure body; the field offset, field type, and field size of each critical data structure can be recorded as the layout of the corresponding critical data structure.

[0083] For example, refer to Figure 2 The diagram shown illustrates the metadata file determination process, as follows: Figure 2 As shown, if the current operating system kernel, including the current kernel header file, is denoted as linux-headers, the current kernel symbol table as / proc / kallsyms, and the current monitoring point information as / sys / kernel / debug / tracing / events, and preset auxiliary tools are used to assist in understanding symbol semantics, including the man tool and the bpftrace tool, and the current kernel header file, current kernel symbol table, current monitoring point information, and preset auxiliary tools are all input data for the automated processing script, then the automated processing script uses the Clang AST parser to analyze the current kernel header file, accurately extracting the field offsets, field types, and field sizes of key data structures; scans / proc / kallsyms to obtain function symbol addresses, and combines the bpftrace tool to explore available probe points and their parameter signatures; scans the / sys / kernel / debug / tracing / events directory to obtain event and event parameter information; and uses the man tool to assist in understanding symbol semantics, the core of which lies in establishing a mapping relationship between the current kernel version identifier and the extracted key data structure layout, function symbol addresses, and event parameters. Then, all the information output by the automated processing script is output to a file in a specified format to obtain the target metadata file corresponding to the current operating system kernel.

[0084] By designing an automated metadata generation mechanism, and by parsing the current kernel header file / current kernel symbol table, a target metadata file containing data structure layout version mapping is constructed, providing a basis for version adaptation for the code generation engine; thereby solving the technical problem of high cost of cross-version adaptation.

[0085] Step 102: Determine the target declarative policy file; the target declarative policy file is used to enable the final generated kernel probe program to have runtime event filtering capabilities.

[0086] The target declarative policy file can be a user-written, format-independent declarative policy file, and must at least specify the probe type, monitoring events, collection parameters, and collection conditions. The format of the target declarative policy file and the target metadata file can be the same or different.

[0087] Specifically, for target declarative policy files, users can write declarative policy files that support other formats such as JSON / YAML / XML based on pre-provided policy fields, thereby determining the target declarative policy file.

[0088] For example, commonly used strategy fields are shown in Table 1.

[0089] Table 1

[0090]

[0091] It should be noted that, besides determining the target declarative policy file through user-written declarative policy files, the target declarative policy file can also be determined by modifying its settings to a human-computer interaction mode using the provided interactive program. However, the specific configuration is still written in the policy file, thus also determining the target declarative policy file. This application does not specifically limit the process for determining the target declarative policy file.

[0092] It is understandable that target declarative policy files inherently support any structured format; different formats are equivalent in expressive power and all can achieve the core objective of declarative policy definition. Therefore, the file format of target declarative policy files can be replaced with other structured formats, and is not limited to JSON, YAML, and XML.

[0093] By employing a user interface based on declarative policy files and an adaptive code generation engine, the kernel probe development logic is decoupled from underlying kernel knowledge, thus addressing the high technical barrier to development. Furthermore, by introducing condition fields into declarative policy files (such as JSON / YAML / XML formats), allowing users to define boolean conditions for event-triggered data collection (e.g., filename.endsWith(“.log”)), the generated probe program possesses runtime event filtering capabilities, thereby reducing invalid data collection and resolving the performance waste caused by full data collection.

[0094] Step 103: Determine the target program logic file corresponding to the target declarative policy file, and generate probe code based on the target program logic file and the target metadata file to obtain the kernel probe program.

[0095] Specifically, in addition to pre-developed automated processing scripts, the operating system kernel of the computer device also has a policy parsing engine and an adaptive probe code generation module. The input data of the policy parsing engine is the target declarative policy file, and the policy parsing engine is used to parse the overall collection logic required to generate the kernel probe from the target declarative policy file. Then, the adaptive probe code generation module is used to extract the necessary structure offsets and monitoring point information from the target metadata file according to the above overall collection logic, and generate a kernel probe program adapted to the current kernel version in conjunction with a predefined code framework.

[0096] The kernel probe generation method provided in this application first obtains the target metadata file corresponding to the current operating system kernel. The target metadata file includes the mapping relationship between the current kernel version identifier and the layout of key data structures in the current kernel header file, the function symbol addresses in the current kernel symbol table, and the event parameter information in the current monitoring point information. It also determines a target declarative policy file, which enables the finally generated kernel probe program to have runtime event filtering capabilities. Then, probe code is generated based on the target program logic file corresponding to the target declarative policy file and the target metadata file. In this way, by combining the target metadata file and the target declarative policy file, probe program source code adapted to the current kernel version can be dynamically generated. This source code generation function decouples the kernel probe development logic from the underlying kernel knowledge, eliminating the need for developers to deeply understand the kernel's internal data structures and version differences, thus lowering the development threshold. It supports not only specific operating systems or probe types but also general Linux kernels and various probe types.

[0097] Based on the above Figure 1In one example embodiment of the method shown, step 101 involves obtaining the target metadata file corresponding to the current operating system kernel. The specific process of this step can be achieved through… Figure 3 Steps 201 and 202 shown are implemented.

[0098] Step 201: Determine whether the current version identifier matches the kernel version identifier in the most recently updated metadata file.

[0099] Step 202: If the current version identifier matches the kernel version identifier, then the most recently updated metadata file is determined as the target metadata file.

[0100] Step 203: If the current version identifier does not match the kernel version identifier, collect the target metadata of the current operating system kernel, and construct a mapping relationship based on the target metadata and the current version identifier to obtain the target metadata file.

[0101] For example, target metadata may include, but is not limited to, the current kernel header file, the current kernel symbol table, and current monitoring point information.

[0102] Understandably, for an operating system kernel, each kernel version upgrade involves collecting kernel header files, kernel symbol tables, and monitor point information. All collected information, along with preset auxiliary tools, is input into an automated processing script to parse the information used to build mapping relationships. This results in a mapping relationship between the kernel version identifier and the layout of key data structures in the kernel header file, the function symbol addresses in the kernel symbol table, and the event parameter information in the monitor point information. This generates the metadata file corresponding to the upgraded operating system kernel. In other words, each time the operating system kernel is upgraded, its corresponding metadata elements are also updated. In this way, when responding to a kernel probe generation request, it can first determine whether the kernel version identifier in the most recently updated metadata file is consistent with the kernel version of the current operating system kernel. If they are consistent, the most recently updated metadata file can be directly used as the target metadata file. Otherwise, if they are inconsistent, the current kernel header file, current kernel symbol table, and current monitoring point information of the current operating system kernel are collected. The current kernel header file, current kernel symbol table, and current monitoring point information, along with preset auxiliary tools, are input into an automated processing script to parse the layout of key data structures, function symbol addresses, and event parameters, and to construct a mapping relationship between them and the current kernel version identifier, thereby obtaining the target metadata file corresponding to the current operating system kernel.

[0103] This application embodiment establishes a mechanism for associating version identifiers with metadata files, enabling intelligent reuse of historical collection results. This reduces the metadata collection frequency from every generation to triggering only when a version changes, significantly reducing computational resource consumption and solving the resource waste problem caused by repeated collection of kernel metadata in traditional methods. At the same time, the dynamic update mechanism ensures that the metadata files are always synchronized with the kernel version of the runtime environment, effectively avoiding the probe program failure problem caused by kernel upgrades.

[0104] Based on the above Figure 1 In one example embodiment of the method shown, the target program logic file corresponding to the target declarative strategy file in step 103 can be specifically described in this embodiment through... Figure 4 Steps 301 and 302 shown are implemented.

[0105] Step 301: If the target declarative strategy file includes probe type declaration field, monitoring point declaration field, monitoring point acquisition parameter declaration field, and parameter value acquisition condition declaration field, perform program-understandable logic parsing on the probe type declaration field, monitoring point declaration field, monitoring point acquisition parameter declaration field, and parameter value acquisition condition declaration field respectively.

[0106] Step 302: Obtain the target program logic file based on the parsed program understandable statements.

[0107] The probe type declaration field is an identifier used to define the functional category of the probe program. It can be implemented using an enumeration type or a string constant. Its purpose is to provide a framework selection basis for the subsequent code generation stage.

[0108] The monitoring point declaration field is used to specify the specific location in the kernel that needs to be monitored. It can be implemented using symbol names or event numbers, and its function is to locate the mount point of the kernel probe.

[0109] The parameter declaration field for monitoring points refers to the information used to determine the kernel data structure members that need to be collected. Specifically, it can be implemented using structure member path expressions or offset descriptions, and its function is to specify the range of parameter extraction.

[0110] The parameter value collection condition declaration field refers to the logical expression used to set runtime event filtering conditions. Specifically, it can be implemented using Boolean expressions or predicate logic, and its function is to establish a dynamic data filtering mechanism.

[0111] Among them, performing program-understandable logic parsing can be understood as parsing into an expression that the program can understand.

[0112] Specifically, when the target declarative policy file contains all four types of declaration fields, a pre-developed policy parsing engine defines the collection policy for each type of defined declaration field based on its meaning. That is, the probe type declaration field is identified and mapped to a predefined probe program framework type; the monitoring point declaration field is parsed and converted into a kernel symbol address or event identifier; the member access path in the monitoring point collection parameter declaration field is parsed and combined with the structural layout information in the metadata to generate parameter location code; and the parameter value collection condition declaration field is converted into conditional judgment statements. In this way, the above four types of declaration fields are parsed into a program-understandable expression, and the target program logic file corresponding to the target declarative policy file is obtained based on the parsed program-understandable expression.

[0113] For example, based on the four commonly used policy fields in Table 1 above, the following is an example of a target declarative policy file (using JSON as an example):

[0114] {

[0115] "probe_type": "kprobe",

[0116] "event": "sys_open",

[0117] "parameters": ["filename", "flags"],

[0118] "condition": "filename.endsWith('.log')"

[0119] }

[0120] In the above example of a target declarative strategy file, filename.endsWith(“.log”) is used to determine whether a string ends with the suffix “.log”.

[0121] This application embodiment uses structured parsing of four core fields in the declarative strategy, allowing users to freely define monitoring requirements through the declarative strategy. In particular, it supports fine-grained, on-demand event filtering via the condition field, effectively reducing runtime overhead, eliminating manual coding, and automating the conversion of user-defined monitoring strategies into executable program logic. This enables users without kernel development experience to quickly build probe programs through declarative configuration. At the same time, the field-based parsing mechanism effectively reduces the impact of strategy modifications on the overall code structure, improving the development efficiency and cross-version adaptability of probe programs.

[0122] Based on the above Figure 1In one example embodiment of the method shown, step 103 involves generating probe code based on the target program logic file and the target metadata file to obtain a kernel probe program. The specific process in this embodiment can be described through… Figure 5 Steps 401 to 405 shown are implemented.

[0123] Step 401: Determine the target predefined probe code template corresponding to the probe type declaration field based on the pre-set correspondence between probe type and predefined probe code template.

[0124] Step 402: Obtain the symbolic address of the monitoring point in the current operating system kernel from the monitoring point declaration field in the target metadata file, and determine the symbolic address code based on the program-understandable statement corresponding to the monitoring point declaration field.

[0125] Step 403: Based on the program-understandable statements corresponding to the parameter value collection condition declaration fields, parse the parameter value collection condition declaration fields and convert them into target filtering logic code.

[0126] Step 404: Obtain the parameter type information, data structure layout, and parameter field offset of each parameter to be collected from the monitoring point collection parameter declaration field in the target metadata file, and parse and convert the parameter type information, data structure layout, and parameter field offset into target parameter value collection code according to the program understandable statements corresponding to the monitoring point collection parameter declaration field.

[0127] Step 405: Concatenate the target predefined probe code template, symbol address code, target filtering logic code, and target parameter value acquisition code to generate a kernel probe program.

[0128] Among them, monitoring points usually refer to the preset performance indicator collection points in the operating system kernel, such as quantifiable operating parameters like CPU utilization, memory usage, and disk read / write speed. These indicators are collected in real time through interfaces or tools provided by the operating system kernel to evaluate the operating system load and resource allocation efficiency.

[0129] In other words, for the operating system kernel, both monitoring points and events serve the operation and maintenance of the operating system. Monitoring points focus on data collection (such as CPU load), while events focus on exception capture (such as abnormal process termination).

[0130] Symbolic addresses in the operating system kernel are primarily used for program debugging, dynamic linking, system maintenance, security, and reverse engineering.

[0131] The data structure layout for each parameter to be collected can be the corresponding key data structure layout in the target metadata file.

[0132] The parameter type information for each parameter to be collected can be the field type of the corresponding key data structure in the target metadata file.

[0133] The parameter field offset for each parameter to be collected can be the field offset of the corresponding key data structure in the target metadata file.

[0134] For example, for the operating system kernel of a computer device, the probe code template of the kernel probe program is as follows:

[0135] #include<linux / kernel.h>

[0136] #include<linux / module.h>

[0137] #include<linux / kprobes.h>

[0138] #include<linux / string.h>

[0139] #include<linux / version.h>

[0140] #include<linux / ptrace.h>

[0141] #include<linux / slab.h>

[0142] #include<linux / perf_event.h>

[0143] struct probe_point {

[0144] const char *symbol_name;

[0145] kprobe_pre_handler_t pre_handler;

[0146] kprobe_post_handler_t post_handler;

[0147] struct kprobe kp;

[0148] bool registered;

[0149] };

[0150] / **

[0151] * Generate filtering logic code

[0152] /

[0153] / **

[0154] * Generate parameter value collection code

[0155] * /

[0156] static struct probe_point monitor_points[] = {

[0157] {

[0158] .symbol_name = "do_sys_open",

[0159] .pre_handler = open_pre_handler,

[0160] .post_handler = open_post_handler,

[0161] .registered = false,

[0162] },

[0163] };

[0164] #define NUM_PROBES (sizeof(monitor_points) / sizeof(monitor_points[0]))

[0165] static int register_all_probes(void)

[0166] {

[0167] int i, ret;

[0168] for (i = 0; i<NUM_PROBES; i++) {

[0169] struct probe_point *point =&monitor_points[i];

[0170] point->kp.symbol_name = point->symbol_name;

[0171] point->kp.pre_handler = point->pre_handler;

[0172] point->kp.post_handler = point->post_handler;

[0173] ret = register_kprobe(&point->kp);

[0174] if (ret<0) {

[0175] printk(KERN_ERR "Failed to register kprobe for %s: %d\n",

[0176] point->symbol_name, ret);

[0177] while (--i>= 0) {

[0178] if (monitor_points[i].registered) {

[0179] unregister_kprobe(&monitor_points[i].kp);

[0180] }

[0181] }

[0182] return ret;

[0183] }

[0184] point->registered = true;

[0185] printk(KERN_INFO "Registered kprobe for %s at %p\n",

[0186] point->symbol_name, point->kp.addr);

[0187] }

[0188] return 0;

[0189] }

[0190] static void unregister_all_probes(void)

[0191] {

[0192] int i;

[0193] for (i = 0; i<NUM_PROBES; i++) {

[0194] if (monitor_points[i].registered) {

[0195] unregister_kprobe(&monitor_points[i].kp);

[0196] printk(KERN_INFO "Unregistered kprobe for %s\n",

[0197] monitor_points[i].symbol_name);

[0198] }

[0199] }

[0200] }

[0201] static int __init kprobe_monitor_init(void)

[0202] {

[0203] int ret;

[0204] printk(KERN_INFO "Initializing kprobe monitor module\n");

[0205] int cpu;

[0206] for_each_possible_cpu(cpu) {

[0207] struct open_data *data = per_cpu_ptr(&open_data, cpu);

[0208] data->filename = NULL;

[0209] data->is_log_file = false;

[0210] }

[0211] ret = register_all_probes();

[0212] if (ret<0) {

[0213] printk(KERN_ERR "Failed to register probes\n");

[0214] return ret;

[0215] }

[0216] printk(KERN_INFO "Kprobe monitor module loaded successfully\n");

[0217] return 0;

[0218] }

[0219] static void __exit kprobe_monitor_exit(void)

[0220] {

[0221] unregister_all_probes();

[0222] printk(KERN_INFO "Kprobe monitor module unloaded\n");

[0223] }

[0224] module_init(kprobe_monitor_init);

[0225] module_exit(kprobe_monitor_exit);

[0226] MODULE_LICENSE("GPL");

[0227] MODULE_AUTHOR("Your Name");

[0228] MODULE_DESCRIPTION("Generic Kprobe Monitoring Framework with SplitHandlers");

[0229] MODULE_VERSION("0.1");

[0230] Specifically, the adaptive probe code generation module pre-developed in the operating system kernel of a computer device can generate probe code by combining the target metadata file and the target program logic file output by the policy parsing engine, such as... Figure 6The diagram shown illustrates the adaptive probe code generation process, as follows: Figure 6 As shown, when the adaptive probe code generation module is pre-configured with predefined probe code templates corresponding to different probe types, the adaptive probe code generation module can determine the target predefined probe code template corresponding to the probe type in the probe type declaration field according to the correspondence between probe type and predefined probe code template.

[0231] The adaptive probe code generation module can also query the target metadata file corresponding to the current operating system kernel based on the monitoring point in the monitoring point declaration field, obtain the exact symbol address of the monitoring point in the current operating system kernel, and parse or convert the symbol address into symbol address code based on the program understandable statement corresponding to the monitoring point declaration field.

[0232] The adaptive probe code generation module not only has pre-configured predefined probe code templates corresponding to different probe types, but also pre-configured probe frames corresponding to different probe types. In this way, the adaptive probe code generation module can determine the target probe frame corresponding to the probe type in the probe type declaration field according to the correspondence between probe type and probe frame. Then, based on the parameter value, it collects the program understandable statements corresponding to the condition declaration field, parses the probe type declaration field and converts it into target filtering logic code that is supported and valid by the target probe frame.

[0233] For example, the target filtering logic code can be as follows:

[0234] struct open_data {

[0235] char *filename;

[0236] int flags;

[0237] bool is_log_file;

[0238] };

[0239] static DEFINE_PER_CPU(struct open_data, open_data);

[0240] #define MAX_FILENAME_LEN 256

[0241] static int open_pre_handler(struct kprobe *p, struct pt_regs *regs)

[0242] {

[0243] const char __user *filename = (const char __user *)regs->si;

[0244] int flags = regs->dx;

[0245] struct open_data *data = this_cpu_ptr(&open_data);

[0246] data->filename = kmalloc(MAX_FILENAME_LEN, GFP_ATOMIC);

[0247] if (!data->filename) {

[0248] data->is_log_file = false;

[0249] return 0;

[0250] }

[0251] int length = strncpy_from_user(data->filename, filename, MAX_FILENAME_LEN - 1);

[0252] if (length<0) {

[0253] kfree(data->filename);

[0254] data->is_log_file = false;

[0255] return 0;

[0256] }

[0257] data->filename[length] = '\0';

[0258] data->flags = flags;

[0259] data->is_log_file = (length>= 4&&strcmp(data->filename + length - 4,".log") == 0);

[0260] return 0;

[0261] }

[0262] The adaptive probe code generation module can also query the parameter type information, data structure layout, and parameter field offset of each parameter to be collected in the parameter declaration field of the monitoring point, and parse and convert the parameter type information, data structure layout, and parameter field offset of each parameter to be collected into code according to the program understandable statement corresponding to the parameter declaration field of the monitoring point, thereby generating the target parameter collection code.

[0263] For example, the code for collecting target parameters is shown below:

[0264] static int open_post_handler(struct kprobe *p, struct pt_regs *regs,unsigned long flags)

[0265] {

[0266] struct open_data *data = this_cpu_ptr(&open_data);

[0267] if (data->is_log_file&&data->filename) {

[0268] printk(KERN_INFO "PROBE_OPEN: Opening log file: %s with flags: %d\n",

[0269] data->filename, data->flags);

[0270] }

[0271] if (data->filename) {

[0272] kfree(data->filename);

[0273] data->filename = NULL;

[0274] }

[0275] data->is_log_file = false;

[0276] return 0;

[0277] }

[0278] At this point, the adaptive probe code generation module concatenates the predefined target probe code template, symbol address code, target filtering logic code, and target parameter value acquisition code generated above. The target filtering logic code is inserted into the final kernel probe program before data acquisition. That is, the target filtering logic code is executed first, and then the parameter value acquisition code is executed. The complete probe code obtained by concatenation is then determined as the final kernel probe program to be generated.

[0279] For example, the complete probe code obtained by splicing can be shown as follows:

[0280] #include<linux / kernel.h>

[0281] #include<linux / module.h>

[0282] #include<linux / kprobes.h>

[0283] #include<linux / string.h>

[0284] #include<linux / version.h>

[0285] #include<linux / ptrace.h>

[0286] #include<linux / slab.h>

[0287] #include<linux / perf_event.h>

[0288] struct probe_point {

[0289] const char *symbol_name;

[0290] kprobe_pre_handler_t pre_handler;

[0291] kprobe_post_handler_t post_handler;

[0292] struct kprobe kp;

[0293] bool registered;

[0294] };

[0295] struct open_data {

[0296] char *filename;

[0297] int flags;

[0298] bool is_log_file;

[0299] };

[0300] static DEFINE_PER_CPU(struct open_data, open_data);

[0301] static int open_pre_handler(struct kprobe *p, struct pt_regs *regs)

[0302] {

[0303] const char __user *filename = (const char __user *)regs->si;

[0304] int flags = regs->dx;

[0305] struct open_data *data = this_cpu_ptr(&open_data);

[0306] data->filename = kmalloc(MAX_FILENAME_LEN, GFP_ATOMIC);

[0307] if (!data->filename) {

[0308] data->is_log_file = false;

[0309] return 0;

[0310] }

[0311] int length = strncpy_from_user(data->filename, filename, MAX_FILENAME_LEN - 1);

[0312] if (length<0) {

[0313] kfree(data->filename);

[0314] data->is_log_file = false;

[0315] return 0;

[0316] }

[0317] data->filename[length] = '\0';

[0318] data->flags = flags;

[0319] data->is_log_file = (length>= 4&&strcmp(data->filename + length - 4,".log") == 0);

[0320] return 0;

[0321] }

[0322] static int open_post_handler(struct kprobe *p, struct pt_regs *regs,unsigned long flags)

[0323] {

[0324] struct open_data *data = this_cpu_ptr(&open_data);

[0325] if (data->is_log_file&&data->filename) {

[0326] printk(KERN_INFO "PROBE_OPEN: Opening log file: %s with flags: %d\n",

[0327] data->filename, data->flags);

[0328] }

[0329] if (data->filename) {

[0330] kfree(data->filename);

[0331] data->filename = NULL;

[0332] }

[0333] data->is_log_file = false;

[0334] return 0;

[0335] }

[0336] #define MAX_FILENAME_LEN 256

[0337] static struct probe_point monitor_points[] = {

[0338] {

[0339] .symbol_name = "do_sys_open",

[0340] .pre_handler = open_pre_handler,

[0341] .post_handler = open_post_handler,

[0342] .registered = false,

[0343] },

[0344] };

[0345] #define NUM_PROBES (sizeof(monitor_points) / sizeof(monitor_points[0]))

[0346] static int register_all_probes(void)

[0347] {

[0348] int i, ret;

[0349] for (i = 0; i<NUM_PROBES; i++) {

[0350] struct probe_point *point =&monitor_points[i];

[0351] point->kp.symbol_name = point->symbol_name;

[0352] point->kp.pre_handler = point->pre_handler;

[0353] point->kp.post_handler = point->post_handler;

[0354] ret = register_kprobe(&point->kp);

[0355] if (ret<0) {

[0356] printk(KERN_ERR "Failed to register kprobe for %s: %d\n",

[0357] point->symbol_name, ret);

[0358] while (--i>= 0) {

[0359] if (monitor_points[i].registered) {

[0360] unregister_kprobe(&monitor_points[i].kp);

[0361] }

[0362] }

[0363] return ret;

[0364] }

[0365] point->registered = true;

[0366] printk(KERN_INFO "Registered kprobe for %s at %p\n",

[0367] point->symbol_name, point->kp.addr);

[0368] }

[0369] return 0;

[0370] }

[0371] static void unregister_all_probes(void)

[0372] {

[0373] int i;

[0374] for (i = 0; i<NUM_PROBES; i++) {

[0375] if (monitor_points[i].registered) {

[0376] unregister_kprobe(&monitor_points[i].kp);

[0377] printk(KERN_INFO "Unregistered kprobe for %s\n",

[0378] monitor_points[i].symbol_name);

[0379] }

[0380] }

[0381] }

[0382] static int __init kprobe_monitor_init(void)

[0383] {

[0384] int ret;

[0385] printk(KERN_INFO "Initializing kprobe monitor module\n");

[0386] int cpu;

[0387] for_each_possible_cpu(cpu) {

[0388] struct open_data *data = per_cpu_ptr(&open_data, cpu);

[0389] data->filename = NULL;

[0390] data->is_log_file = false;

[0391] }

[0392] ret = register_all_probes();

[0393] if (ret<0) {

[0394] printk(KERN_ERR "Failed to register probes\n");

[0395] return ret;

[0396] }

[0397] printk(KERN_INFO "Kprobe monitor module loaded successfully\n");

[0398] return 0;

[0399] }

[0400] static void __exit kprobe_monitor_exit(void)

[0401] {

[0402] unregister_all_probes();

[0403] printk(KERN_INFO "Kprobe monitor module unloaded\n");

[0404] }

[0405] module_init(kprobe_monitor_init);

[0406] module_exit(kprobe_monitor_exit);

[0407] MODULE_LICENSE("GPL");

[0408] MODULE_AUTHOR("Your Name");

[0409] MODULE_DESCRIPTION("Generic Kprobe Monitoring Framework with SplitHandlers");

[0410] MODULE_VERSION("0.1");

[0411] It should be noted that in the above complete probe code example, the file name can be specified by the user, or it can be set to {probe_type}_{event ID}_{detection point} by default. In this embodiment, it is kprobe_12345_sys_open.c.

[0412] This application's implementation process solves the problem of low efficiency in manual coding by reusing a general code framework through predefined templates and automatically adapting to different kernel versions using metadata. It eliminates manual intervention for cross-version adaptation by dynamically acquiring kernel version-specific information. Through an automatic policy-to-code conversion mechanism, it endows the probe program with dynamic event filtering capabilities, avoiding the performance loss caused by full data collection at runtime. In this way, declarative policies are converted into executable logic, realizing the automated generation and assembly of core functional components, effectively reducing development complexity, and achieving modular automatic generation of kernel probe code.

[0413] Based on the above Figure 5 In one example embodiment of the method shown, step 403 involves parsing and converting the parameter value collection condition declaration field into target filtering logic code based on the program-understandable statements corresponding to the parameter value collection condition declaration field. The specific process in this embodiment can be described through… Figure 7 Steps 501 and 502 shown are implemented.

[0414] Step 501: After obtaining the event ID of the monitoring point in the current operating system kernel from the target metadata file, and after the event ID is pre-bound to the list of parameters to be collected in the parameter declaration field of the monitoring point, compare the number of parameters to be collected in the list of parameters to be collected with the number of key data structures in the target metadata file.

[0415] Step 502: If the number of parameters to be collected is less than or equal to the number of key data structures, then based on the program-understandable statements corresponding to the parameter value collection condition declaration fields, the parameter value collection condition declaration fields are parsed and converted into target filtering logic code.

[0416] Among them, an event specifically refers to an exception or state transition record kept by the operating system kernel, such as critical nodes such as process creation / termination, security policy triggering, and system crash; event monitoring helps to locate the cause of the failure by tracking changes in the state of the operating system kernel (such as identifying abnormal processes through log analysis).

[0417] Specifically, for the adaptive code generation module, it can not only obtain the symbolic address of the monitoring point in the current operating system kernel from the monitoring point declaration field in the target metadata file, but also obtain the event ID of the monitoring point in the current operating system kernel. When the event ID can be obtained, the event ID is bound to the list of parameters to be collected in the monitoring point collection parameter declaration field to determine the legality of the parameters to be collected. The legality judgment process refers to comparing the number of parameters to be collected in the list of parameters to be collected with the number of key data structures in the target metadata file. If the number of parameters to be collected is less than or equal to the number of key data structures, the list of parameters to be collected is determined to pass the legality verification. At this time, the parameter value collection condition declaration field can be parsed and converted into target filtering logic code according to the program understandable statement corresponding to the parameter value collection condition declaration field.

[0418] Understandably, if the number of parameters to be collected exceeds the number of key data structures, the subsequent parameter value collection code generation process and filtering logic code generation process will stop, that is, the kernel probe program generation ends.

[0419] It should be noted that the event ID is not converted into actual code. Instead, it is bound to the list of parameters to be collected and used to determine the validity of the parameters during the generation of parameter value collection code and filtering logic code, ultimately generating the final kernel probe program.

[0420] This application's embodiments solve the stability problem of filtering logic code generation in scenarios where event IDs are bound to parameter lists by automatically comparing the number of parameters with the capacity of the data structure, thus forcibly constraining the parameter collection scale and ensuring that the parameter collection condition conversion process conforms to the physical limitations of the kernel data structure. Automated comparison of the number of parameters with the capacity of the data structure avoids memory access anomalies caused by parameter overflow, and the binding relationship ensures a strict match between the parameter collection range and the event context, thereby improving the security and reliability of the kernel probe program during runtime.

[0421] Based on the above Figure 1 In one example embodiment of the method shown, the specific process for determining the layout of key data structures in the current kernel header file in step 101 can be achieved through... Figure 8 Steps 601 to 603 shown are implemented.

[0422] Step 601: Determine whether the current kernel header file supports header file parsing operations.

[0423] Step 602: If the current kernel header file supports header file parsing, then parse the layout of key data structures from the current kernel header file;

[0424] Step 603: If the current kernel header file does not support header file parsing, extract the layout of key data structures by using the debugging information format.

[0425] The header file parsing operation refers to the operation of performing syntax analysis and semantic parsing on the operating system kernel header file. By traversing the structure definitions in the operating system header file, information such as field offsets and data types is extracted. This header file parsing operation can directly utilize the structured header file information provided by the operating system kernel developers to ensure the accuracy of data structure layout.

[0426] Debug information format extraction refers to the operation of reading standard debug symbol information from executable files or kernel images. Specifically, it can be implemented using a DWARF format parser, which analyzes the debug segment data embedded in the binary file to reverse-engineer the memory layout of data structures. This operation enables the acquisition of internal information of critical data structures through debug symbols generated during compilation, even when header files are unavailable.

[0427] Specifically, determining whether the current kernel header file supports header file parsing can involve checking if the user corresponding to the kernel probe generation request has permission to open the current kernel header file, or successfully decrypting an encrypted kernel header file. If the user has permission to open the current kernel header file or can successfully decrypt an encrypted kernel header file, then the layout of key data structures can be parsed from the current kernel header file. Conversely, if the user does not have permission to open the current kernel header file or cannot successfully decrypt an encrypted kernel header file, then the layout of key data structures can be extracted using the debug information format. For example, the debug information format can be DWARF format.

[0428] This application's embodiments introduce an alternative path for extracting debugging information, enabling the acquisition of data structure layouts through debug symbols generated during compilation even when header files are unparseable. This effectively solves the cross-version compatibility problem, ensuring accurate extraction of key field offsets under different kernel compilation configurations. This improves the compatibility of the generated kernel probe program with the target kernel version and avoids runtime memory access anomalies caused by data structure layout errors.

[0429] Based on the above Figure 1 In one example embodiment of the method shown, step 102 involves determining the target declarative policy file. The specific process of this step can be achieved through… Figure 9 Steps 701 and 702 shown are implemented.

[0430] Step 701: In response to human-computer interaction instructions, obtain the probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions selected by the user in the editable software.

[0431] Step 702: Declare strategies for probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions, and generate a target declarative strategy file.

[0432] Among them, human-computer interaction instructions refer to interactive signals triggered by user operations. Specifically, they can be implemented using click events or drag-and-drop operations in the graphical interface, and are used to convert user intentions into input signals that the system can recognize.

[0433] It should be noted that the target declarative policy file can be pre-written by developers, or it can be configured online via human-computer interaction in response to a kernel probe generation request. Specifically, when the kernel probe generation request is applied to other editable software such as Word or WPS, and the probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions are selected according to actual needs in the interface displayed after opening, a policy declaration can be made for the selected probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions. That is, the selected probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions are converted into a system-executable policy definition through declarative syntax, describing the probe configuration in a structured format; thus generating the target declarative policy file.

[0434] This application's embodiments automatically parse kernel metadata to directly provide users with editable configuration items. Users only need to select the probe type, monitoring points, target parameters, and set filter values ​​to complete the configuration. This allows operations and maintenance personnel without kernel development experience to quickly build monitoring policies through a graphical interface, avoiding probe program failures caused by manual coding errors. Simultaneously, the standardized generation mechanism of declarative policy files reduces the differences in configurations among different users, ensuring the portability of generated probe programs across different kernel versions. Furthermore, by decoupling kernel metadata parsing from the user interface, only the metadata file needs to be updated during underlying kernel version upgrades to maintain the availability of policy configuration functionality, significantly reducing version adaptation costs.

[0435] Compared with the prior art, the embodiments of this application have the following advantages:

[0436] Advantage 1: Greater versatility and flexibility: It not only supports specific systems or probe types, but also supports general Linux kernels and various probe types (kprobe, lsm, eBPF, etc.); users can freely define monitoring requirements through declarative policies, especially supporting fine-grained, on-demand event filtering through condition fields, effectively reducing runtime overhead.

[0437] Advantage 2: More thorough cross-version compatibility: By explicitly encapsulating kernel version differences (especially changes in data structure layout) through automatically generated metadata files, the code generation engine dynamically adapts to the target kernel based on the metadata, achieving "define once, generate in multiple places", significantly reducing maintenance costs.

[0438] Advantage 3: Lower development threshold: Developers do not need to have a deep understanding of the kernel's internal data structures and version differences. They can define complex monitoring logic by simply writing declarative policy files, which improves development efficiency from weekly / monthly to minute-level.

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

[0440] In one embodiment, this application also provides a kernel probe generation apparatus, such as... Figure 10 As shown, the kernel probe generation device includes: a metadata file determination unit 1001, a policy declaration determination unit 1002, and a kernel probe generation unit 1003.

[0441] Metadata file determination unit 1001 is used to obtain the target metadata file corresponding to the current operating system kernel in response to the kernel probe generation request. The target metadata file includes the mapping relationship between the current kernel version identifier and the layout of key data structures in the current kernel header file, the function symbol addresses in the current kernel symbol table, and the event parameter information in the current monitoring point information.

[0442] The policy declaration determination unit 1002 is used to determine the target declarative policy file; the target declarative policy file is used to enable the final generated kernel probe program to have runtime event filtering capabilities.

[0443] The kernel probe generation unit 1003 is used to determine the target program logic file corresponding to the target declarative policy file, and generate probe code based on the target program logic file and the target metadata file to obtain the kernel probe program.

[0444] In one embodiment, the metadata file determination unit 1001 is specifically used to determine whether the current version identifier matches the kernel version identifier in the most recently updated metadata file; if the current version identifier matches the kernel version identifier, the most recently updated metadata file is determined as the target metadata file; if the current version identifier does not match the kernel version identifier, the target metadata of the current operating system kernel is collected, and a mapping relationship is constructed based on the target metadata and the current version identifier to obtain the target metadata file.

[0445] In one embodiment, the kernel probe generation unit 1003 is specifically used to perform program-understandable logic parsing on the probe type declaration field, monitoring point declaration field, monitoring point acquisition parameter declaration field, and parameter value acquisition condition declaration field, respectively, when the target declarative policy file includes probe type declaration field, monitoring point declaration field, monitoring point acquisition parameter declaration field, and parameter value acquisition condition declaration field; and to obtain the target program logic file based on the parsed program-understandable statements.

[0446] In one embodiment, the kernel probe generation unit 1003 is specifically used to: determine the target predefined probe code template corresponding to the probe type declaration field based on the pre-set correspondence between probe types and predefined probe code templates; obtain the symbol address of the monitoring point in the current operating system kernel from the monitoring point declaration field in the target metadata file, and determine the symbol address code based on the program understandable statements corresponding to the monitoring point declaration field; parse and convert the parameter value collection condition declaration field into target filtering logic code based on the program understandable statements corresponding to the parameter value collection condition declaration field; obtain the parameter type information, data structure layout, and parameter field offset of each parameter to be collected from the monitoring point collection parameter declaration field in the target metadata file, and parse and convert the parameter type information, parameter data structure layout, and parameter field offset into target parameter value collection code based on the program understandable statements corresponding to the monitoring point collection parameter declaration field; and concatenate the target predefined probe code template, symbol address code, target filtering logic code, and target parameter value collection code to generate a kernel probe program.

[0447] In one embodiment, the kernel probe generation unit 1003 is specifically used to compare the number of parameters to be collected in the parameter list with the number of key data structures in the target metadata file when the event ID of the monitoring point in the current operating system kernel is obtained from the target metadata file and the event ID is pre-bound to the list of parameters to be collected in the parameter declaration field of the monitoring point; if the number of parameters to be collected is less than or equal to the number of key data structures, the parameter value collection condition declaration field is parsed and converted into target filtering logic code according to the program understandable statement corresponding to the parameter value collection condition declaration field.

[0448] In one embodiment, the metadata file determination unit 1001 is specifically used to determine whether the current kernel header file supports header file parsing operations; if the current kernel header file supports header file parsing operations, the key data structure layout is parsed from the current kernel header file; if the current kernel header file does not support header file parsing operations, the key data structure layout is extracted through the debugging information format.

[0449] In one embodiment, the strategy declaration determination unit 1002 is specifically used to respond to human-computer interaction instructions, obtain the probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions selected by the user in the editable software; declare the strategy for the probe type, monitoring point, monitoring point acquisition parameters, and parameter value acquisition conditions, and generate a target declarative strategy file.

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

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

[0452] like Figure 11 As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1102 or programs loaded from storage section 1108 into random access memory (RAM) 1103. The RAM 1103 also stores various programs and data required for the operation of the system 1100. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0453] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1110 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

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

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

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

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

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

[0459] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 1 The steps of the method shown.

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

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

Claims

1. A kernel probe generation method, characterized in that, The method comprises: in response to a kernel probe generation request, obtaining a target metadata file corresponding to a current operating system kernel; the target metadata file comprises a mapping relationship between a current kernel version identifier and a key data structure layout in a current kernel header file, a function symbol address in a current kernel symbol table, and event parameter information in a current monitoring point information; determining a target declarative policy file; the target declarative policy file is used to enable the finally generated kernel probe program to have runtime event filtering capability; determining a target program logic file corresponding to the target declarative policy file, and generating probe code according to the target program logic file and the target metadata file to obtain the kernel probe program; wherein the determination of the target program logic file corresponding to the target declarative policy file comprises: in the case that the target declarative policy file comprises a probe type declaration field, a monitoring point declaration field, a monitoring point collection parameter declaration field, and a parameter value collection condition declaration field, respectively performing program understandable logic analysis on the probe type declaration field, the monitoring point declaration field, the monitoring point collection parameter declaration field, and the parameter value collection condition declaration field; obtaining the target program logic file according to the parsed program understandable statements; the generation of the kernel probe program according to the target program logic file and the target metadata file comprises: determining a target predefined probe code template corresponding to the probe type declaration field according to a preset corresponding relationship between a probe type and a predefined probe code template; obtaining a symbol address of the monitoring point in the current operating system kernel from the target metadata file according to the program understandable statement corresponding to the monitoring point declaration field, and determining a symbol address code; parsing and converting the parameter value collection condition declaration field into target filtering logic code according to the program understandable statement corresponding to the parameter value collection condition declaration field; obtaining parameter type information, a data structure layout, and a parameter field offset of each parameter to be collected from the monitoring point collection parameter declaration field in the target metadata file, and parsing and converting the parameter type information, the data structure layout, and the parameter field offset into target parameter value collection code according to the program understandable statement corresponding to the monitoring point collection parameter declaration field; splicing the target predefined probe code template, the symbol address code, the target filtering logic code, and the target parameter value collection code to generate the kernel probe program.

2. The method of claim 1, wherein, the obtaining of the target metadata file corresponding to the current operating system kernel comprises: determining whether the current kernel version identifier matches a kernel version identifier in a last updated metadata file; if the current kernel version identifier matches the kernel version identifier, determining the last updated metadata file as the target metadata file; If the current kernel version identifier does not match the kernel version identifier, target metadata of the current operating system kernel is collected, and the mapping relationship is constructed according to the target metadata and the current kernel version identifier, to obtain the target metadata file.

3. The method of claim 1, wherein, The parameter value collection condition declaration field is parsed and converted into target filtering logic code according to the program understandable statement corresponding to the parameter value collection condition declaration field. If the event ID of the monitoring point in the current operating system kernel is obtained from the target metadata file, and the event ID and the to-be-collected parameter list in the monitoring point collection parameter declaration field are pre-established binding relationship, the number of to-be-collected parameters in the to-be-collected parameter list is compared with the number of the key data structures in the target metadata file. If the number of to-be-collected parameters is less than or equal to the number of the key data structures, the parameter value collection condition declaration field is parsed and converted into the target filtering logic code according to the program understandable statement corresponding to the parameter value collection condition declaration field.

4. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: determining whether the current kernel header file supports header file parsing operation; if the current kernel header file supports the header file parsing operation, the key data structure layout is parsed from the current kernel header file; if the current kernel header file does not support the header file parsing operation, the key data structure layout is extracted through debugging information format.

5. The method according to any one of claims 1 to 3, characterized in that, The target declarative policy file comprises: in response to human-computer interaction instructions, a user-selected probe type, monitoring point, monitoring point collection parameter and parameter value collection condition in editable software are obtained; the probe type, the monitoring point, the monitoring point collection parameter and the parameter value collection condition are declared to generate the target declarative policy file.

6. A kernel probe generation apparatus characterized by comprising: The device comprises: a metadata file determination unit configured to obtain a target metadata file corresponding to a current operating system kernel in response to a kernel probe generation request; the target metadata file comprises a mapping relationship between a current kernel version identifier and a key data structure layout in a current kernel header file, a function symbol address in a current kernel symbol table and event parameter information in a current monitoring point information; a policy declaration determination unit configured to determine a target declarative policy file; the target declarative policy file is used to ensure that a finally generated kernel probe program has time filtering capability when running; a kernel probe generation unit configured to determine a target program logic file corresponding to the target declarative policy file, and generate probe code according to the target program logic file and the target metadata file to obtain the kernel probe program. The target program logic file corresponding to the target declarative policy file is determined, comprising: in the case that the target declarative policy file comprises a probe type declaration field, a monitoring point declaration field, a monitoring point collection parameter declaration field and a parameter value collection condition declaration field, The probe type declaration field, the monitoring point declaration field, the monitoring point collection parameter declaration field and the parameter value collection condition declaration field are respectively subjected to program-understandable logic analysis; According to the parsed program-understandable statements, the target program logic file is obtained; The probe code generation according to the target program logic file and the target metadata file to obtain the kernel probe program comprises: According to the corresponding relationship between the probe type-predefined probe code template, the target predefined probe code template corresponding to the probe type declaration field is determined; The symbol address of the monitoring point in the current operating system kernel is obtained from the target metadata file, and the symbol address code is determined according to the program-understandable statement corresponding to the monitoring point declaration field; According to the program-understandable statement corresponding to the parameter value collection condition declaration field, the parameter value collection condition declaration field is parsed and converted into target filtering logic code; The parameter type information, data structure layout and parameter field offset of each parameter to be collected in the monitoring point collection parameter declaration field are obtained from the target metadata file, and the parameter type information, data structure layout and parameter field offset are parsed and converted into target parameter value collection code according to the program-understandable statement corresponding to the monitoring point collection parameter declaration field; The target predefined probe code template, the symbol address code, the target filtering logic code and the target parameter value collection code are spliced to generate the kernel probe program.

7. A computer device comprising a processor, a memory, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to realize the kernel probe generation method in any one of claims 1 to 5.

8. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to realize the kernel probe generation method in any one of claims 1 to 5.

Images