Synchronous IPC over transparent monitors

Interprocess (IPC) monitoring enables the examination of any IPC between a source and a destination. IPC monitoring is useful for a variety of purposes, including debugging, logging, and security. For example, a monitor may collect communication state for the purpose of debugging a program consisting of several independent tasks. Also, a monitor can be used to filter communication data or control the communication rate for security purposes. Transparent monitoring means that the source and destination are not aware that they are being monitored. This has two advantages: (1) the system can control the insertion and removal of monitors without interacting with either the source or destination and (2) the source and destination protocols do not need to take into account the possibility that they may be monitored. Traditional systems make no attempt to support transparent monitoring. Using Mach-style ports [1], the source and destination hold rights that must be revoked in order to insert a monitor, so at least one must be notified before such a change can occur safely. The Pebble microkernel enables transparent redirection of source IPCs using its portals to implement customized IPC, but the redirection is not transparent to the destination because it sees that the message is from the redirected task, not the original source [3].Other IPC mechanisms, such as Clans & Chiefs [6] and IPC Redirection [2], enable monitors to intercept and forward IPCs while claiming to be the original source of the IPC. Thus, the destination receives the IPC from the source, not the monitor, so it need not know that an IPC is being monitored. Unfortunately, such mechanisms are not truly transparent because the kernel's IPC semantics are not preserved when a monitor intercepts an IPC. Modern microkernels implement a synchronous IPC semantics, which means that the source is blocked until the destination is ready to receive the IPC or an error occurs (e.g., the destination task is killed or a timeout expires). When destination commences receipt, the IPC is sent to the destination and the source unblocks. Unfortunately, if a monitor is inserted on an IPC path, the source is unblocked when the IPC is received by the monitor, not the destination. This may result in some anomalous behaviors, such as: (1) the source assuming that IPCs have been delivered to the destination before they really have; (2) the source terminating IPCs due to timeout expiration even though the destination is ready, but because the monitor was not ready; and (3) the source assuming that the IPC was delivered reliably to the destination when an error may have occurred.In this paper, we propose an IPC mechanism that restores synchronous IPC semantics over transparent monitors. The key feature of this mechanism is that system monitors are considered as an extension of the kernel, so the source and destination are treated as if the kernel is still processing the IPC. However, there are a number of possible monitoring extensions that must be considered, and these introduce a number of problems that must be solved simultaneously. Our design enables layering of these additional semantics upon system monitors as necessary.The remainder of the paper is as follows. In Section 2, we define the basic synchronous IPC semantics that must be achieved and refine these semantics for relevant extensions. In Section 3, we construct a synchronous IPC protocol that solves these problems by incrementally extending a basic IPC mechanism. In Section 4, we demonstrate the use of the synchronous IPC mechanism on an example which both redirects and controls the rate of IPCs securely. In Section 5, we examine efficient implementations of the synchronous IPC mechanism upon the L4 microkernel using the IPC redirection mechanism. In Section 6, we conclude the paper.