Instruction-level kernel vulnerability triggering process tracking method based on task selectivity

Abstract

The invention belongs to the technical field of operating system kernel vulnerability analysis, and particularly relates to an instruction-level kernel vulnerability triggering process tracking method based on task selectivity. The method comprises the steps that all kernel tasks triggered by a vulnerability concept verification program are recognized in the execution process of the vulnerability concept verification program, and a range is defined for subsequent selective execution; in the execution process of the vulnerability concept verification program, the instruction executed by the kernel is selectively tracked according to the defined execution range, and the kernel instruction level tracking efficiency is improved; and finally, a kernel execution record is stored in a high-density binary storage format, so that the storage space is greatly saved under the condition of ensuring complete data storage. According to the method, through selective kernel execution tracking, the efficiency of instruction-level kernel execution tracking is effectively improved, the storage space required by kernel execution tracks is reduced, and an efficient, accurate and complete vulnerability triggering process tracking tool is provided for various kernel vulnerability dynamic analysis tasks.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of operating system kernel vulnerability analysis, and particularly relates to a task-selective instruction-level kernel vulnerability triggering process tracking method. BACKGROUND

[0002] With the wide application of automatic kernel vulnerability mining technology, the number of kernel vulnerability reports shows a significant growth trend. In order to effectively alleviate the large overhead generated by kernel vulnerability analysis, many automatic kernel vulnerability dynamic analysis technologies have emerged. These automatic kernel vulnerability dynamic analysis technologies mostly need to track the instruction level of the vulnerability triggering proof-of-concept program to perform fine-grained vulnerability triggering process analysis. However, existing researches show that the overhead generated by complete instruction-level tracking of the kernel is huge, which is difficult to be used on a large scale. Therefore, many kernel vulnerability dynamic analysis tasks are difficult to be carried out on a large scale in real events. This leads to the contradiction between the increasing demand for vulnerability analysis and the inefficient analysis method. In order to alleviate this problem, existing works have discussed and researched the efficient instruction-level kernel dynamic tracking.

[0003] The existing instruction-level kernel dynamic tracking methods are mainly divided into two categories: binary translation-based instruction-level tracking and hardware-assisted instruction-level tracking. The binary translation-based method usually converts operating system instructions into intermediate representations for simulation execution. Since a translation layer is introduced, this kind of method can usually easily insert hook functions before and after the instruction execution to extract various types of information and data of the instruction execution. However, binary translation usually translates one binary instruction into multiple intermediate representations, which brings a fold increase in code size. Therefore, the complete instruction-level tracking based on binary translation is inefficient and difficult to be applied on a large scale in practice.

[0004] Another new type of method is to track the kernel by hardware-assisted tracking technology at the instruction level, such as PT technology on the Intel platform, which can record the selection of all branches in the program execution process for subsequent recovery of the complete execution process. However, this method still has defects. First, the tracking record of this type of technology is completely completed by hardware, and the hardware completes the tracking record by writing record data into a predefined buffer. However, this type of technology usually lacks a synchronization message notification mechanism. When the buffer is full, the hardware sends an asynchronous signal to the system to prompt that the record data is full. If the system does not process and empty the buffer in time, the tracking data may be lost. Second, the implementation of this type of technology on various hardware platforms is different, and it is difficult to design a unified and highly versatile system that can support operation on a variety of different hardware platforms. Finally, most hardware tracking technologies do not support tracking and recording of memory access. Tracking memory access is crucial in vulnerability analysis. Therefore, hardware-assisted instruction-level tracking technology has certain shortcomings in accuracy and completeness and is not suitable for direct application in the tracking and recording of the kernel vulnerability triggering process.

[0005] In summary, the existing instruction-level kernel execution tracking technology has significant limitations in efficiency, accuracy, and applicability, and it is difficult to be applied to large-scale dynamic tracking of the kernel vulnerability triggering process. Therefore, a new method is needed to improve the efficiency of kernel execution tracking technology while ensuring its accuracy and completeness of tracking data. SUMMARY

