Method and system for collecting system calls, and non-transitory tangible calculator readable medium

Abstract

The present disclosure provides methods, systems, and non-transitory tangible calculator readable media for collecting system calls. In an optional embodiment, the present disclosure provides a method of collecting system calls for a particular process, comprising: providing an ioctl interface from a Linux kernel module (LKM), the LKM comprising a function callback function, configured such that when ioctl is used, the kernel module registers a callback function for the trace point, and all system calls are passed through the callback function; filtering a syscale with an identification (ID) of the specific process; and storing an index and a parameter of the syscale related to the specific process.

Description

Technical Field

[0001] The present disclosure relates generally to computer science and, more particularly, to systems and methods for collecting system calls (syscalls for short) for a particular process. Background Art

[0002] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0003] In computing, a system call is a programmatic way for a computer program to request services from the kernel of the operating system (OS) in which it is executed. A system call is executed when a computer program makes a request to the kernel of the operating system. System calls provide operating system services to user programs through the Application Program Interface (API). They provide an interface between processes and the operating system, allowing user-level processes to request operating system services. System calls are the only entry point into the kernel system. All programs requiring resources must use system calls.

[0004] A system call is initiated by a program executing a specific instruction that triggers a switch to kernel mode, allowing the program to request a service from the OS. The OS then processes the request, performs the necessary actions, and returns the results to the program.

[0005] Due to the rapid development of artificial intelligence, more and more applications have been developed, and these user space programs need to communicate with the kernel through system calls.

[0006] However, most methods for collecting system calls require specific permissions and cannot be easily used in user space.

[0007] Therefore, there exists a heretofore unaddressed need in the art to address the above-mentioned deficiencies and inadequacies. Summary of the Invention

[0008] The present disclosure provides a method, system, and non-transitory tangible computer-readable medium for collecting system calls.

[0009] In an optional embodiment, the present disclosure provides a method for collecting system calls of a specific process, including: providing an io control (ioctl) interface from a Linux kernel module (LKM), the LKM including a function callback function (functioncallback), and configuring so that when ioctl is used, the kernel module registers a callback function (callbackfunction) for the trace point, and all system calls (syscall) pass through the callback function; filtering syscalls with an identification (ID) of the specific process; and storing an index and parameters of the syscall related to the specific process.

[0010] In another optional embodiment, the present disclosure provides a system comprising: at least one processor configured to execute a method for collecting system calls of a specific process, the method comprising: providing an io control (ioctl) interface from a Linux kernel module (LKM), the LKM including a function callback function, configured so that when ioctl is used, the kernel module registers a callback function for the trace point, and all system calls (syscalls) pass through the callback function; filtering syscalls having an identification (ID) of the specific process; and storing an index and parameters of the syscall related to the specific process.

[0011] In another optional embodiment, the present disclosure provides a non-transitory tangible computer-readable medium for storing instructions that, when executed by one or more processors, form a method for executing and collecting system calls of a specific process, the method comprising: providing an io control (ioctl) interface from a Linux kernel module (LKM), the LKM including a function callback function, configured so that when ioctl is used, the kernel module registers a callback function for the trace point, and all system calls (syscalls) pass through the callback function; filtering syscalls with an identification (ID) of the specific process; and storing an index and parameters of the syscall related to the specific process. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 An exemplary configuration for collecting system calls of a specific process is shown according to certain embodiments.

[0013] Figure 2 A flowchart for collecting system calls of a specific process is shown according to some embodiments. DETAILED DESCRIPTION

[0014] The following detailed description and attached Figure 1The detailed description includes specific details to provide a thorough understanding of the various concepts. However, those skilled in the art can practice these concepts without these specific details. In some cases, known structures and components are shown in block diagram form to avoid obscuring these concepts.

[0015] Some aspects of telecommunications systems will now be described with reference to various apparatus and methods. These apparatus and methods are described in the following detailed description and illustrated in the accompanying figures by various blocks, components, circuits, processes, algorithms, etc. (collectively, "elements"). These elements can be implemented using electronic hardware, computer software, or a combination of both. Whether these elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0016] For example, an element, any portion of an element, or any combination of elements may be implemented as a "processing system" comprising one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoCs), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configurations for performing the various functions described herein. One or more processors in a processing system may execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise, software should be broadly understood to mean instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, programs, functions, and the like.

[0017] Thus, in one or more example aspects, the functions described may be implemented in hardware, software, or a combination of the two. If implemented in software, these functions may be stored in or encoded as one or more instructions or codes, stored on a computer-readable medium. Computer-readable media include computer storage media. The storage medium may be any available medium that a computer can access. For example, and not limitation, a computer-readable medium may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, a combination of the above-mentioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.

