System call processing method and device

Abstract

The embodiment of the invention provides a system call processing method and device.The system call processing method comprises the steps that a kernel space of an operating system conducts return address detection on a system call request initiated by a user process, intercepting the system call request and sending abnormal call information of the system call request to the user process under the condition that the detection is not passed, and carrying out abnormal call reporting and call admission detection by the user process and initiating a secondary call request after the call admission detection is passed; and the kernel space carries out request processing on a secondary calling request initiated by the user process so as to realize system calling of the operating system.

Description

Technical Field

[0001] This document relates to the field of operating system technology, and in particular to a system call processing method and device. Background Art

[0002] The operating system is system software that manages computer hardware and software resources, including two different processor operating modes: kernel state and user state. Kernel state is the core of the operating system. It abstracts and encapsulates various underlying hardware and exposes interfaces for user programs to use. Unlike user state, kernel state has high operating permissions. Once a security vulnerability occurs, it will directly affect the entire operating system and user programs. How to avoid security vulnerabilities is a focus of common concern for users and service agencies. Summary of the invention

[0003] One or more embodiments of the present specification provide a system call processing method, which is applied to the kernel space of an operating system, and the method includes: responding to a system call request initiated by a user process in the user space, performing a return address detection on the system call request; if the detection fails, intercepting the system call request, and sending abnormal call information of the system call request to the user process, so as to perform abnormal call reporting and call access detection through the user process. Receiving a secondary call request initiated by the user process after the call access detection passes and performing request processing.

[0004] One or more embodiments of this specification provide a system call processing device that runs in the kernel space of an operating system, and the device includes: a detection module, which is configured to respond to a system call request initiated by a user process in the user space and perform a return address detection on the system call request; if the detection fails, an interception module is run, and the interception module is configured to intercept the system call request and send abnormal call information of the system call request to the user process, so as to perform abnormal call reporting and call access detection through the user process. A request processing module is configured to receive a secondary call request initiated by the user process after the call access detection passes and perform request processing.

[0005] One or more embodiments of the present specification provide a system call processing device, including: a processor; and a memory configured to store computer executable instructions, wherein when the computer executable instructions are executed, the processor: the kernel space of the operating system responds to the system call request initiated by the user process in the user space, and performs a return address detection on the system call request; if the detection fails, the system call request is intercepted, and the abnormal call information of the system call request is sent to the user process, so as to perform abnormal call reporting and call access detection through the user process. A secondary call request initiated by the user process after the call access detection passes is received and the request is processed.

[0006] One or more embodiments of the present specification provide a computer-readable storage medium for storing computer-executable instructions, which implement the following process when executed: the kernel space of the operating system responds to the system call request initiated by the user process in the user space, and performs a return address detection on the system call request; if the detection fails, the system call request is intercepted, and the abnormal call information of the system call request is sent to the user process, so as to perform abnormal call reporting and call access detection through the user process. A secondary call request initiated by the user process after the call access detection passes is received and the request is processed. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to more clearly illustrate one or more embodiments of the present specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative labor. Figure 1 A schematic diagram of an implementation environment of a system call processing method provided by one or more embodiments of this specification; Figure 2 A processing flow chart of a system call processing method provided by one or more embodiments of this specification; Figure 3 A schematic diagram of a system call processing process applied to a system call detection scenario provided by one or more embodiments of this specification; Figure 4 A processing flow chart of a system call processing method applied to a system call detection scenario provided by one or more embodiments of this specification; Figure 5 A schematic diagram of an embodiment of a system call processing device provided by one or more embodiments of this specification; Figure 6A schematic diagram of the structure of a system call processing device provided for one or more embodiments of this specification. DETAILED DESCRIPTION

[0008] In order to enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below in conjunction with the drawings in one or more embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on one or more embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this document.