[0006] The purpose of the present application is to provide a kernel vulnerability triggering process instruction-level tracking technology with high efficiency, accuracy, and completeness to overcome the defects and deficiencies of the prior art.

[0007] The present application improves the efficiency of kernel instruction-level tracking by task-selective tracking while maintaining accuracy and data integrity. Specifically, the present application first runs the system kernel in a virtual machine and identifies the kernel task of interest triggered by the vulnerability proof-of-concept program. Second, by identifying whether the currently executed kernel task is the task of interest, the present application selectively enables kernel instruction-level tracking, reduces the overhead of tracking, and obtains complete register context, memory access, and kernel task life cycle data information. Finally, the present application stores the tracking data in binary fragments in the storage device, greatly saving the storage space occupied by the tracking data.

[0008] The following introduces the related definitions of instruction-level kernel vulnerability triggering process tracking and task selectivity: Instruction-level kernel vulnerability triggering process tracking is the tracking process of the relevant instructions executed in the kernel vulnerability triggering process during the execution of the kernel vulnerability proof-of-concept program. The tracked data includes register context, memory access, and kernel task life cycle.

[0009] Task selectivity, by identifying and analyzing the kernel tasks triggered directly or indirectly by the kernel vulnerability proof of concept, that is, the tasks of interest, selectively tracking the execution of the kernel tasks at the instruction level, thereby avoiding the huge overhead generated by tracking irrelevant tasks.

[0010] The present application provides a task-selective instruction-level kernel vulnerability trigger process tracking method, and the specific steps are as follows: (1) Kernel task identification: identify the kernel tasks of interest created and triggered by the vulnerability proof of concept program from the execution process of the vulnerability proof of concept program, and identify the life cycle of the tasks of interest, which is used to selectively start kernel instruction-level tracking; wherein the types of kernel tasks of interest include system calls, pure kernel threads, interrupts, and in-queue work, and the life cycle of the tasks of interest is in any one of the four stages of task creation, task execution, task scheduling, and task termination; (2) Kernel tracking control: according to the identified kernel tasks of interest, track the instructions running in the kernel through the selective tracking switch function; if the task currently being executed by the kernel is a task of interest, tracking is started, otherwise tracking is temporarily closed to reduce unnecessary overhead; when the selective tracking switch is turned on, the tracking data collection module is notified to collect and record the instruction-level execution data of the kernel; (3) Tracking data storage: receive the collected tracking data record entries and temporarily store them in a buffer, when the number of data entries in the buffer reaches a specified number or a specified storage volume, convert the instruction-level execution data in the current buffer to structured data and empty the buffer, and further use a binary serialization tool to convert the data to binary format for persistent storage.

[0011] In the present application, in step (1), the vulnerability proof of concept program directly or indirectly triggers kernel tasks; by instrumenting the related kernel task life cycle control functions, and receiving feedback from the instrumented functions during the dynamic running of the kernel, the complete life cycle of various kernel tasks is monitored.

[0012] In the present application, in step (1), the method for identifying kernel tasks of interest is as follows: First, add the system calls directly triggered by the vulnerability trigger proof of concept program to the kernel task list of interest, and use the system call order and system call number as the task identifier. Secondly, if a task of interest creates other kernel tasks, the newly created kernel tasks are also added to the kernel task list of interest, pure kernel threads are identified by kernel thread number, interrupts are identified by interrupt number, and in-queue work is identified by the address of the kernel structure corresponding to the in-queue work.

[0013] In the present application, in step (2), the selective tracking switch obtains all the lists of kernel tasks of interest from the kernel task identification step and updates in real time, and when a new kernel task life cycle event is received, it is determined whether a kernel task of interest is about to enter the task execution stage in the life cycle; if yes, the tracking switch is turned on to inform the tracking data collection module to collect instruction-level execution data; if no, the tracking switch is temporarily turned off to save the overhead of system operation.