[0018] In computing, operating systems typically divide virtual memory into kernel space and user space. Kernel space is the memory space where the operating system's core (kernel) executes and provides services. Kernel space is reserved for running device drivers, the operating system kernel, and all other kernel extensions. User space, also known as userland, is the memory space where all user applications or application software execute. Everything except the operating system's core and kernel runs in user space. User processes can access kernel space through system calls. A system call (syscall) is a programmatic way for a computer program to request services from the operating system (OS) it is executing on—that is, how a program interacts with the underlying system, such as accessing hardware resources or performing privileged operations. User programs can use system calls to interact with the operating system. Typically, a program will request multiple services, and the OS will respond by initiating multiple system calls to fulfill the requests.

[0019] System call monitoring is the act of capturing execution in certain contexts before an application successfully passes its task to the OS. System call monitoring can detect and control compromised applications by checking at runtime whether each system call complies with policies that specify normal program behavior. As systems become busier and more stressed, the amount of system call activity typically increases accordingly. Because these interactions occur frequently, system call monitoring must ensure minimal performance impact on activity. However, most existing methods for monitoring system calls require specific permissions and cannot be easily used from userspace.

[0020] In view of the above situation, one aspect of the present invention discloses a new method for collecting and monitoring system calls from user space. The method provides a method for collecting system calls and managing permissions from user space, ensuring minimal performance impact on system call activities.

[0021] In some embodiments, a method for collecting system calls of a specific process from user space includes providing an io control (ioctl) (i.e., input and output control) interface from a Linux kernel module (LKM), the LKM including a function callback function, configured so that when ioctl is used, the kernel module registers a callback function for a tracepoint, and all system calls (syscalls) pass through the callback function; filtering syscalls with an identification (ID) of the specific process; and storing an index and parameters of the syscall associated with the specific process.

[0022] In some embodiments, the ioctl is set in the user space and communicates with the LKM in the kernel space. In operation, the user can call the LKM to collect and / or monitor system calls through the ioctl in the user space.

[0023] In some embodiments, the structures contained in the function callback functionality include task_struct and pt_regs.

[0024] In some embodiments, the task_struct contains details of all processes that call sys_entry, including but not limited to process ID, syscall ID, and the sequence of all syscalls.

[0025] In some embodiments, the pt_regs contains the syscall number and register values ​​stored in a central processing unit (CPU).

[0026] In some embodiments, filtering syscalls with the ID of the specific process includes checking the thread group ID (tgid) within the task_struct to confirm whether it is a syscall of the specific process. In other words, the filtering step selectively collects / monitors only syscalls of the specific process. It should be noted that by changing certain filtering criteria, the filtering step can collect / monitor syscalls of different processes and / or all processes according to some embodiments of the present invention.

[0027] In some embodiments, storing the index and parameters of the syscall includes storing the syscall ID and parameters from pt_regs when the syscall is a syscall of the specific process. Similarly, the storing step selectively stores only the syscall of the specific process. It should be noted that by changing certain filtering criteria, the storing step can store syscalls of different processes and / or all processes according to some embodiments of the present invention.

[0028] In some embodiments, the collected / monitored syscall information can be analyzed for use in different application scenarios, such as optimizing system performance, detecting potential system risks, analyzing user behavior, making corresponding system settings, determining which type of application is using the collected syscall, system debugging, etc.

[0029] In some embodiments, the method further includes analyzing syscalls to optimize system performance, detect potential system risks, analyze user behavior, make corresponding system settings, and / or determine what type of applications are using the collected syscalls.

[0030] In some embodiments, the method further includes tracing syscalls for system debugging.

[0031] refer to Figure 1In some embodiments, the Linux kernel module (LKM) 100 for sequentially collecting system calls includes a callback function 120 located in the kernel and registered for a trace point. Therefore, all system calls (syscalls) pass through the callback function 120. For example, when a user application, such as APK 20, requests a service from the kernel of the operating system it is executing on, it issues one or more syscalls in sys_entry 30 in kernel space. These one or more syscalls pass through the callback function 120.

[0032] LKM 100 also includes an LKM entry 110 that communicates with a callback function 120. In operation, user 10 uses the ioctl in user space to call LKM entry 110 through ioctl interface 101, which in turn couples to callback function 120 that logs all syscalls.

[0033] In addition, the LKM 100 further includes a filter 130 coupled to and in communication with the callback function 120 for filtering syscalls having an identification (ID) of the specific process; and a storage unit 140 coupled to and in communication with the filter 130 for storing indexes and parameters of syscalls related to the specific process.

[0034] Analyze the collected / monitored syscall information for different application scenarios15, such as optimizing system performance, detecting potential system risks, analyzing user behavior, making corresponding system settings, determining which types of applications are using the collected syscalls, system debugging, etc.