[0009] The system call processing method provided in one or more embodiments of this specification can be applied to the implementation environment of system call processing of the operating system. Figure 1 , the implementation environment at least includes: an operating system 101; The operating system 101 runs on the terminal device and includes a user space 101-1 and a kernel space 101-2; the user space 101-1 is used to initiate a system call request through a user process; the kernel space 101-2 is used to process the system call request initiated by the user process; In addition, the kernel space 101 - 2 is also configured with a filter for performing return address detection; In this implementation environment, the user process in the user space 101-1 initiates a system call request, and the kernel space 101-2 responds to the system call request and uses a filter to detect the return address of the system call request; if the detection fails, the system call request is intercepted and abnormal call information is sent to the user process in the user space 101-1. After the user process performs abnormal call reporting and call access detection, a secondary call request is initiated. The kernel space 101-2 receives the secondary call request initiated by the user process and processes the request.

[0010] One or more embodiments of a system call processing method provided in this specification are as follows: Reference Figure 2 The system call processing method provided in this embodiment can be applied to the kernel space of the operating system. The method specifically includes steps S202 to S206.

[0011] Step S202: In response to a system call request initiated by a user process in the user space, a return address detection is performed on the system call request.

[0012] In this embodiment, the operating system is a program that manages computer hardware and software resources. It is an interface between the user and the computer hardware. It provides an interface that the user can understand and interact with, and is also responsible for executing various application programs. For example, desktop operating systems include Microsoft Windows and macOS; mobile operating systems include Android (based on the Linux kernel) operating system and iOS (developed by Apple) operating system.

[0013] The user space includes the execution space corresponding to the user state of the operating system. In addition, the user space can also be a user module. The user state of the operating system runs applications, and the code in the user state cannot directly access hardware resources or execute privileged instructions, thereby preventing ordinary applications from directly operating key parts of the system, thereby improving the security of the system. The corresponding processing is performed by the user process in the user state. Each user process in the user state has its own address space and is isolated from each other to prevent one user process from interfering with another user process. In addition to the user state, the operating system also includes the kernel state. The kernel space in this embodiment includes the execution space corresponding to the kernel state of the operating system. In addition, it can also be a kernel module. When the user state needs to access the underlying resources (such as file I / O, network communication), it must request the kernel to complete it through the system call interface; the code in the kernel state has a high level of permissions, can directly access all hardware resources and memory areas, and can execute any instructions. Since the kernel state has the highest permissions, any errors or problems may cause the operating system to crash.

[0014] In actual applications, when a user performs application operations such as file access, network access and / or command execution on an application, a system call is initiated through the user process; after the user process initiates the system call, in order to ensure the safe, correct and efficient execution of the system call, the kernel space of the operating system performs request processing of the system call request.

[0015] In this embodiment, by configuring detection logic in the kernel space, the kernel space performs return address detection on the system call request in the process of responding to the system call request initiated by the user process. In this way, the vulnerability protection method of finding as many API (Application Programming Interface) calls as possible in the user state and intercepting each API is avoided. The method cannot find all APIs and cannot handle the operation of directly using the system call command to execute the system call, thereby improving the comprehensiveness and flexibility of vulnerability protection.

[0016] In specific implementation, the return address detection of the system call request in the kernel space can be achieved by setting a device filter in the kernel space. For example, in the Linux operating system, seccomp bpf (Secure Computing Mode with Berkeley Packet Filter) can be used to set a filter in the Linux operating system kernel space to detect the return address of the system call request through the filter.

[0017] Since there are various call types of system call requests, among which some call types of system call requests will not trigger vulnerabilities and cause exceptions, it is not necessary to detect and intercept all system call requests. Based on this, in this embodiment, the detection call type that needs to be detected and intercepted can be pre-configured. When the kernel space detects that the call type of the system call request initiated by the user process is the detection call type, it performs a return address detection on the system call request; in an optional implementation provided by this embodiment, in order to avoid the waste of resources caused by detecting all call types of system call requests, after receiving the system call request initiated by the user process, the kernel space first detects whether the call type of the system call request is the detection call type, and if so, performs a return address detection on the system call request, and if not, directly performs the request processing of the system call request. Optionally, the detection call type in this embodiment includes at least one of the following: file access call type, network access call type, and command execution call type.