[0014] In the present application, in step (2), the instruction-level execution data includes three parts of register context, memory access and life cycle event: The register context refers to the set of values of all registers on the processor running the task before and after the execution of a kernel instruction by the kernel task, which covers the specific values of various types of registers including general registers, flag registers or program counters; The memory access refers to the memory access behavior occurring when the kernel instruction is executed, including memory read and memory write behaviors; the access address, access length and access result memory value of each behavior are recorded in the instruction-level execution data; if it is a memory read behavior, the access result memory value is the value obtained by reading the memory; if it is a memory write behavior, the access result memory value is the value to be written into the memory.

[0015] The life cycle event refers to the life cycle event occurring when the selective tracking is turned on or off, including the creation, execution, scheduling and termination of system call tasks, the creation, execution, scheduling and termination of pure kernel thread tasks, the creation, execution and termination of interrupt tasks, and the creation, execution, scheduling and termination of in-queue work tasks; in addition to recording the type of life cycle event, the data entry also records the corresponding kernel task identifier. In the present application, in step (2), tracking entries for identifying the life cycle of the task of interest are inserted at the beginning and end of tracking; for the tracked instructions, the register context of the processor before and after execution is extracted and recorded, and if memory access occurs, the access address, access length and access result memory value of the memory access are also recorded.

[0016] In the present application, in step (3), the format conversion of the instruction-level execution data is as follows: First, for the register context, each data value in the register context is labeled with a label, and the label content is the register name where it is located; for memory access, the two different memory access behaviors are mapped to integer representation, using 0 to represent reading and 1 to represent writing, and the captured access address, access length and access result memory value are labeled with string labels for distinction; for the life cycle event, different life cycle events are mapped to integer representation, and the kernel task identifier is labeled with a string label; Second, the data entry is appended with the instruction address and process number executed when the data entry is generated; Finally, the data entry is assigned with an integer type data entry index, which globally uniquely identifies the order of the data entry captured in all executed data entries.

[0017] In the present application, in step (3), during the tracking process, the data entry is stored in slices according to the number of real-time cached data entries, and when the data entries in the buffer reach a specified number or a specified storage volume, a background thread is started to submit the cached data entries to the background thread for actual storage work, preventing the tracking function from being blocked. The background thread converts the data into binary format for storage by calling a binary serialization interface; after the tracking is completed, a series of instruction-level tracking data segments of the vulnerability triggering process are obtained and stored in binary form on the storage device.

[0018] Compared with the prior art, the present application has the following beneficial effects: The present application provides a task-selective instruction-level kernel vulnerability triggering process tracking method, which selectively tracks the kernel execution by identifying the interested task in the kernel vulnerability triggering process, and efficiently stores the tracking data in binary form. This method not only improves the tracking efficiency of the instruction set kernel vulnerability triggering process, but also guarantees the accuracy and integrity of the tracking data. Through these innovations, the present application provides a more efficient and robust tool for instruction set kernel vulnerability triggering process tracking, and provides effective support for kernel vulnerability analysis tasks. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 The figure is a whole framework diagram of the task-selective instruction-level kernel vulnerability triggering process tracking method.

[0020] Figure 2 The figure is a schematic diagram of the interested kernel task identification.

[0021] Figure 3 The figure is a schematic diagram of the selective tracking switch action of the four types of kernel tasks.

[0022] Figure 4 The figure is a schematic diagram of the tracking data storage. DETAILED DESCRIPTION

[0023] The present application will be further described below by way of examples in conjunction with the accompanying drawings.

[0024] This invention primarily targets kernel vulnerabilities with proof-of-concept programs. Its goal is to efficiently and completely record the vulnerability triggering process through task-selective instruction-level kernel execution tracing. By selectively tracing kernel execution, this invention effectively improves the efficiency of instruction-level kernel execution tracing, reduces the storage space required for kernel execution traces, and provides an efficient, accurate, and complete vulnerability triggering process tracing tool for various dynamic kernel vulnerability analysis tasks.

