Abstract:
The present disclosure relates to a system and method for monitoring system calls to an operating system kernel. A performance monitoring unit is used to monitor system calls and to gather information about each system call. The information is gathered upon interrupting the system call and can include system call type, parameters, and information about the calling thread/process, in order to determine whether the system call was generated by malicious software code. Potentially malicious software code is nullified by a malicious code counter-attack module.

Description:
FIELD OF THE DISCLOSURE 
       [0001]    The present disclosure relates to a system and method for monitoring system calls to an operating system kernel. A performance monitoring unit is used to monitor system calls and to gather information about each system call. The information is gathered upon interrupting the system call and can include system call type, parameters, and information about the calling thread/process, in order to determine whether the system call was generated by malicious software code. Potentially malicious software code is nullified by a malicious code counter-attack module. 
       BACKGROUND 
       [0002]    As computing devices become increasingly complex, malicious code such as viruses or malware also is becoming increasingly complex and difficult to detect and prevent. Continuous improvements are needed to identify and nullify such malicious code. 
         [0003]      FIG. 1  depicts an exemplary prior art computing device  100  comprising processor  110  and memory  120 . One of ordinary skill in the art will understand that processor  110  can include a single processor core or multiples processor cores as well as numerous cache memories, as is known in the prior art. Examples of processor  110  include Intel x86 and ARM-based processors. 
         [0004]    Processor  110  runs operating system  130  (such as Windows, Linux, OSX, iOS, and Android) and software applications  160 . Operating system  130  comprises kernel  140 . Among other things, kernel  140  serves as an interface between other portions of operating system  130  and software applications  160  one the one hand and the actual hardware of processor  110  on the other hand. Kernel  140  also manages system resources for processor  110 . 
         [0005]    Processor  110  also comprises performance monitoring unit (PMU)  150 . Performance monitoring unit  150  is used in many modern processor architectures, including ARM and Intel x86 processor architectures. Performance monitoring unit  150  is currently used for nonintrusive debugging and introspection, offering engineers or operating system  130  the ability to measure performance criteria of processor  110  such as CPU clock cycles, cache efficiency, or branch prediction efficiency and to help drive code optimizations. Performance monitoring unit  150  can be viewed as a counter of events within processor  110  using architecture-specific controls. Performance monitoring unit  150  can be configured to provide the data it captures to operating system  130  or software applications  160 . 
         [0006]    In  FIG. 2 , the concept of system calls is depicted. During operation of computer system  100 , any of software applications  160  can send system call  210  to kernel  140 . System call  210  is used to request a service from kernel  140 , such as a hardware-related service (such as writing to a disk drive) or the creation of a new process within operating system  130 . Although many system calls  210  are legitimate and desirable events, system calls  210  also can be used by malicious software (such as malware) to damage or misappropriate computer system  100  and/or a user&#39;s data. 
         [0007]    In  FIG. 3 , malicious software code  310  sends system call  210  to kernel  140  for a malicious purpose. Malicious software code  310  can comprise an entire software application or just lines of code injected into a legitimate software application  160 . 
         [0008]    Operating system  130  and certain software applications  160  currently provide some mechanisms to monitor system calls  210 . These mechanisms, however, are limited in their efficacy. Kernel patch protection exists in many operating systems  130  to prevent attackers from modifying and hooking system call dispatch tables. As a result, those software applications  160  that are intended to identify suspicious system calls are limited to user-space injection and hooking and do not operate at the level of kernel  140 . Thus, while kernel patch protection attempts to restrict the capabilities of malicious code, it also limits the ability to monitor and detect malicious system calls. 
         [0009]    What is needed is a mechanism to monitor system calls  210  and/or other interrupts and to gather information about each system call  210  and other interrupt in a way that avoids the kernel patch protection and the limitations of existing mechanisms. What is further needed to a mechanism to analyze the gathered information and to counter-attack potentially malicious code. 
       BRIEF SUMMARY OF THE INVENTION 
       [0010]    In one aspect of the invention, performance monitoring unit  150  is used to monitor system calls  210  and to gather information about each system call  210 . In the prior art, performance monitoring unit  150  has not been configured and used for this purpose. The data gathered by performance monitoring unit  150  can be analyzed to identify system calls  210  that potentially have been generated by malicious software code  310 . 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]      FIG. 1  depicts a prior art computing device. 
           [0012]      FIG. 2  depicts a system call generated by a software application to the kernel of an operating system. 
           [0013]      FIG. 3  depicts a system call generated by malicious software code to the kernel of an operating system. 
           [0014]      FIG. 4  depicts an embodiment comprising a hardware-assisted system and method for detecting system calls made to an operating system kernel. 
           [0015]      FIG. 5  depicts an embodiment for analyzing data generated by the embodiment of  FIG. 4  and to counteract potential malware. 
           [0016]      FIG. 6  depicts a method for detecting and analyzing system calls made to an operating system kernel, analyzing related data, and counteracting potential malware. 
           [0017]      FIG. 7  depicts the use of the embodiments to counteract a malware attack that utilizes return-oriented programming. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0018]    An embodiment is shown in  FIG. 4 . System call monitoring module  410  is executed by processor  110 . System call monitoring module  410  has special privileges and operates at the level of kernel  140 , and for purposes of this description can be considered as part of kernel  140 . System call monitoring module  410  configures performance monitoring unit  150  to trap system calls  210 , to gather the arguments for each system call  210 , and to provide some or all of the arguments of system call  210  to system call monitoring module  410  as monitoring data  420 . System call monitoring module  410  optionally can configure performance monitoring unit  150  to trap other types of interrupts in addition to system calls  210 . 
         [0019]    If processor  110  follows an ARM architecture, performance monitoring unit  150  can be configured to count and trap supervisor call instructions (which is an example of system call  210 ). The supervisor call exception vector is typically utilized by many operating systems (e.g. Android) to service system calls. As a result, trapping supervisor call instructions can effectively trap all system calls. 
         [0020]    If processor  110  follows an Intel x86 architecture, performance monitoring unit  150  can be configured to count Far branches that are destined for kernel  140 . This effectively encapsulates the Intel SYSCALL instruction (which generates system call  210 ) as well as various other hardware driven interrupts such as page faults. This enables the trapping and analyses of critical operating system events. 
         [0021]    Returning to  FIG. 4 , system call  211  is generated and sent to kernel  140 . System call  211  here is a specific instance of system call  210  described previously. At this moment in time, it is unclear whether system call  211  has been generated by software application  160  and is a legitimate system call or by malicious software code  310  and is a harmful system call. Monitoring data  420  here will include some or all of the arguments of system call  211 . 
         [0022]    With reference to  FIG. 5 , monitoring data  420  can comprise:
       information about the path to the file to be accessed by system call  211 ;   the memory address or range of addresses to be accessed by system call  211 ;   the context for the thread within operating system  120  that will be interrupted by system call  211 ;   the type of system call;   information about the socket that is being used by system call  211  in order to send or receive data;   the history of system calls in order to monitor for specific sequences of system calls  211 ;   the frequency or periodicity of a particular system call or set of systems calls; and   other information.       
 
         [0031]    Monitoring data  420  is provided to data analysis module  510 , which is a software application  160 . Data analysis module  510  uses known data analysis algorithms (such as machine learning algorithms, artificial intelligence algorithms, pattern recognition algorithms, or other known data analysis techniques) to analyze monitoring data  420  in light of previously stored data. Data analysis module  510  has the ability to learn from the previously stored data and monitoring data  420 . Data analysis module  510  can generate alert  520  if it determines that system call  211  likely has been generated by malicious software code  310 . 
         [0032]    Alert  520  is provided to malware counter-attack module  530 , which also is a software application  160 . Malware counter-attack module  530  can perform one or more of the following actions:
       identify malicious software code  310 ;   suspend malicious software code  310  from being further executed by processor  110 ;   delete malicious software code  310 ;   add malicious software code  310  to a list of code to not be executed;   instruct kernel  140  to ignore system call  211 ;   capture/save memory containing malicious code for further offline analysis;   modify malicious software code  310  to cause alternate behavior; and   other techniques for counter-attacking malicious software code  310 .       
 
         [0041]      FIG. 6  depicts system call monitoring and analysis method  600 . Malicious software code  310  generates system call  211  (step  610 ). Performance monitoring unit  150  is configured by system call monitoring module  410  and detects system call  211  and generates monitoring data  420  (step  620 ). Data analysis module  510  analyzes monitoring data  420  and generates alert  520  (step  630 ). Malware counter-attack module  530  receives alert  520  and performs malware counter-attack action (step  640 ). Malicious software code  310  is suspended or eradicated and system call  211  is ignored by operating system  130  (step  650 ). 
         [0042]    An example of a specific use case of the above embodiments is shown in  FIG. 7 . Return oriented programming malware prevention system  700  is depicted using components previously described in other Figures. Malicious shell code  710  is injected into memory  120  by a virus or other malware agent. Code-reuse attacks such as Return-Oriented Programming often rely on an attacker reusing existing code gadgets in order to mark malicious shell code  710  in memory  130  as executable before branching to it. This often requires the use of a system call  210  such as mprotect (when operating system  130  is Linux or Android) or VirtualProtect (when operating system  130  is Windows). Using the embodiments described herein, system  700  is able to detect and prevent return-oriented programming attacks. 
         [0043]    In another use case, monitoring of system calls  210  can be utilized to detect malicious software code  310  at various stages ranging from early shellcode to advanced persistent malware. The embodiments can be used to not only detect an initial malicious attack, but also to counter-attack malware that is running on a system that has already been infected. 
         [0044]    In another use case, trapping Far branches in processor  110  (when processor  110  follows the Intel x86 architecture) allows the system to interrupt the page fault handler running within operating system  130  (when operating system  130  is Windows). This will allow malware detection to apply memory protection policies that could detect exploitation attempts prior to any control-flow hijack even taking place. 
         [0045]    The embodiments described above provide a new system and method for detecting system calls using a module operating at the kernel level and the performance monitoring unit of a processor. Monitoring data is collected for each system call and analyzed using a data analysis module, which generates alerts that identify potential malicious software code. Any malicious software code can be counteracted by a malicious code counter-attack module. 
         [0046]    The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures which, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various different exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art. In addition, certain terms used in the present disclosure, including the specification, drawings and claims thereof, can be used synonymously in certain instances, including, but not limited to, for example, data and information. It should be understood that, while these words, and/or other words that can be synonymous to one another, can be used synonymously herein, that there can be instances when such words can be intended to not be used synonymously. Further, to the extent that the prior art knowledge has not been explicitly incorporated by reference herein above, it is explicitly incorporated herein in its entirety. All publications referenced are incorporated herein by reference in their entireties.