[0018] For example, in a Linux operating system, a user process in user state initiates a system call request according to a file access instruction, and switches to kernel state. The kernel space first detects whether the file access call type of the system call request is a detection call type. If so, the filter set by the seccomp bpf mechanism performs a return address detection on the system call request; if not, the system call is allowed and the operation corresponding to the system call request is executed; wherein, during the return address detection, the filter detects whether the return address in the system call request is a stored type access address. If so, the detection pass result SECCOMP_RET_ALLOW is returned; if not, the detection fail result SECCOMP_RET_TRAP is returned; further, if the kernel space detects that the filter returns the detection result SECCOMP_RET_ALLOW, the detection is determined to be passed; if the filter returns the detection result SECCOMP_RET_TRAP, the detection is determined to be failed. It should be noted that in order to implement the hook of the system call request, the type access address of the call type can be configured as an address that is different from the return address of the system call request, so as to ensure that the return address detection of the system call request cannot pass. Optionally, hook technology is used to intercept or modify function calls, messages, events and / or system behaviors; through hook technology, custom code can be inserted before or after the target function or event occurs, thereby changing or enhancing its behavior.

[0019] Optionally, a filter may be configured for each detection call type, and only the type access address of the corresponding detection call type is written into each filter. Specifically, after detecting that the call type of the system call request is the detection call type, the system call request is input into the filter corresponding to the call type for return address detection to obtain the detection result returned by the filter. In addition, only one filter may be configured, and the filter is written into the type access address of each detection call type. After detecting that the call type of the system call request is the detection call type, the system call request is input into the filter for return address detection according to the call type to obtain the detection result returned by the filter.

[0020] Taking the Linux operating system as an example, the system calls corresponding to file access, network access and command execution include: NR_openat, NR_bind, NR_connect and NR_execve. Among them, the openat system call is used to open or create a file, the bind system call is used to bind a local address to a socket, the connect system call is used to connect a socket to a remote address, and the execve system call is used to execute a new program. If the detection call types pre-configured in the kernel space include these four types, then after receiving the system call request initiated by the user process, it is detected whether the call type of the system call request is one of the four types. If so, it is determined that the call type of the system call request is the detection call type. If not, the system call corresponding to the system call request is executed.

[0021] During specific implementation, a type access address may be configured for each detection call type. After receiving a system call request initiated by a user process and determining that the call type of the system call request is a detection call type, a return address detection is performed on the system call request. In an optional implementation provided by this embodiment, during the process of performing return address detection on the system call request, it is detected whether the return address of the system call request is a type access address. If so, it is determined that the detection has passed, and request processing of the system call request is performed, that is, the system call corresponding to the system call request is executed. If not, it is determined that the detection has failed.

[0022] Step S204: if the detection fails, the system call request is intercepted, and abnormal call information of the system call request is sent to the user process, so as to perform abnormal call reporting and call admission detection through the user process.

[0023] In this embodiment, when the return address check of the system call request fails, in order to ensure the security of the system call, the system call request is intercepted and abnormal call information of the system call request is sent to the user process so that the user can perform a call access check on the system call request.

[0024] In specific implementation, if the detection result returned by the filter indicating that the detection failed is obtained, the system call request is intercepted, and the abnormal call information of the system call request is sent to the user process. Due to the particularity of the user space and the kernel space, the kernel space sends an abnormal call signal to the user process to complete the sending of the abnormal call information in the process of sending the abnormal call information containing the system call request to the user process. Since the user process needs to use the context information of the system call request, that is, the system call parameters, in the process of reporting the abnormal call and calling the access detection, therefore, in an optional implementation mode provided by this embodiment, in the process of sending the abnormal call information of the system call request to the user process, the system call parameters corresponding to the system call request are first obtained, and then the abnormal call information is generated according to the system call request and the system call parameters and sent to the user process, or, the abnormal call signal is generated according to the system call parameters of the system call request and sent to the user process.

[0025] Optionally, the system call parameters include system call parameters and / or system call context information of a call stack (register values, stack pointers, program counters, etc. that initiate a system call request).

[0026] In the specific execution process, the kernel space sends the abnormal call signal SIGSYS (SIGnal SYStem call badargument, system call error parameter) to the user space. After the user process in the user space captures the abnormal call signal, on the one hand, it performs call access detection based on the abnormal call information to determine whether a system call can be made based on the system call request. On the other hand, it reports the abnormal call information, so that the server records the abnormal system call information, and then manages the operation of the corresponding application based on the abnormal call information, thereby improving the effectiveness of call access detection. The following specifically describes the abnormal call reporting and call access detection of the user process.