[0025] The overall framework diagram of the present invention is as follows: Figure 1 As shown. It includes: a kernel task identification module, a kernel tracing control module, and a tracing data storage module. The functions of each module are as follows: 1) Kernel Task Identification Module: During the execution of the kernel vulnerability proof-of-concept program, this module identifies the related kernel tasks created and triggered, including but not limited to system calls, kernel threads, interrupts, and work queues; it also determines whether these related tasks are in an execution state in order to selectively enable kernel-level instruction tracing. 2) Based on the kernel task identification module, the system traces the instructions running in the kernel. Tracing is initiated when the currently executing task belongs to the task of interest; otherwise, it is temporarily disabled to reduce unnecessary overhead. Tracing entries identifying the lifecycle of the task of interest are inserted at the beginning and end of each tracing step. For each traced instruction, the system extracts and records the processor register context before and after its execution; if memory access is involved, the accessed address, length, and corresponding value are also recorded. 3) Tracking Data Storage Module: Based on the lifecycles, instruction addresses, register contexts, and memory access information of tasks of interest collected through selective tracking, the system organizes and processes these data in execution order. To avoid impacting read efficiency due to excessively long records, the system splits records into multiple segments once they reach a certain length, converting each segment into a specific binary format for storage, thereby saving storage space.

[0026] The following is a further description of each module: 1. Kernel Task Identification Module The kernel task identification module constantly monitors the execution of the kernel within the virtual machine. When the vulnerability proof-of-concept program begins execution, it identifies kernel tasks of interest that are directly or indirectly triggered by the program and notifies the kernel tracing control module to enable or disable the tracing switch.

[0027] (1) Kernel task definition Kernel tasks are various business logics triggered by the operating system in user mode and kernel mode. These business logics are designed in various forms, such as user-triggered system calls, background long-running pure kernel threads, interrupts triggered by various burst events, and in-queue work delayed for execution by joining a work queue. These forms are collectively referred to as kernel tasks. When the vulnerability concept verification program executes, a series of kernel tasks are triggered, ultimately leading to the occurrence of the vulnerability. The kernel tasks triggered directly or indirectly by the vulnerability concept verification program are referred to as kernel tasks of interest. These tasks are usually highly relevant to the vulnerability triggering process and are therefore the analysis targets of interest of the present application. The kernel tasks triggered directly or indirectly by the vulnerability concept verification program are defined as follows: Directly triggered kernel tasks include the kernel tasks triggered by the vulnerability concept verification program code directly through system calls and the like to the operating system for execution in the kernel mode.

[0028] Indirectly triggered kernel tasks include new kernel tasks triggered again in the kernel tasks triggered directly or indirectly by the vulnerability concept verification program. These new kernel tasks triggered again do not exist if the vulnerability concept verification program is not executed. Therefore, these kernel tasks are also considered to be triggered by the vulnerability concept verification program and are classified as indirect triggers.

[0029] (2) Kernel task life cycle identification The life cycle of a kernel task starts with the creation of the task, goes through the execution of the task, the scheduling of the task, and ends with the destruction of the task due to completion or other reasons. For typical kernel task types, the life cycle is described as follows: The system call is considered to be task creation, i.e., the start of the life cycle, when the user mode process initiates a system call request and falls into the kernel mode; the system call in execution is considered to be task execution; when the kernel code related to the system call is executing, it may be paused due to the kernel task scheduling mechanism, and after a period of time, it will resume execution, which is considered to be task scheduling; when the system call ends, i.e., when it is about to return to the user mode process, it is considered to be task completion and termination, i.e., the end of the life cycle.

[0030] Pure kernel threads are used to continuously complete some long-term tasks. The life cycle of a pure kernel thread starts with the creation of the thread; when the thread is executing, it is considered to be task execution; the thread may be paused due to the kernel task scheduling mechanism, and after a period of time, it will resume execution, which is considered to be task scheduling; when the tasks executed by the thread are all completed or the thread exits due to task errors, the thread stops executing and releases the related resources at this time, which is considered to be task termination, and the life cycle ends.

