Flexible interprocess communication via redirection

Details Flexible interprocess communication via redirection Flexible interprocess communication via redirection

1999-03-26

2004-06-08

Follansbee, John (Department: 2126)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C709S241000

Reexamination Certificate

active

06748452

ABSTRACT:

FIELD OF INVENTION
The present invention is related to Interprocess Communications. In particular, the present invention is related to a mechanism that enables a redirection controller to specify the destination of any interprocess communication (IPC). Even more particularly, the present invention is related to a mechanism that enables a redirection controller to to specify the destination of any interprocess communication (IPC)such that an IPC either: (1) is sent to the requested destination; (2) is redirected to an alternative destination; (3) is blocked from being sent; or (4) incurs a redirection fault which is handled by the redirection controller.
Glossary
Interprocess
Transfer of a message from a source
Communication
identifier (for one or more sender
processes), to a destination identifier
(for one or more receiver processes).
IPC process
Implementor of the interprocess
communication mechanism.
Redirection
The transfer of an interprocess
communication to a destination other than
that specified by the source.
Redirection Data
A mapping between the interprocess
communication paths (i.e., pairs of
sources and destinations) and the entries
that specify the actual destinations for
the IPC process to use for those paths
Redirection Controller
A process assigned to manage the
redirection data entries for a set of
interprocess communication paths
Redirection Fault
The result when a requested interprocess
communication path contains no destination
entry in the redirection data.
BACKGROUND
The conflict between Interprocess Communication (“IPC”) performance and security-policy enforcement is fundamental to the development of micro-kernel systems. In such systems, many system services may be implemented at user-level, so many processes may need to communicate to complete a task. In early micro-kernel systems, such as Mach, the kernel only authorizes whether a process can send or receive an IPC from another process (see K. Loepere,
Mach
3
Kernel Principles
, Open Software Foundation and Carnegie Mellon University, 1992). Actual authorization of the operations on server objects is performed by the servers themselves. While the server must be trusted to control access to its own objects, it may not be designed to either interpret or enforce the system's global security policy. In these cases, an additional trusted process, often called a reference monitor, is assigned the task of enforcing the system's access control policy properly.
Security researchers have extended such systems to enable the enforcement of security policy, such as the Distributed Trusted operating System (DTOS) (see S. Minear,
Providing Policy Control Over Object Operations in a Mach
-
based System
, in Proceedings of the Fifth USENIX Security Symposium, 1995), but Mach's IPC mechanism limits flexibility which, in turn, limits the potential optimizations. Mach ports enable a principal with receive rights to that port to receive IPCs from those principals with send rights to the port. In order to interpose a task to intercept IPCs, the current receiver must delegate its port receive right to another principal. This means that interposition requires the cooperation of the receiver which is a problem if either: (1) the receiver is incapable of the cooperation; or (2) the receiver resists the interposition. Thus, the DTOS implementation which uses Mach's IPC mechanism depends on the server processes (or the kernel for kernel resources, such as ports) to call security servers to authorize operations using the system security policy (a round-trip IPC). Since the servers cannot tell when security policy has changed, they must continue to request authorizations using this mechanism. Even though the designers of DTOS smartly cache capabilities in the kernel to improve performance (to a single system call, about one IPC), in general, these IPCs would not be necessary if the IPCs could be redirected to reference monitors on demand (e.g., only when the security policy changes).
In more recent micro-kernel systems, Liedtke pushed authorization completely out of the kernel to optimize IPC performance (see J. Liedtke et al,
Achieved IPC Performance
, in Proceedings of HotOS VI, 1997). In the L4 system, the kernel does not authorize communication, but provides unforgeable IPC source identification and permits any IPC to be redirected to another process instead. L4 uses a model called “Clans & Chiefs” to define these redirections (see J. Liedtke,
Clans & Chiefs
, in Achitektur von Rechensystemen, 1992, in English). In this model, a chief is a special process in a clan (i.e., set of processes). Assignments of clan members to chiefs is static in L4. Any IPC between two processes in the same clan is forwarded directly to the destination by the kernel. However, any IPC either to a process outside the clan or from a process outside the clan is automatically redirected by the kernel to the clan's chief. To monitor individual processes, we found it necessary to assign each to their own clan, so three IPCs (client-chief, chief-chief, chief-server) are required for an inter-process request. While we showed that the base cost could be as low as 4 microseconds and that we measured 9 microseconds (see T. Jaeger,
Operating System Protection for Fine
-
grained Programs
, in Proceedings of the Seventh USENIX Security Symposium, 1998), in many cases, the chief-chief IPC is unnecessary (see J. Tidswell and J. Potter,
Domain and Type Enforcement in a Micro
-
kernel
, in Proceedings of the 20th Australasian Computer Science Conference, 1997).
Another concept that is being developed is called a portal (see E. Gabber et al,
Building Efficient Operating Systems from User
-
level Components in Pebble
, in Proceedings of the 1999 USENIX Annual Technical Conference, 1999). A portal is a reference to a customizable IPC mechanism. Portals are defined by a privileged task and invoked by the kernel on an IPC request. The proposed implementation of portals uses a portal table in the nucleus to vector references to the portal code which the nucleus then executes (i.e., all portal code is trusted). Portals enable trusted customizations to be defined outside the nucleus and run inside the nucleus. However, since these customizations must be trusted we must trust the compiler which increases our system TCB, and untrusted processes cannot set redirection entries (even for other untrusted processes). This limits the flexibility of the IPC redirection. The present invention addresses this need.
SUMMARY
In accordance with the aforementioned needs, the present invention is a method, system and computer program product that defines an interprocess communication (IPC) mechanism enabling redirection controllers to redirect communications to selected destinations.
A method for performing interprocess communication (IPC) redirection, having features of the present invention comprises the steps of: receiving an IPC from an IPC process, the IPC including a source identifier and a destination identifier; and modifying a redirection entry specifying an actual destination for the IPC associated with the source identifier and the destination identifier; wherein the IPC process can restrict a set of redirection entries that can be modified.
In a preferred embodiment, the IPC redirection mechanism uses the source and destination identifiers of the communication and the system's redirection data to find the current redirection entry for that communication. If the redirection entry is null, a redirection fault is taken. The IPC redirection mechanism determines the redirection controller assigned for this source and destination and requests that the redirection controller handle the fault. The redirection controller may then specify a redirection entry for this combination of source and destination as well as others. The redirection entry values may range from: ‘blocked,’ which rejects the IPC request; to the specified destination; to an alternative destination.
Therefore, trusted user-level processes may specify the redirections for processes t

Affiliated with

Also associated with

Rating

Flexible interprocess communication via redirection does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Flexible interprocess communication via redirection, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Flexible interprocess communication via redirection will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3365756