[0027] (1) Abnormal call reporting During the specific execution process, in order to improve the effective management of the application, the user process reports the exception call information after detecting the exception call information sent by the kernel space. In an optional implementation provided by this embodiment, during the process of reporting the exception call, the user process asynchronously sends the exception call information to the server of the application corresponding to the user process, so as to update the path detection strategy for call access detection based on the exception call information.

[0028] Specifically, after obtaining the abnormal call information, the server may send the abnormal call information to the service user so that the service user can update the path detection strategy based on the abnormal call information; for example, the abnormal call information can be input into the sensitive path detection model to perform sensitive path detection on the call path in the abnormal call information to obtain the detection result. If the detection result is yes, the sensitive path is updated to the path detection strategy, and if not, no processing is performed. Optionally, the path detection strategy is loaded and stored in the user process after the user process is started or created, or the path detection strategy is loaded and stored after the application corresponding to the user process is started.

[0029] For example, the call path included in the abnormal call information of the system call request is the call path of a file, and the file is a sensitive file. After the service user or the sensitive path detection model detects that the call path of the file is a sensitive call path, the sensitive call path is updated to the sensitive call path table, and the updated sensitive call path is obtained so that the user process can load and store it.

[0030] (2) Call access detection In the specific execution process, after detecting the abnormal call information sent by the kernel space, the user process performs a call admission detection according to the abnormal call information. In order to ensure the security of the system call, in an optional implementation mode provided in this embodiment, the user process performs the following operations during the call admission detection: Perform path access detection on the call path in the abnormal call information according to the path detection strategy; If the path admission detection passes, it is determined that the call admission detection passes, and according to the type admission address corresponding to the call type of the system call request, the return address of the system call request is updated to obtain a secondary call request; When the path admission check fails, it is determined that the call admission check fails, and the system call request is intercepted.

[0031] After intercepting a system call request, an interception prompt may be displayed in order to let the user who submitted the system call request know about the interception.

[0032] Specifically, when the user process detects that the call path in the exception call information is a sensitive call path in the sensitive call path table, the system call request is intercepted. When the user process detects that the call path in the exception call information is not a sensitive call path in the sensitive call path table, it is determined that the system call request can be executed normally. Therefore, the return address of the system call request is updated according to the type access address corresponding to the call type of the system call request, and a secondary call request is obtained and initiated.

[0033] In addition, step S204 can also be replaced by, if the detection fails, intercepting the system call request, and sending abnormal call information of the system call request to the user process, so as to perform call access detection through the user process, and form a new implementation method with one or more other processing steps provided in this embodiment.

[0034] Step S206, receiving a secondary call request initiated by the user process after the call admission detection passes and performing request processing.

[0035] After the above-mentioned user process performs asynchronous exception call reporting and call access detection, a secondary call request is initiated if the call access detection passes. On this basis, the kernel space receives the secondary detection request initiated by the user process after the call access detection passes and processes the request.

[0036] The return address of the secondary call request is different from the return address of the system call request, and the others may be the same. In this embodiment, the secondary call request may be a proprietary call request, and the proprietary call request includes a system call request whose return address is a type access address generated after the call access detection of the system call request passes. In order to use the hook technology to achieve trusted access to the system call request, the filter may only determine the detection result of the proprietary call request as passed during the return address detection process, and the detection results of other system call requests are all failed, thereby achieving interception of the system call.

[0037] In an optional implementation manner provided by the present embodiment, in the process of the kernel space receiving a secondary call request initiated by a user process and performing request processing, similar to the system call request, it is first detected whether the call type of the secondary call request is a detection call type. If not, request processing of the secondary call request is performed. If so, a return address detection is performed on the secondary call request. If the detection passes, request processing of the secondary call request is performed. If the detection fails, abnormal call information of the secondary call request is sent to the user process.

[0038] Since the call type of the secondary call request is consistent with that of the system call request, the filter is also required to perform return address detection on the secondary call request. Since the return address of the secondary call request has been updated to the type access address corresponding to the call type, the filter returns a detection result of passing the detection. For example, after the kernel space detects the result SECCOMP_RET_ALLOW returned by the filter, it executes the operation corresponding to the system call request.