[0031] An interrupt is generated by a sudden event in the system, such as a device request, a running error, or a network packet entering. The operating system will pause the task currently being executed and give priority to the sudden event. The life cycle of the interrupt starts from the setting of the interrupt flag bit; the execution process of the interrupt handler is regarded as task execution; and the end of the running of the interrupt handler is regarded as task termination. An interrupt usually does not contain task scheduling and must be executed once from beginning to end.

[0032] Queuing is also a long-term kernel task running mechanism, which is usually used to delay the processing of some tasks that do not need to be processed immediately, so as to improve the real-time performance of the system. The life cycle of queuing starts from the creation and joining of the work queue; when the work queue starts to execute the work, it is regarded as task execution; during the execution of the work, the kernel task scheduling mechanism may pause the execution of the work, and after a period of time, the execution is resumed, which is regarded as task scheduling; when the work is executed or exited due to an error, it is regarded as task termination, and the life cycle ends.

[0033] In order to identify the life cycle of these tasks, the present application inserts a stake into the related kernel task life cycle control function, and receives feedback from the stake function during the dynamic running of the kernel, so as to monitor the complete life cycle of various kernel tasks. Some classic kernel task life cycle control functions are as follows: __schedule: the core function of the kernel task scheduling system, which is used for the scheduling in / out of different kernel tasks.

[0034] do_syscall_64: the entry function of the system call.

[0035] syscall_exit_to_user_mode: the exit function of the system call.

[0036] kthread_create: the creation function of the pure kernel thread.

[0037] kthread_run: the start function of the pure kernel thread.

[0038] do_exit: the exit function of the pure kernel thread.

[0039] __raise_softirq_irqoff: a creation function of an interrupt.

[0040] __do_softirq: a start function of an interrupt, which indicates that the interrupt is completed when the function is run.

[0041] insert_work: the creation function of the queuing work.

[0042] process_one_work: The function that starts the queued work. When this function finishes running, it means that the queued work is complete.

[0043] (3) Identification of kernel tasks of interest To identify the kernel task of interest in the proof-of-concept program that triggers the vulnerability, the following steps are taken: First, add the system calls directly triggered by the vulnerability triggering proof-of-concept program to the list of kernel tasks of interest, using the system call order and system call number as task identifiers; Secondly, if a task of interest creates other kernel tasks, the newly created kernel tasks are also added to the list of kernel tasks of interest. Pure kernel threads are identified by their kernel thread number; interrupts are identified by their interrupt number; and queued tasks are identified by the address of the kernel structure corresponding to the queued task.

[0044] by Figure 2 As shown in the example, the main function of the vulnerability proof-of-concept program triggers two system calls: System Call 1 and System Call 3. Both of these system calls will be added to the list of kernel tasks of interest. Specifically, the second system call, System Call 3, creates and triggers a new kernel task, Queued Job 1. Therefore, Queued Job 1 will also be added to the list of kernel tasks of interest. Kernel tasks triggered by other programs, such as System Call 2 and Interrupt 1, will not be added to the list of kernel tasks of interest.

[0045] 2. Kernel Tracing Control Module The kernel tracing control module enables or disables the tracing switch based on information fed back from the kernel task identification module. When the tracing switch is enabled, it calls the interfaces provided by the virtual machine to collect various types of tracing data and sends it to the tracing data storage module in real time for further processing.

[0046] (1) Selective tracking switch The kernel is complex and highly parallel. During the execution of a kernel vulnerability proof-of-concept program, numerous unrelated programs execute simultaneously. Most of these programs are unrelated to the vulnerability triggering process. To improve tracing efficiency, this invention employs a selective tracing switch function, tracking only the code execution within kernel tasks of interest triggered by the vulnerability proof-of-concept program. The selective tracing switch first obtains and updates a list of all interested kernel tasks from a kernel task identification technology in real time. When a new kernel task lifecycle event is received, it determines whether an interested kernel task is about to enter the task execution phase of its lifecycle. If so, the tracing switch is activated, notifying the tracing data acquisition module to collect instruction-level execution data; otherwise, the tracing switch is temporarily deactivated to save system overhead.