[0035] In some embodiments, the method selectively collects / monitors syscalls of only a specific process. It should be noted that the method can also be used to collect / monitor syscalls of different processes and / or all processes. According to the present invention, the method of collecting and monitoring system calls from user space minimizes system resource consumption and ensures the accuracy of the collected data.

[0036] refer to Figure 2 , a flowchart of a method for collecting system calls of a specific process is shown according to some embodiments of the present invention.

[0037] According to the method, in step 210, an io control (ioctl) interface is provided from a Linux kernel module (LKM), the LKM including a function callback function, configured so that when ioctl is used, the kernel module registers a callback function for a trace point, and all system calls (syscalls) pass through the callback function.

[0038] In some examples, the ioctl is set in user space to communicate with the LKM in kernel space.

[0039] In some examples, the LKM further includes an LKM entry in communication with the callback function, wherein in operation, the user calls the LKM entry through the ioctl; a filter in communication with the callback function, configured to filter syscalls having the ID of the specific process; and a storage unit in communication with the filter, configured to store indexes and parameters of syscalls related to the specific process.

[0040] In some examples, the structure of the function callback functionality includes task_struct and pt_regs.

[0041] In some examples, the task_struct records details of all processes that call sys_entry, and wherein the pt_regs contains the number of the syscall and register values ​​stored in a central processing unit (CPU).

[0042] According to the method, at step 220 , syscalls having an identification (ID) of a specific process are filtered.

[0043] According to the method, at step 230 , the index and parameters of the syscall associated with the specific process are stored.

[0044] In some examples, filtering the syscall with the ID includes checking a thread group ID (tgid) within the task_struct to confirm whether it is the syscall of the specific process. Storing the index and the parameters of the syscall includes storing the syscall id and the parameters from the pt_regs when confirming that the syscall is the syscall of the specific process.

[0045] In some examples, the method may also include analyzing syscalls to optimize system performance, detect potential system risks, analyze user behavior, make corresponding system settings, and / or determine which types of applications are using the collected syscalls, and / or trace syscalls for system debugging.

[0046] It should be noted that all or part of the steps of the method according to an embodiment of the present invention are implemented by hardware or a software module executed by a processor, or by a combination thereof. In one aspect, the present invention provides a system comprising at least one processor configured to execute the method for collecting system calls of a specific process as described above.

[0047] Another aspect of the present invention provides a non-transitory, tangible computer-readable medium storing instructions that, when executed by one or more processors, cause the system to perform the method disclosed above for collecting system calls for a specific process. The computer-executable instructions or program code enable a computer or similar computing system to perform various operations in the method disclosed above for gazing rendering of panoramic media content. The storage medium / memory may include, but is not limited to, high-speed random access media / memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices, and non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, other non-volatile solid-state storage devices, or any other type of non-transitory, computer-readable recording medium, as is well known in the art.

[0048] It should be understood that the specific order or hierarchy of blocks in the flow charts / flowcharts is an illustration of an exemplary method. It should be understood that the specific order or hierarchy of blocks in the flow charts / flowcharts may be rearranged based on design preferences. Furthermore, some blocks may be combined or omitted. The accompanying method claims present the elements of the various blocks in an example order and are not intended to be limited to the specific order or hierarchy presented. The foregoing description is intended to enable any skilled person to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not limited to the aspects shown herein, but rather to the scope of the claim language consistent with which reference is made, wherein a reference to a singular element does not mean "only one" unless specifically so stated, but rather "one or more." The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects. The term "some" refers to one or more unless specifically stated otherwise. Combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" may include only A, only B, only C, A and B, A and C, B and C, or A, B, and C, where any such combination may include one or more members of A, B, or C. All structural and functional equivalents to the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill are hereby expressly incorporated herein and are intended to be encompassed by the claims. In addition, nothing disclosed herein is intended to be dedicated to the public regardless of whether it is explicitly recited in the claims. The words “module,” “mechanism,” “element,” “device,” etc. may not be substitutes for “means.” Therefore, no claim element should be construed as comprising a means for function unless the element is explicitly stated using the phrase “means for.”

Claims

1. A method for collecting system calls of a specific process, characterized in that: include: Provides an io control ioctl interface from the Linux kernel module LKM. The LKM includes a function callback function. When ioctl is used, the kernel module registers a callback function for the tracepoint, and all system calls syscall through the callback function. Filtering for syscalls with the identification ID of that specific process; and Stores the index and arguments of this syscall relevant to this particular process.

2. The method according to claim 1, wherein The ioctl is set in the user space and communicates with the LKM in the kernel space.