[0039] It should be noted that, in this embodiment, the processing results of the request processing of the system call request and the request processing of the secondary call request are set to the register storing the system call result.

[0040] In summary, in the system call processing method provided by the embodiment of the present application, the kernel space of the operating system responds to the system call request initiated by the user process of the application in the user space, and performs return address detection on the system call request; in this process, a system call filter can be set in the kernel space, so that the filter performs return address detection on the received system call request of the detection call type and returns the detection result; When the kernel space obtains the detection result returned by the filter that the detection fails, it sends an abnormal call signal of the system call request to the user process; after the user process captures the abnormal call signal sent by the kernel space, it uses the path detection strategy to perform call access detection on the abnormal call signal. If the user process detects that the call access detection passes, it reads the type access address corresponding to the call type in the pre-configured access address record table according to the call type contained in the abnormal call signal, uses the type access address as the return address and initiates a secondary system call; In addition to call admission detection, the user process can also report the abnormal call information to update the path detection strategy according to the abnormal call information to ensure the effectiveness of the path detection strategy, thereby improving the accuracy and effectiveness of call admission detection. If the user process detects that the call admission detection passes, it reads the type admission address corresponding to the call type in the pre-configured admission address record table according to the call type contained in the abnormal call signal, uses the type admission address as the return address and initiates a secondary system call; After the kernel space receives the secondary system call initiated by the user process, when the call type of the secondary system call is a detection call type, the return address of the secondary call request is detected through the filter. The kernel space executes the operation corresponding to the secondary call request according to the detection result returned by the filter. In this way, by setting the filter, it is impossible to bypass the system call to trigger the vulnerability of the application, thereby improving the security of the application and ensuring the trusted operation of the application.

[0041] The following takes the application of a system call processing method provided in this embodiment in a system call detection scenario as an example, combined with Figure 3 and Figure 4 , the system call processing method provided in this embodiment is further described, see Figure 4 , a system call processing method applied to a system call detection scenario specifically includes the following steps.

[0042] like Figure 3As shown, the operating system includes user space and kernel space, and the seccomp bpf is used to set the filter in the kernel space, wherein the filter can be set in the kernel space through the following statement: Prctl (PR_SET_SECCOMP, SECCOMP_MODE_FILTER, ...); obtain Seccomp BPF: filier1, filier2, filier3, ...; the user process in the user space initiates a system call request, and the system call request can be initiated through the system / open svc#0 statement, that is, the svc request; the kernel space receives the system call request and after detecting that the call type of the system call request is the detection call type, the return address of the system call request is detected through the filter, and according to the detection result SECCOMP_RET_TRAP returned by the filter, the SIGSYS signal of the system call request is generated and sent to the user process; after the user process detects the SIGSYS signal, a call admission detection (Handle SIGSYS, proprietary svc#0, the result is set back to the original svc), and asynchronously reports the abnormal call. If the call access detection passes, a proprietary call request is initiated. After the kernel space receives the proprietary call request and determines that the call type of the proprietary call request is the detection call type, the return address of the proprietary call request is detected through the filter. According to the detection result SECCOMP_RET_ALLOW returned by the filter, the system call (system call in kernel) corresponding to the proprietary call request is executed.

[0043] Step S402: receiving a system call request initiated by a user process in the user space.

[0044] Step S404, detecting whether the call type of the system call request is a detection call type; If yes, execute step S406; If not, perform request processing of the system call request.

[0045] Optionally, after request processing of the system call request is performed, the processing result is set to a result register of the system call request.

[0046] Step S406, detecting through a filter whether the return address of the system call request is a type admission address of the call type; If so, perform request processing of the system call request; If not, execute steps S408 to S414.

[0047] Step S408: Generate an abnormal call signal of the system call request and send it to the user process, so as to perform abnormal call reporting and call admission detection through the user process.

[0048] Optionally, the user process receives an abnormal call signal, and performs abnormal call reporting and call admission detection according to the abnormal call signal.

[0049] Step S410, receiving a dedicated call request initiated by a user process after passing the call admission detection.

[0050] Step S412: According to the detection call type of the proprietary call request, a filter is used to detect whether the return address of the system call request is a type access address of the call type.

