Process Loading (2024)

The process load server receives load requests for objects andretrieves, validates, and loads the object. Some objects may beexecutable and some may not, but our discussion focuses on the loadingof executable objects.

The process load server solves the following problems:

• retrieve requested executable content,
• uses the authentication server to verify the authenticity of content and derive the content principal,
• uses the derivation server to derive the content's permissions,
• find the process in which to load the content,
• load the content into that process

Our effort here is concentrated on a mechanism for loading executablecontent. We propose mechanisms and policy representations forauthentication and permission derivationelsewhere[12, 13]. These mechanism enablepermissions to be derived dynamically for downloaded content givenlimited input from multiple principals.

While IPC can be faster than 230 s, it is still well understoodthat procedure calls are faster. IPC in the Lava Nucleus takes 4times longer on a Pentium than a procedure call than Wallach etal.[26] measure for a PC. In addition, there areindirect costs that are a result of the context switch, such as thehandling TLB and cache misses. While the Lava Nucleus is designed toenable these costs to be reduced, the fewer context switches thebetter.

To reduce these overheads, we want the ability to link supportingcontent in the requesting process. However, only links that ensurethat both the requesting process and the downloaded content do notobtain any unauthorized access rights can be permitted. This is onlypossible if: (1) neither the downloaded content nor the requestingprocess gain any permissions as a result of the co-location; (2) thedownloaded content is permitted access to the requesting process'sdata and vice versa; and (3) the downloaded content can run properlywith the rights of the requesting process. For the first condition tohold, the permissions of the joint process must be the intersection ofthe permissions of the content loaded into it. Thus, neither processcan use a permission unless both had it previously. Also, neithercontent may have data in its address space that it must keep secretfrom the other. In addition, the content and process must also beable to effectively perform their jobs with the resultant rights forthe co-location to be feasible.

While these restrictions limit the content that can be loaded into therequesting process, a variety of useful content can still bedownloaded and co-located. Trusted libraries can be co-located withthe requesting process in many instances. For example, many Javaclasses in java.lang package (although not the Java ClassLoader whosefunctionality we are superseding) can be loaded into a requestingprocess. For example, the String class does not provide the user'sprocess any additional rights (although it may be used to circumventlanguage-based security), so it can be loaded into the requestor'saddress space. Also, we think that all the classes in the java.io canbe loaded into a requesting process, because restricted access to thefile server can be enforced by the monitor. Of the 30,000 domaincrossings per second measured by Wallach et al., we expect thatmany of those do not really require a change in domain for therequesting process. Our experience with the FlexxGuard prototypesystem (a controlled Java interpreter) was that restricting thepermissions of the Java system classes to that of the current appletbeing run still permitted many useful applications to beimplemented[1].