3. The method according to claim 1, wherein The LKM further comprises: The LKM entry that communicates with the callback function. During operation, the user calls the LKM entry through the ioctl; a filter that communicates with the callback function to filter syscalls with that ID for that specific process; and A storage unit in communication with the filter is used to store the index and parameters of the syscall associated with the specific process.

4. The method according to claim 1, wherein The callback function contains the structures task_struct and pt_regs.

5. The method according to claim 4, wherein The task_struct records the details of all processes that call sys_entry, and wherein the pt_regs contains the number of the syscall and the register values ​​stored in the central processing unit (CPU).

6. The method according to claim 5, wherein The filtering of the syscall with the ID includes checking the thread group ID (tgid) in the task_struct to confirm whether it is the syscall of the specific process; as well as Storing the index and parameters of the syscall includes storing the identifier of the syscall and the parameters from the pt_regs when confirming the syscall for the specific process.

7. The method according to claim 1, wherein Further including: Analyze the syscalls to optimize system performance, detect potential system risks, analyze user behavior, make appropriate system settings, and / or determine what type of applications are using the collected syscalls, and / or Trace this syscall for system debugging.

8. A system for collecting system calls of a specific process, characterized in that include: At least one processor is configured to execute a method for collecting system calls of a specific process, the method comprising: Provides an io control (ioctl) interface from a Linux kernel module (LKM). The LKM includes a function callback function. When ioctl is used, the kernel module registers a callback function for the tracepoint, and all system calls (syscalls) go through the callback function. Filter syscalls with the ID of a specific process; as well as Stores the index and arguments of this syscall relevant to this particular process.

9. The system according to claim 8, wherein The ioctl is set in the user space and communicates with the LKM in the kernel space.

10. The system according to claim 8, wherein The LKM further comprises: The LKM entry that communicates with the callback function. During operation, the user calls the LKM entry through the ioctl; a filter that communicates with the callback function to filter syscalls with that ID for that specific process; and A storage unit in communication with the filter is used to store the index and parameters of the syscall associated with the specific process.

11. The system according to claim 8, wherein The callback function contains the structures task_struct and pt_regs.

12. The system according to claim 11, wherein The task_struct records the details of all processes that call sys_entry, and wherein the pt_regs contains the number of the syscall and the register values ​​stored in the central processing unit (CPU).

13. The system according to claim 12, wherein: The filtering of the syscall with the ID includes checking the thread group ID (tgid) in the task_struct to confirm whether it is the syscall of the specific process; as well as Storing the index and the parameters of the syscall includes storing the identifier of the syscall and the parameters from the pt_regs when confirming the syscall for the specific process.

14. The system according to claim 8, wherein The method further comprises: Analyze the syscalls to optimize system performance, detect potential system risks, analyze user behavior, make appropriate system settings, and / or determine what type of applications are using the collected syscalls, and / or Trace this syscall for system debugging.

15. A non-transitory tangible computer-readable medium, characterized in that The device is used to store instructions that, when executed by one or more processors, form a method for executing and collecting system calls for a specific process, the method comprising: Provides an io control (ioctl) interface from a Linux kernel module (LKM). The LKM includes a function callback function. When ioctl is used, the kernel module registers a callback function for the tracepoint, and all system calls (syscalls) go through the callback function. Filtering syscalls with the ID of that particular process; and Stores the index and arguments of this syscall relevant to this particular process.

16. The non-transitory tangible computer readable medium of claim 15, wherein: The ioctl is set in the user space and communicates with the LKM in the kernel space.

17. The non-transitory tangible computer readable medium of claim 15, wherein the LKM further comprises: The LKM entry that communicates with the callback function. During operation, the user calls the LKM entry through the ioctl; a filter that communicates with the callback function to filter syscalls with that ID for that specific process; and A storage unit in communication with the filter is used to store the index and parameters of the syscall associated with the specific process.

18. The non-transitory tangible computer readable medium of claim 15, wherein: The callback function contains the structures task_struct and pt_regs.

19. The non-transitory tangible computer readable medium of claim 18, wherein: The task_struct records the details of all processes that call sys_entry, and wherein the pt_regs contains the number of the syscall and the register values ​​stored in the central processing unit (CPU).

20. The non-transitory tangible computer readable medium of claim 19, wherein: The filtering of the syscall with the ID includes checking the thread group ID (tgid) in the task_struct to confirm whether it is the syscall of the specific process; as well as Storing the index and the parameters of the syscall includes storing the identifier of the syscall and the parameters from the pt_regs when confirming the syscall for the specific process.

21. The non-transitory tangible computer readable medium of claim 15, wherein: The method further comprises: Analyze the syscall to optimize system performance, detect potential system risks, analyze user behavior, make appropriate system settings, and / or determine which type of application is using the collected syscall, and / or Trace this syscall for system debugging.

Images