[0051] Step S414: Process the proprietary call request according to the detection result returned by the filter.

[0052] Optionally, after making a dedicated call request, the processing result is set to the result register of the system call request.

[0053] It should be noted that any one of steps S402 to S414 or any combination of multiple steps can be combined with any one of steps S202 to S206 to form a new implementation method according to the needs of implementation deployment; in addition, according to the needs of actual deployment, any one or multiple technical features can be selected from steps S402 to S414 and combined with any one or multiple technical features provided by steps S202 to S206 to form a new implementation method; or, any one or multiple technical features in steps S402 to S414 can be replaced with any one or multiple technical features provided by steps S202 to S206 to form a new implementation method according to the needs of actual deployment, which will not be elaborated here.

[0054] An embodiment of a system call processing device provided in this specification is as follows: In the above-mentioned embodiment, a system call processing method is provided, and correspondingly, a system call processing device is also provided, which is described below with reference to the accompanying drawings.

[0055] Reference Figure 5 , which shows a schematic diagram of an embodiment of a system call processing device provided by this embodiment.

[0056] Since the device embodiment corresponds to the method embodiment, the description is relatively simple, and the relevant parts can refer to the corresponding description of the method embodiment provided above. The device embodiment described below is only illustrative.

[0057] This embodiment provides a system call processing device, which runs in the kernel space of an operating system, and the device includes: The detection module 502 is configured to respond to a system call request initiated by a user process in the user space and perform a return address detection on the system call request; If the detection fails, the interception module 504 is run, and the interception module 504 is configured to intercept the system call request and send abnormal call information of the system call request to the user process, so as to perform abnormal call reporting and call admission detection through the user process; The request processing module 506 is configured to receive a secondary call request initiated by the user process after the call admission detection passes and perform request processing.

[0058] An embodiment of a system call processing device provided in this specification is as follows: Corresponding to the system call processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a system call processing device, which is used to execute the system call processing method provided above. Figure 6 A schematic diagram of the structure of a system call processing device provided for one or more embodiments of this specification.

[0059] This embodiment provides a system call processing device, including: like Figure 6 As shown, the system call processing device may have relatively large differences due to different configurations or performances, and may include one or more processors 601 and memory 602, and the memory 602 may store one or more storage applications or data. Among them, the memory 602 may be a temporary storage or a permanent storage. The application stored in the memory 602 may include one or more modules (not shown in the figure), and each module may include a series of computer executable instructions in the system call processing device. Furthermore, the processor 601 may be configured to communicate with the memory 602, and execute a series of computer executable instructions in the memory 602 on the system call processing device. The system call processing device may also include one or more power supplies 603, one or more wired or wireless network interfaces 604, one or more input / output interfaces 605, one or more keyboards 606, etc.

[0060] In a specific embodiment, the system call processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer executable instructions in the system call processing device, and the one or more programs configured to be executed by one or more processors include computer executable instructions for performing the following: The kernel space of the operating system responds to the system call request initiated by the user process in the user space and performs return address detection on the system call request; If the detection fails, the system call request is intercepted, and abnormal call information of the system call request is sent to the user process, so as to perform abnormal call reporting and call admission detection through the user process; Receive a secondary call request initiated by the user process after the call admission detection passes and process the request.

[0061] An embodiment of a computer-readable storage medium provided in this specification is as follows: Corresponding to the system call processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a computer-readable storage medium.

[0062] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, and the computer-executable instructions implement the following process when executed: The kernel space of the operating system responds to the system call request initiated by the user process in the user space and performs return address detection on the system call request; If the detection fails, the system call request is intercepted, and abnormal call information of the system call request is sent to the user process, so as to perform abnormal call reporting and call admission detection through the user process; Receive a secondary call request initiated by the user process after the call admission detection passes and process the request.

[0063] It should be noted that an embodiment of a computer-readable storage medium in this specification and an embodiment of a system call processing method in this specification are based on the same inventive concept, so the specific implementation of this embodiment can refer to the implementation of the aforementioned corresponding method, and the repeated parts will not be repeated.