[0047] The selective switching timing of the four classic kernel tasks is shown in Figure 3 For a system call executed in the task of interest (hereinafter referred to as "the interested system call"), the tracking switch is opened at the beginning of the system call; if task scheduling occurs so that it is no longer executed, the tracking switch is temporarily closed; when it is scheduled into execution again, the tracking switch is opened again; when the system call is completed, the tracking switch is closed. For an interested interrupt, the tracking switch is opened at the beginning of the interrupt processing, and the tracking switch is closed when the interrupt processing is completed. For an interested pure kernel thread and an interested in-queue work, the tracking switch has no action when created, and the subsequent actions are similar to the interested system call. The tracking switch is opened when it starts to execute; the tracking switch is temporarily closed when it is called out; the tracking switch is opened again when it is called in; and the tracking switch is closed when it is terminated. Except for interrupts, the other three types of tasks may be called in and out multiple times during their life cycle, accompanied by repeated opening and closing of the tracking switch.

[0048] (2) Tracking data collection If the selective tracking switch is opened, the tracking data collection module will collect the instruction-level execution data of the kernel. The instruction-level execution data includes the following three parts: When the tracking switch is opened, this module collects the following register context data: the set of register values of the processor on which the kernel task is executed before and after executing the kernel instruction, covering the specific values of various types of registers such as general registers, flag registers, program counters, etc.

[0049] When the tracking switch is opened, this module collects the following memory access data: the type of memory access behavior, including memory read and memory write behaviors; the access address, access length, and access result memory value of each behavior will also be recorded in the instruction-level execution data. If it is a memory read behavior, the access result memory value is the value obtained by reading the memory; if it is a memory write behavior, the access result memory value is the value to be written into the memory.

[0050] At the moment when the tracking switch state is switched, the following life cycle events of the interested kernel task are collected: the creation, execution, scheduling (including calling in and calling out), termination of the system call, the creation, execution, scheduling (including calling in and calling out), termination of the pure kernel thread, the creation, execution, termination of the interrupt, the creation, execution, scheduling (including calling in and calling out), termination of the in-queue work. In addition to recording the type of life cycle event, this data entry will also record the corresponding kernel task identifier. For a system call, the system call order and the system call number are used as the task identifier; for a pure kernel thread, the kernel thread number is used as the identifier; for an interrupt, the interrupt number is used as the identifier; for an in-queue work, the address of the kernel structure corresponding to the in-queue work is used as the identifier.

[0051] 3. Tracking data storage module The tracking data storage module mainly receives the tracking data record entries collected by the kernel tracking control module and stores them in a buffer. Once the data entries in the buffer reach a specified number or a specified storage volume, the tracking data storage module converts the original data in the current buffer into structured data and empties the buffer, and further converts the data into a binary format using a binary serialization tool for persistent storage.

[0052] (1) Tracking data format conversion The data obtained by tracking data collection needs to be converted for storage as structured data. For the three types of instruction-level execution data entries, the format conversion method is as follows: The conversion of the register context data entry includes three steps. First, each data value in the register context is labeled with the register name it is in; second, the instruction address and process number at which the data entry is generated are attached to the data entry; and finally, an integer type data entry index is assigned to the data entry, globally uniquely identifying the order in which the data entry is captured among all execution data entries.

[0053] The format conversion of the memory access data entry includes three steps. First, the two different memory access behaviors are mapped to integer representations, with 0 representing reading and 1 representing writing, and the access address, access length, and access result memory value are labeled with string tags to distinguish them; second, the instruction address and process number at which the data entry is generated are attached to the data entry; and finally, an integer type data entry index is assigned to the data entry, globally uniquely identifying the order in which the data entry is captured among all execution data entries.

[0054] The conversion of the lifecycle time data entry includes three steps. First, different lifecycle events are mapped to integer representations, and the kernel task identifier is labeled with a string tag; second, the instruction address and process number at which the data entry is generated are attached to the data entry; and finally, an integer type data entry index is assigned to the data entry, globally uniquely identifying the order in which the data entry is captured among all execution data entries.

