The process load server receives load requests for objects and retrieves, validates, and loads the object. Some objects may be executable and some may not, but our discussion focuses on the loading of executable objects.
The process load server solves the following problems:
Our effort here is concentrated on a mechanism for loading executable content. We propose mechanisms and policy representations for authentication and permission derivation elsewhere [12, 13]. These mechanism enable permissions to be derived dynamically for downloaded content given limited input from multiple principals.
While IPC can be faster than 230 
s, it is still well understood
that procedure calls are faster. IPC in the Lava Nucleus takes 4
times longer on a Pentium than a procedure call than Wallach et
al. [26] measure for a PC. In addition, there are
indirect costs that are a result of the context switch, such as the
handling TLB and cache misses. While the Lava Nucleus is designed to
enable these costs to be reduced, the fewer context switches the
better.
To reduce these overheads, we want the ability to link supporting content in the requesting process. However, only links that ensure that both the requesting process and the downloaded content do not obtain any unauthorized access rights can be permitted. This is only possible if: (1) neither the downloaded content nor the requesting process gain any permissions as a result of the co-location; (2) the downloaded content is permitted access to the requesting process's data and vice versa; and (3) the downloaded content can run properly with the rights of the requesting process. For the first condition to hold, the permissions of the joint process must be the intersection of the permissions of the content loaded into it. Thus, neither process can use a permission unless both had it previously. Also, neither content may have data in its address space that it must keep secret from the other. In addition, the content and process must also be able to effectively perform their jobs with the resultant rights for the co-location to be feasible.
While these restrictions limit the content that can be loaded into the requesting process, a variety of useful content can still be downloaded and co-located. Trusted libraries can be co-located with the requesting process in many instances. For example, many Java classes in java.lang package (although not the Java ClassLoader whose functionality we are superseding) can be loaded into a requesting process. For example, the String class does not provide the user's process any additional rights (although it may be used to circumvent language-based security), so it can be loaded into the requestor's address space. Also, we think that all the classes in the java.io can be loaded into a requesting process, because restricted access to the file server can be enforced by the monitor. Of the 30,000 domain crossings per second measured by Wallach et al., we expect that many of those do not really require a change in domain for the requesting process. Our experience with the FlexxGuard prototype system (a controlled Java interpreter) was that restricting the permissions of the Java system classes to that of the current applet being run still permitted many useful applications to be implemented [1].