[0064] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. For example, the device embodiment, equipment embodiment and computer-readable storage medium embodiment are similar to the method embodiment, so the description is relatively simple. To read the relevant contents in the device embodiment, equipment embodiment and computer-readable storage medium embodiment, please refer to the partial description of the method embodiment.

[0065] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0066] In the 1930s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many of today's method flow improvements can be regarded as direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0067] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.

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

[0069] For the convenience of description, the above devices are described in terms of functions and are divided into various units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0070] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present specification may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0071] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0072] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0073] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0075] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

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

[0077] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of further restrictions, the elements defined by the sentence "includes at least one ..." do not exclude the presence of other identical elements in the process, method, commodity or device including the elements.

[0078] One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0079] The above description is only an embodiment of this document and is not intended to limit this document. For those skilled in the art, this document may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this document should be included in the scope of the claims of this document.

Claims

1. A system call processing method, applied to the kernel space of an operating system, the method comprising: In response to a system call request initiated by a user process in a user space, performing return address detection on the system call request; If the detection fails, the system call request is intercepted, and abnormal call information of the system call request is sent to the user process, so as to perform abnormal call reporting and call admission detection through the user process; Receive a secondary call request initiated by the user process after the call admission detection passes and process the request.

2. The system call processing method according to claim 1, before performing a return address detection operation on the system call request, further comprising: Detecting whether the call type of the system call request is a detection call type; If yes, executing the return address detection operation on the system call request; If not, perform request processing of the system call request.

3. The system call processing method according to claim 2, wherein the detection call type comprises at least one of the following: a file access call type, a network access call type, and a command execution call type.

4. The system call processing method according to claim 1, wherein the performing return address detection on the system call request comprises: Detecting whether the return address of the system call request is a type access address; If yes, it is determined that the test has passed; If not, it is determined that the test has failed.

5. The system call processing method according to claim 1, wherein the call admission detection comprises: Performing path access detection on the call path in the abnormal call information according to the path detection strategy; If the path access check passes, it is determined that the call access check passes, and the return address of the system call request is updated according to the type access address corresponding to the call type of the system call request to obtain the secondary call request.

6. The system call processing method according to claim 5, after performing the path access detection operation on the call path in the abnormal call information according to the path detection strategy, further comprising: If the path access detection fails, it is determined that the call access detection fails, and the system call request is intercepted.

7. The system call processing method according to claim 5, wherein the abnormal call reporting comprises: The abnormal call information is asynchronously sent to a server of an application corresponding to the user process, so as to update the path detection strategy based on the abnormal call information.

8. The system call processing method according to claim 1, wherein the receiving a secondary call request initiated by the user process after the call admission detection passes and performing request processing comprises: Detecting whether the call type of the second call request is a detection call type; If yes, performing return address detection on the secondary call request; If the detection is passed, the request processing of the secondary call request is performed.

9. The system call processing method according to claim 1, wherein the sending the abnormal call information of the system call request to the user process comprises: Obtaining system call parameters corresponding to the system call request; The abnormal call information is generated according to the system call request and the system call parameters and sent to the user process.

10. The system call processing method according to claim 1, after performing a return address detection operation on the system call request, further comprising: If the detection passes, the request processing of the system call request is performed.

11. A system call processing device, running in the kernel space of an operating system, the device comprising: A detection module is configured to respond to a system call request initiated by a user process in the user space and perform return address detection on the system call request; If the detection fails, an interception module is run, wherein the interception module is configured to intercept the system call request and send abnormal call information of the system call request to the user process, so as to perform abnormal call reporting and call admission detection through the user process; The request processing module is configured to receive a secondary call request initiated by the user process after the call admission detection passes and perform request processing.

12. A system call processing device, comprising: processor; and a memory configured to store computer executable instructions that, when executed, cause the processor to: The kernel space of the operating system responds to the system call request initiated by the user process in the user space and performs return address detection on the system call request; If the detection fails, the system call request is intercepted, and abnormal call information of the system call request is sent to the user process, so as to perform abnormal call reporting and call admission detection through the user process; Receive a secondary call request initiated by the user process after the call admission detection passes and process the request.

13. A computer-readable storage medium for storing computer-executable instructions, wherein the computer-executable instructions implement the steps of the method of claim 1 when executed.

Images