Application programs use system calls to request services from an operating system (OS. The OS provides various services that are available to the application. The application uses a system call to request that the OS perform one of these services.
There may be reasons to modify a system call's behavior. However, OS services are typically implemented through service routines that are part of the OS kernel. Therefore, modification of a system call's behavior typically involves modifying the kernel code that implements a particular system call's service routine. But modifying kernel code may not be practical. Some parties who wish to modify the behavior of a system call do not have access to the kernel source code. Even if a party does have access to the kernel source code, there may be reasons not to modify the kernel code (e.g., maintaining stability of the kernel, or avoiding a departure from the OS's standard behavior).
The behavior of a system call may be modified with little or no change to the operating system kernel. A modification component may be interposed between the application that makes the system call and the service routine that acts on the system call. The modification component may perform pre- and/or post-processing on the system call. For example, the modification component could change the arguments to the system call; or could replace one system call with another; or could change the return value and/or any side effects after the system call has executed; or could respond to the system call without invoking the service routine at all.
The modification component may be added to the system-call-processing infrastructure in various ways. For example, when system calls are invoked by applications through a set of library routines, the library routines could be altered to direct the system calls to the modification component instead of to the normal system call handler. Or, as another example, tables and/or pointers that are used in routing system calls to the appropriate service routines could be changed to route a system call to the modification component. These techniques, or other techniques, could be used to route a system call to the modification component.
Modified system call behavior could be used in a variety of ways. A system call could be modified to impose quality of service (QoS) constraints—e.g., limiting a process to requesting n megabytes of memory, or writing m bytes of data per unit of time. Or, a system call could be modified to allow one operating system to emulate another operating system—e.g., modifying system calls in a MICROSOFT WINDOWS operating system kernel to behave like Linux system calls do, or vice versa. Or, as a further example, system calls could be modified to provide information that normal system calls do not provide. For example, a system call that uses or affects memory (e.g., read, write, etc.) could be modified to provide the memory layout that the kernel has assigned to a process, and/or any changes to the layout that resulted from executing the system call. (Knowledge of the memory layout could be used by a security application to detect security violations—e.g., by tracking the movement of protected data, and determining whether protected data has been moved into a memory location that is available to an untrusted process.)
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
An operating system (OS) provides services that may be used by applications or other programs. Examples of services include input/output (I/O) operations (e.g., read, write, etc.), process operations (e.g., kill, fork, wait, etc.), or other kinds of operations. These services are typically exposed to the application through system calls. The system calls provide a known interface through which a program may obtain OS services. Additionally, the system calls abstract the implementation details of the service. That is, when a particular service is invoked, the service is expected to act within a defined range of behavior, but the details of how this behavior is implemented are normally opaque to the program that invokes the service.
There may be reason to change the behavior of a system call. Some example reasons to change a system call's behavior are:
To implement quality of service (QoS) constraints. For example, a system call that allocates memory to a process may have the technical capability to allocate arbitrary amounts of memory. But modified behavior of the system call might be to allocate memory while imposing, e.g., a 10 Mb per-process limit on the allocation.
To allow one OS to emulate the system calls of another OS. For example, the behavior of system calls in a MICROSOFT WINDOWS operating system kernel could be modified to behave like Linux system calls.
To provide information to applications that is not normally available through system calls. For example, system calls do not always inform an application process of the memory layout that the kernel has assigned to that process, or how I/O operations affect this layout. However, the OS has this information available, and therefore a system call could be modified to provide this information to processes (which may be useful, for example, to security applications that use knowledge of the memory layout, and of when that layout is affected, to detect and prevent security breaches). For example, any I/O operation (read, write, etc.) could causing pages to be swapped in or out of memory, which would modify the layout of memory. Another example is asynchronous I/O operations that modify the contents of memory without notifying appropriately the application. Thus, I/O system calls could be modified to report how carrying out of the system call has affected the memory mapping that the OS assigns to that process (e.g., how the system call has affected the physical location of data in the process's address space) or how this memory is being used.
The foregoing are some example reasons why one might want to modify the behavior of a system call, although the behavior of system calls could be modified for any reason.
The services that are accessed through system calls are normally implemented through service routines. Since the service routines are implemented by kernel components as part of the kernel, changing the behavior of a system call normally involves modifying the kernel code. However, modifying the kernel code may not be practical. The party who wants to modify the behavior of a system call might not have access to the kernel source code. Even if the party does have access to the source code, modifying the code of a complex OS may create stability issues. Moreover, in some cases the behavior modifications to be made are not universally-applicable. For example, one may want to modify the behavior of a system call for use in certain contexts, while having the system call behave in its normal fashion in other contexts. It may not be appropriate to modify the kernel's service routine to deal with a situation that applies only in certain contexts.
The subject matter herein may be used to modify the behavior of a system call, with little or no modification to the underlying kernel service routines through which the system call is implemented.
Turning now to the drawings,
Kernel components 112-116 may provide any type of service, such as I/O operations (e.g., read, write, etc.), process-related operations (e.g., wait, fork, kill, etc.), operations that control devices (e.g., turning a network card on or off), or any other type of operation. Kernel components may implement services that are native to a particular operating system, or may be add-ons, such as third-party device drivers. Some of the services provided may involve control of hardware 118 (e.g., a disk drive, a processor, physical memory, a network card, etc.) that is part of, or connected to, a machine on which operating system 108 operates. (Some services, such as killing a process, might involve tangential, although not direct, control of hardware 118.)
Kernel components 112-116 implement certain behaviors that may be invoked in response to system calls. However, these behaviors may be modified by service modifier 120. Service modifier 120 may be implemented in various ways. First, service modifier 120 may be implemented inside of operating system 108, or outside of operating system 108. (Service modifier 120 is depicted in
Each of
Each of
System call handler 210 receives a system call from some component user level 202 (e.g., from an application 206 or from another user-level program) and dispatches the call to the appropriate service routine. There are various ways in which system call handler 210 may receive the system call. In one example, an interrupt is generated at the user level, and data that identifies the service to be invoked, as well as any input to that service, is provided to the component that responds to system calls. When the interrupt is generated, system call handler is invoked and acts on the provided data. Certain hardware platforms allow system calls to be made through a sequence of instructions, which provides another way that a system call could be invoked. In order to make a system call, application 206 could generate an interrupt or could issue the appropriate instructions sequence. Application 206 could take these actions directly, or could make function calls that take the actions on behalf of application 206. For example, there may be a user modelibrary 224 (either a dynamically loaded library or a statically linked one) that provides functions corresponding to particular services and performs the appropriate system calls. Thus, if, for example, writing data to a file is a service, then library 224 may provide a function name “write”, which takes arguments (e.g., the data to be written, a descriptor of the file or device to which the data is to be written, etc.) and invokes the appropriate system call. For example, the function could generate an interrupt, or issue an appropriate instruction sequence, and could identify, to system call handler 210, the number of the service that performs the “write” operation, while also providing to system call handler 210 the arguments that were provided with the function call. The foregoing are some example ways in which system call handler 210 could be invoked, although system call handler 210 could be invoked in other ways.
When system call handler 210 is invoked, it may route the request represented by the system call to the appropriate service routine.
The heads of service tables 214 and 216 are identified by entries in descriptor table 212. For example entry 232 points to the head of service table 214, and entry 234 points to the head of service table 216. Thus, when system call handler 210 receives a system call, system call handler 210 determines which set of services (e.g., Win32K, GDI32, etc.) contains the service that is being invoked by the system call. System call handler 210 then looks up, in descriptor table 212, the address of the head of the service table for that service. Each service may be identified as an offset into the appropriate service table. So, if system call handler 210 determines that the service requested by a particular system call is the Win32K service whose entry has an offset of one (and if service table 216 is the service table for the Win32K services), then system call handler 210 may find the head of service table 216 by looking at entry 234 in descriptor table 212. System call handler may then find the entry 230 that is at offset one into service table 216. This entry points to service routine 222, so service routine 222 would be used to process the system call.
The following is a description of various different ways in which service modification could be implemented. These various different ways are described with reference to
Modification component 254 may contain code that pre-processes or post-processes a system call made by application 206. Descriptions of pre- and post-processing of system calls are described below in connection with
When modification component 254 is used, the path that a system call takes is shown by the dotted line in
The example of
Implementation of the scenario shown in
In
The implementation of
The scenario in
As noted above, a service modifier may pre-process and/or post-process a system call in order to modify the system call's behavior. Example processes of pre-processing and post-processing, respectively, are shown in
In the foregoing description, a system call 712 is formed through a library routine. However, as previously noted, system calls need not be made through a particular set of library routines, and could be made in any manner. Moreover, as previously described, many of the mechanisms described herein for modifying a system call do no rely on the system call's being made through particular library routines.
System call 712 may be provided to service modifier 120.
Service modifier 120 may perform a modification 714 to system call 712, and this modification may take various forms. One example modification is to modify the arguments in argument list 704, which are part of system call 712 (block 716). For example, a system call might request to allocate memory for a process, and might specify, as an argument, the number of bytes to be allocated. Service modifier 120 might impose a QoS limit on the amount of memory that can be allocated to a process, and if the amount of memory requested exceeds this limit, service modifier 120 could change the argument to comply with the limit. Another example of a modification that could be performed is to change service number 708, in order to invoke a different service than the one that the calling application requested (block 718). This technique effectively changes one system call into another system call. Yet another example of a modification is to direct the system call to another machine (block 720). (
Assuming that modification 714 has not resulted in interception of system call 712, a modified system call 724 is generated. Modified system call 724 may comprise a service number 726, an argument list 728, and a size 730 of the argument list. Zero or more of these elements may be modified relative to their values in system call 712.
The modified system call 724 may then be provided to system call handler 210. As described above in connection with
Service modifier 120 may post-process a system call in the sense that it may modify side effect 806 and/or result 804. Thus, service modifier 120 may produce a modified result 808. For example, if a service routine generates a return value, and if service modifier 120 changes the generated return value into a new return value, then the new return value is a modified result 808. Service modifier 120 may also modify side effect 806. For example, if execution of a system call has written some data into a memory location, service modifier 120 may modify this side effect by changing the data in some manner—e.g., by overwriting the data, by adding to the data, etc. In general, if side effect 806 puts a machine, or a component of a machine in a particular state, post-processing may involve changing of that state.
As previously described, a service modifier may be implemented in various ways.
A modification component may be added to the environment in which system calls are processed (block 1006). Modification components 254, 302, 404, 502, and 602 (shown variously in
In order to allow system calls to be routed through a modification component, various other changes may be made to the environment. For example, a system call library may be modified (block 1008).
Modification of system call behavior may be used in various ways.
One way in which modification of system call behavior may be used is to limit the behavior of a given system call to some subset of possible behaviors (block 1102). As described above, there may be a QoS constraint that governs the service that a system call may provide to a program. For example, a memory-allocation system call might allow a process to request arbitrary amounts of memory, but a QoS constraint might specify that a process may receive only 10 Mb of memory. Thus, if the amount of memory requested is an argument to the system call, a modification component might examine and modify the argument specified by an application to ensure that the argument does not result in allocation of more memory than the QoS constraint allows. If an application issues, e.g., a request for 20 Mb of memory by specifying the number of bytes in an argument, the modification component might modify the argument to a lower number in order to cause the system call, when invoked, to comply with a per-process memory-allocation limit. The modification component might also maintain a running total of the amount of memory that has been allocated to a process, in order to enforce this constraint across different instances of the system call (e.g., a request for 2 Mb may be converted to a request for 1 Mb, if prior system calls have already obtained allocation of 9 Mb). Other types of QoS constraints could be implemented—e.g., the amount of data that a process may write per unit of time, the number of new processes that a given process may spawn, etc.
Another example of how a service modifier could modify the behavior of a system call is to cause a system call in one OS to behave like a system call in another OS (block 1104). This example may provide a way for one operating system to execute software built for another operating system. For example, by modifying the behavior of system calls in the MICROSOFT WINDOWS operating system to behave like Linux system calls, it may be possible for an application built for Linux to execute on the MICROSOFT WINDOWS operating system. The same principles can be applied in the opposite direction, allowing MICROSOFT WINDOWS applications to run on a modified Linux kernel.
Another way in which a service modifier could modify the behavior of a system call is to route the system call from one processor to another (block 1106). The scenario shown in block 1106 may occur, for example, when a limited-purpose processor is used. Suppose that processor 1110 is a limited-purposed processor, such as a graphics accelerator. Processor 1110 may have an operating system 1112. Application 1114 may make a system call to operating system 1112. If processor 1110 is a limited-purpose processor, it may have the ability to perform certain functions (e.g., graphics output), but not others (e.g., writing to a file on disk). In operating system 1112's default behavior, a system call that attempts to write to a file might be rejected on the ground that such a system call requests a service that processor 1110 cannot fulfill. However, the behavior of this system call could be modified to route such requests to operating system 1116, which executes on processor 1118. In this example, processor 1118 is a general-purpose processor which controls the typical hardware associated with a computer (e.g., disk drives, etc.). Thus, the system calls on operating system 1112 could have their behavior modified such that, if operating system 1112 receives a request to write to a disk (or to perform some other operation that is normally performed on the general-purpose processor), the system call could be re-routed to operating system 1116 (as indicated by arrow 1120).
Another way in which service modifier could modify the behavior of a system call is to implement support for distributed processing (block 1122). Normally, a system call is handled on the machine to which the system call is made. A machine, however, may be part of a distributed computing arrangement. System call behavior could be modified so that a system call received at one machine could be routed to one or more other machines. For example, block 1122 shows a distributed arrangement with machines 1124, 1126, and 1128. There may be system calls 1130 implemented on machine 1124, and an application 1132 that runs on machine 1124 might issue a system call on that machine. System calls 1130, however, may have been modified to route the system call to machines 1126 or machine 1128. The decision to route the system call to another machine could be based on availability (e.g., the system call could be routed to other machines for load balancing among the machines), or based on division of functionality among machines (e.g., one machine could be designated to handle a particular system call, or a particular category of system calls). Application 1132 might issue the system call on machine 1124 just as if the system call were to be executed on machine 1124. Thus, modification of system calls 1130 allows these system calls to re-route system calls to other machines in a way that does not involve application 1132 in the details of the rerouting. In this way, modification of system call behavior may be used to support a distributed computing arrangement.
Yet another example way in which modification of system call behavior could be used is to extend the functionality of system calls by providing memory layout information (block 1134) or data flow usage information. Normally, a process accesses a machine's physical memory through the abstraction of virtual addresses. The operating system assigns the mapping of virtual-to-physical addresses, and does not share this information with the processes. However, system calls could be augmented to provide this information to processes. Thus, the example of block 1134, kernel 1136 manages a memory 1138. In the course of managing memory 1138, kernel 1136 assigns a particular memory mapping 1140 for use by a particular process. Modification component 1142 may access this memory mapping. Thus, for example, when a process uses system calls to read memory, write memory, allocate new memory, etc., these operations may change mapping 1140. Modification component 1142 may modify the behavior of these system calls so that the system calls will report on the state of mapping 1140, and/or changes to mapping 1140. E.g., if a “read” system call requests to read memory that has been paged to disk, the system call may result in moving one or more virtual pages from disk to memory; a modified system call could report on the physical memory location in which the virtual page is being stored following the “read” system call. In greater generality, kernel 1136 may maintain internal data structures, and may make changes to those internal data structures. Modification component 1142 may learn of changes to the internal data structures, and may modify the behavior of a system call to report these changes to an application (even if the normal behavior of the system call is not to report these changes). The data structures may be “internal” in the sense that they are maintained by the kernel are are not normally accessible outside of the kernel. Mapping 1140 is an example of these internal structures, although kernel 1136 may maintain other internal data structures.
One example of how this information about mapping 1140 could be used is to implement a security application. A security application might be designed to detect and/or prevent the use of malware by tracking the movement of data. Such an application might attempt to enforce a rule that protected data stay in locations that are controlled by trusted applications, and might conclude that a security violation has occurred if protected data moves into a space controlled by an untrusted program. Detecting such movement may involve knowing the physical memory locations in which protected data has been placed. By tracking the physical movement of data, it is possible to determine whether a location that stores protected data has come under control of a non-trusted application. While system calls do not normally report to an application how the kernel has laid out the use of physical memory for the process in which the application executes, system calls (such as those that affect the contents of memory) could be modified to report this information.
Computer 1200 includes one or more processors 1202 and one or more data remembrance components 1204. Processor(s) 1202 are typically microprocessors, such as those found in a personal desktop or laptop computer, a server, a handheld computer, or another kind of computing device. Data remembrance component(s) 1204 are components that are capable of storing data for either the short or long term. Examples of data remembrance component(s) 1204 include hard disks, removable disks (including optical and magnetic disks), volatile and non-volatile random-access memory (RAM), read-only memory (ROM), flash memory, magnetic tape, etc. Data remembrance component(s) are examples of computer-readable storage media. Computer 1200 may comprise, or be associated with, display 1212, which may be a cathode ray tube (CRT) monitor, a liquid crystal display (LCD) monitor, or any other type of monitor.
Software may be stored in the data remembrance component(s) 1204, and may execute on the one or more processor(s) 1202. An example of such software is system call modification software 1206, which may implement some or all of the functionality described above in connection with
The subject matter described herein can be implemented as software that is stored in one or more of the data remembrance component(s) 1204 and that executes on one or more of the processor(s) 1202. As another example, the subject matter can be implemented as software having instructions to cause a computer to perform one or more acts of a method, where the instructions are stored on one or more computer-readable storage media. The instructions to perform the acts could be stored on one medium, or could be spread out across plural media, so that the instructions might appear collectively on the one or more computer-readable storage media, regardless of whether all of the instructions happen to be on the same medium.
In one example environment, computer 1200 may be communicatively connected to one or more other devices through network 1208. Computer 1210, which may be similar in structure to computer 1200, is an example of a device that can be connected to computer 1200, although other types of devices may also be so connected.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.