Electrical computers and digital data processing systems: input/ – Interrupt processing – Multimode interrupt processing
Reexamination Certificate
2000-09-18
2004-05-04
Myers, Paul R. (Department: 2112)
Electrical computers and digital data processing systems: input/
Interrupt processing
Multimode interrupt processing
C707S793000
Reexamination Certificate
active
06732211
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to computer operating systems, and more particularly, to techniques for intercepting I/O multiplexing operations involving cross-domain file descriptor sets.
2. Description of the Background Art
Operating systems such as UNIX® and Microsoft WINDOWS NT® are widely used in commercial computing systems. Among their many uses, these operating systems are commonly deployed on Internet and other network server computers. With the popularity and success of the Internet, operating systems for network servers are currently of great commercial importance.
Frequently, intercepting system calls that pertain to accessing files is desirable. Although operating systems include various internal resources for accessing a file system, it is often desirable to customize or extend operating system functionality for a particular use. Such customization allows a computer programmer, a network administrator, or a webmaster to utilize the operating system in a specific manner beyond the default system capabilities provided by the manufacturer of the operating system. The interception of system calls is one such method of extending and expanding operating system functionality.
A system call is a subroutine, the object code of which is located in the operating system. Such subroutines are normally called by processes (applications) executing under the control of the operating system. When executed, a system call performs some system operation, such as accessing a system hardware device or a software resource. Examples of operations executed by system calls may include reading data from a file, opening a network communication channel, and allocating computer memory to a specific process.
A system call vector table typically stores pointers to the executable code of the system calls. In order to make a system call, arguments are programmatically loaded into specific registers of the central processing unit (CPU) of the computer on which the operating system is executing. One of these arguments identifies the specific system call that is being made. This argument is typically in the form of a number that is an offset into the system call vector table. The other loaded arguments include parameters to be passed to the system call.
Once the arguments have been loaded, a software interrupt is normally generated, signaling to the operating system that a process is requesting execution of a system call. The operating system reads the registers, and executes the requested system call with the specified parameters. The system call executes and performs the desired functionality. If the system call generates a return value, it places the generated return value (or a pointer thereto) in a pre-designated register where it can be accessed by the calling process.
In order to intercept a system call, a pointer in the system call vector table to the system call is replaced with a pointer to alternative object code to be executed instead of the system call. As a result, when the operating system reads the system call vector table in response to the system call being requested, the operating system will read the pointer to the alternative object code, and the alternative object code will execute instead of the system call. The alternative object code is typically known as a “system call wrapper.”
The interception of system calls providing access to the file system is useful in extending and customizing operating system functionality. For example, the interception of system calls may be used to manipulate operating system access privileges to provide security beyond that which is provided by the operating system. By intercepting system calls that provide access to the file system, processes can be prevented from deleting, modifying, creating, or even reading files. This is desirable, for example, when a user wishes to remotely execute a program residing on a web server, but does not want the remote program to be able to read or alter private data on the user's computer. Today, Java® applets are commonly employed to provide such security. However, many programs that users wish to remotely execute are written in languages other than Java®. System call interception has the potential to allow the safe execution of programs written in all languages.
The interception of system calls is known today, although it is an advanced programming technique. Nonetheless, a serious shortcoming limits the usefulness of intercepting system calls that provide access to the file system. That shortcoming is the inability to disambiguate between a file descriptor that is associated with a file stored on media (e.g., hard disk, optical disk, random access memory) and a file descriptor that is associated with a communication channel (e.g., referred to as a “socket” in UNIX®).
Many computer operating systems utilize file descriptors to provide access to file systems. Under such operating systems, a file is created by making a system call that creates a file and returns a file descriptor that is associated with the newly created file. Subsequently, the file is accessed via the file descriptor. Examples of file access operations include reading from a file, writing to a file, closing a file, and deleting a file. Such operations are typically conducted by making a designated system call, and passing the system call the file descriptor that is associated with the file being accessed.
Many commercially popular operating systems such as UNIX® and Microsoft WINDOWS NT® treat communication channels as files. In such an operating system, when a process makes a system call in order to establish a communication channel, the operating system returns a file descriptor. The communication channel is subsequently accessed via the file descriptor, in a similar manner as a file stored on media.
Commonly, the same system calls are made to perform the same access operations on both files stored on media and on communication channels. For example, under the UNIX® operating system, a read system call can be made in order to read data from either a file stored on media or from a communication channel. The system call itself has no information concerning the file type with which a file descriptor is associated. The system call simply executes instructions to access a file in a specific manner via a file descriptor. For example, the read system call executes instructions to copy a specific number of bytes from a file to a buffer in memory. The read system call does not distinguish between a file on media and a communication channel.
Likewise, a system call wrapper that executes when such a system call is intercepted conventionally has no mechanism for distinguishing between file types. For example, if the read system call is intercepted, the system call wrapper will execute whenever any process makes the system call to read data from any type of file. Thus, the system call wrapper will execute whenever a process attempts to read data from a file stored on media and also whenever a process attempts to read data from a communication channel.
Communication channels and files stored on media are inherently different, despite the fact that both are accessed via file descriptors. Thus, it is often desirable to intercept system calls that access a file stored on media, but not to intercept system calls that access a communication channel. Likewise, it is often desirable to intercept system calls that access a communication channel, but not to intercept system calls that access a file stored on media.
For example, as noted above, it is sometimes desirable only to intercept system calls that access files stored on media. The desired result is to prevent access to files stored on media, but not to prevent access to communication channels. At the same time, it may be undesirable to prevent write access to the communication channels of the client computer, because it would be desirable for the computer to be able to receive communication responses from web servers. However, intercepting
Goyal Pawan
Gylfason Snorri
Huang Xun Wilson
Keshav Srinivasan
Sharma Rosen
Ensim Corporation
Fenwick & West LLP
Myers Paul R.
LandOfFree
Intercepting I/O multiplexing operations involving... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Intercepting I/O multiplexing operations involving..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Intercepting I/O multiplexing operations involving... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3259097