[0055] (2) Tracking data storage In order to prevent the tracking data volume of a single kernel vulnerability triggering process from being too large, affecting storage and transmission, during the tracking process, the tracking data storage module will perform slice storage according to the number of real-time cached data entries. For example, Figure 4As shown, when the obtained data entries are accumulated to a certain number or a certain storage volume, the tracking data storage module will start a background thread to submit the cached data entries to the background thread to perform the actual storage work, preventing the tracking function from being blocked. The background thread converts the data into binary format for storage by calling the binary serialization interface, such as "Tracking Data Fragment.1.bin" and "Tracking Data Fragment.2.bin" in Figure 4 After the tracking is completed, a series of instruction-level tracking data fragments of the vulnerability triggering process are obtained and stored in binary form on the storage device. These instruction-level vulnerability triggering process tracking data can be used for subsequent vulnerability analysis tasks.

[0056] Real environment practice evaluation The present application verifies the effectiveness in real environment through a series of actual cases. In order to ensure that the present application can efficiently track the kernel vulnerability triggering process at the instruction level, the present application collects 54 real kernel vulnerabilities for testing. The test shows that, without adopting selective tracking, the number of instructions that need to be tracked is between 100,000 and 100 million, with an average of 20.94 million. After adopting the selective tracking strategy, the number of instructions that need to be tracked can be reduced to one-third of the original, about 30,000 to 30 million, with an average of about 6.74 million. The time consumed in the tracking process is between 40 seconds and 171 seconds, with an average of about 59 seconds. Without using the selective tracking technology of the present application, the tracking time will increase by about 3 times. The present application uses binary format for tracking data storage, and the space occupied is between 110 MB and 10 GB, with an average of 1.39 GB. The storage overhead can be completely borne by modern servers.

[0057] In summary, the present application proposes an instruction-level kernel vulnerability triggering process tracking method based on task selectivity. First, the kernel task identification module accurately identifies the kernel task of interest triggered directly or indirectly by the vulnerability concept verification program by identifying the life cycle of the kernel task, and defines the range for subsequent selective execution. Second, the kernel tracking control module captures the executed instructions, memory access, task life cycle, etc. of the task execution process of the task of interest by selectively tracking the task execution process of the task of interest, avoiding tracking of irrelevant kernel tasks, and improving tracking efficiency. Finally, the tracking data storage module converts the tracking data into binary format for storage, improving the utilization efficiency of storage space. Through these series of steps, the present application can efficiently, accurately and completely track the triggering process of the kernel vulnerability at the instruction level, providing effective support for downstream kernel vulnerability analysis tasks.

[0058] The method comprises the following steps: identifying all kernel tasks triggered by a vulnerability proof program from an execution process of the vulnerability proof program; selectively tracking instructions of kernel execution according to a designated execution range during the execution process of the vulnerability proof program, so as to improve the efficiency of kernel instruction level tracking; and finally saving the kernel execution record by using a high-density binary storage format, so as to greatly save storage space while ensuring the completeness of data storage.

Claims

1. A method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity, characterized in that, The specific steps are as follows: (1) Kernel task identification: Identify the kernel tasks of interest created and triggered by the vulnerability proof-of-concept program during its execution, and identify the lifecycle of these tasks of interest for selectively enabling kernel instruction-level tracing; among them, the types of kernel tasks of interest include system calls, pure kernel threads, interrupts and queued work, and the lifecycle of the tasks of interest is in any of the four stages of task creation, task execution, task scheduling and task termination. (2) Kernel tracing control: Based on the identified kernel task of interest, the instructions running in the kernel are traced through the selective tracing switch function; if the task currently being executed by the kernel is the task of interest, tracing is enabled; otherwise, tracing is temporarily disabled to reduce unnecessary overhead; when the selective tracing switch is enabled, the tracing data acquisition module is notified to collect and record the kernel instruction-level execution data. (3) Tracking data storage: Receive the collected tracking data record entries and temporarily store them in the buffer. When the number of data entries in the buffer reaches the specified number or the specified storage volume, convert the instruction-level execution data format in the current buffer into structured data and clear the buffer. Furthermore, use a binary serialization tool to convert the data into binary format for persistent storage.

2. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 1, characterized in that, In step (1), the vulnerability proof-of-concept program directly or indirectly triggers kernel tasks; by instrumenting the relevant kernel task lifecycle control functions and receiving feedback from the stub functions during the dynamic operation of the kernel, the complete lifecycle of various kernel tasks is monitored.

3. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 1, characterized in that, In step (1), the method for identifying the kernel tasks of interest is as follows: First, add the system calls directly triggered by the vulnerability-triggered proof-of-concept program to the list of kernel tasks of interest, using the system call order and system call number as task identifiers; Secondly, if a task of interest creates other kernel tasks, the newly created kernel tasks are also added to the list of kernel tasks of interest. Pure kernel threads are identified by their kernel thread number, interrupts are identified by their interrupt number, and queued tasks are identified by the address of the kernel structure corresponding to the queued task.

4. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 1, characterized in that, In step (2), the selective tracking switch obtains and updates the list of all interested kernel tasks from the kernel task identification step in real time. When a new kernel task lifecycle event is received, it determines whether an interested kernel task is about to enter the task execution phase of its lifecycle. If yes, the tracking switch is turned on, notifying the tracking data acquisition module to collect instruction-level execution data; if no, the tracking switch is temporarily turned off to save system operating costs.

5. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 1 or 4, characterized in that, In step (2), the instruction-level execution data includes three parts: register context, memory access, and lifecycle events. Register context refers to the set of values ​​of all registers on the processor running the kernel task before and after the kernel task executes a kernel instruction. It covers the specific values ​​of various types of registers, including general-purpose registers, flag registers, and program counters. Memory access refers to the memory access behavior that occurs when kernel instructions are executed, including memory read and memory write. The access address, access length, and memory value of the access result for each behavior are recorded in the instruction-level execution data. If it is a memory read operation, the resulting memory value is the value obtained from reading memory. If it is a memory write operation, the memory access result will be the value that needs to be written to memory; Lifecycle events refer to selectively tracking lifecycle events that occur at the time of startup or shutdown, including the creation, execution, scheduling, and termination of system call tasks, the creation, execution, scheduling, and termination of pure kernel thread tasks, the creation, execution, and termination of interrupt tasks, and the creation, execution, scheduling, and termination of queued worker tasks. In addition to recording the type of lifecycle event, this data entry also records the corresponding kernel task identifier.

6. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 5, characterized in that, Insert trace entries to identify the lifecycle of the task of interest when tracing starts and ends; for the traced instructions, extract and record the processor register context before and after their execution; if memory access occurs, record the access address, access length, and memory value of the access result.

7. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 1, characterized in that, In step (3), the format conversion method of instruction-level execution data is as follows: First, for register context, each data value in the register context is labeled with the name of the register it belongs to; for memory access, two different memory access behaviors are mapped to integer representations, using 0 to represent read and 1 to represent write, and the captured access address, access length, and access result memory value are labeled with strings for distinction; for lifecycle events, different lifecycle events are mapped to integer representations, and the kernel task identifier is labeled with a string. Secondly, append the address of the instruction executed when the data entry was created to the data entry; Finally, each data entry is assigned an integer index that globally and uniquely identifies the order in which the data entries were captured across all executed data entries.

8. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 1, characterized in that, In step (3), during the tracking process, the data entries in the real-time cache are sliced ​​and stored. When the number of data entries in the buffer reaches a specified number or a specified storage volume, a background thread is started to submit the cached data entries to the background thread to perform the actual storage work, so as to prevent the tracking function from being blocked.

9. The method for tracing the triggering process of instruction-level kernel vulnerabilities based on task selectivity according to claim 8, characterized in that, The background thread converts the data into binary format for storage by calling the binary serialization interface; after the tracing is completed, it obtains a series of instruction-level tracing data fragments of the vulnerability triggering process, which are stored in binary form on the storage device.

Images