Protected Shared Libraries: A New Approach to ... - Semantic Scholar

Protected Shared Libraries: A New Approach to Application-Extensible Operating Systems Arindam Banerji and David L. Cohn Distributed Computing Research Laboratory Department of Computer Science and Engineering University of Notre Dame Notre Dame, Indiana, USA axb,[email protected]

Abstract Protected shared libraries are a new mechanism for building fast applicationextensible user-level operating system services. They extend notions previously found in dynamically linked shared libraries and thread migration to provide a new structuring model for operating system services. Early prototypes indicate that the performance of protected shared library services will be good, and that services can be made flexible with minimum overhead.

1. Introduction Modern operating system structures are evaluated on their performance, modularity and flexibility. Monolithic systems have generally provided the best performance whereas microkernel-based systems are modular [1] and, hence, more easily maintained. With the use of thread migration [10] [8], modular systems can achieve performance close to that of monolithic systems. However, neither monolithic nor microkernel-based structures, in themselves, seem particularly well suited to application-specific extensibility. This paper proposes a new structure that retains the isolation of modular systems and the performance of thread migration but that offers the discipline and scope control necessary for application-specific extensibility.

Client

Base I/F

System software designers are increasingly focusing on building flexible operating systems [9], [19], [20]. In fact, the whole concept of hidden, fixed implementations is being questioned [11]. It has been noted that fixed implementations can create untenable mismatches (also called matching dilemmas [12]) between client needs and system realities. However, if the implementations were adjustable, they could be made to provide a better match and substantially improve performance and behavior. It has been proposed that the traditional blackbox service model be replaced. In addition to exporting its base interface that gives access to the service functionality, a server should also export a meta interface. The meta interface would allow a client to alter the service implementation to better match its needs. Such a dual interface implementation can be pictured as shown in Figure 1. Service Meta I/F

Figure 1 Flexible Service Implementation

Submitted to the Fifth Workshop on Hot Topics in Operating Systems


When flexible service implementation allows client modifications, it is essential to limit the scope of the modifications. Generally, other applications should not be effected by them and should continue to be served by a default implementation. Also, some structural limitations must be imposed to insure that the alternative implementation does not violate system integrity. Ideally, a mechanism can be found that permits scope control and discipline without losing the benefits of modularity. We propose protected shared libraries (PSL) as an effective approach to application-specific extensibility. They extend the notion of dynamically loadable shared libraries to associate protection domains with threads and with the code those threads are executing. With protected shared libraries, user-level system services are implemented as shareable libraries with protected entry points and globally-shared protected state data (called service-data). When a user-level clientthread enters a PSL service, it acquires appropriate privileges and address space visibility; when it exits, these are reset. The service also has client-specific memory which is accessible only by threads from that client and can be used to store meta data for that client. The fact that PSLs make protection and visibility dynamic and thread-specific plays a key role in their use for flexible system software. It is our position that protected shared libraries are the proper way to build applicationextensible operating systems. They offer the modularity and performance of migrating threads, but add the crucial scope control and discipline needed for flexible system software.

2. Shared Libraries Dynamically loadable shared libraries are a widely used system software tool. By delaying applications-to-library binding until load-time, they defer certain implementation decisions. For example, OS/2 [14] uses dynamic linked libraries for display device drivers, allowing new displays to be developed and used with old applications. In their simplest form, shared library routines are just code; they own no state. Some implementations permit such routines to retain state information. For example, UNIX allows libraries to define instance data that is separately instantiated in the address space of each process that links to the library. (We shall refer to such data, which has distinct values but common purposes across multiple processes, as common data, and the region where it is stored as common memory.) Shared libraries in OS/2 can also define shared data that is accessible to all tasks which link to the library. Such data can be used for the state of a shared library service, but it is not protected from other library services. The use of shared libraries for system services can be viewed as a descendent of the technology used in Apollo’s Domain system [18]. The addition of enforceable protection (which was not available in Domain) substantially improves the value of the tool. For example, the protection allows shared data regions to hold sensitive information. Thus, protected shared liberties can be used to build services such as communication protocol stacks. Also, PSLs can provide the same level of system service isolation that has made microkernel architectures popular. Finally, and perhaps most importantly, client-specific common data can be used to store the meta data used to tailor a service implementation to the needs of each client.

3. Design Issues With protected shared libraries, just as for 64-bit addresses [7], the concept of protection domain is separeated from that of address space. Here, however, memory access rights are asso-

-2-


ciated with a thread and with the code that that thread is currently executing. Each thread originates in a client task and normally sees memory available in the client protection domain. This is shown on the left-hand side of Figure 2. When it needs a service contained in a protected shared library, the thread enters that code by way of a kernel-level service gate. This gate resembles the call gates defined in the Intel 80x86 architecture in that it guarantees proper invocation of PSL services. It adjusts the protection domain and permits entry to services only at predefined legal entry points. The resulting picture is shown on the right-hand side of Figure 2.

Call

Client Code

Client Code

Client Data

Client Data

Common Data

Common Data

Service Data

Service Data

Entry Stub

Entry Stub

Service Code

Service Code

Exit Stub

Exit Stub Protection Boundary

Service Gate

Return

Service Gate Service Protection Domain

Client Protection Domain

Figure 2 Protection Domains The three data areas each serve important functions. The uses of first two are straightforward. Client Data stores normal application data and is only available to the Client Code. Service Data contains service state information that is seen by all threads which invoke the service. The use of Common Data is more complex. Common Data is in the common memory region and is accessible in both the client protection domain and the service protection domain. Common memory is client-specific, with a separate region defined for each service client. Only threads originating in a given client can access that client’s common memory. Common memory areas can have a number of uses: • Common data - read/write accessible in both domains. Useful for sending arguments to the service and/or returning data to the client. Optionally, the area can be virtually copied to the service domain, providing LRPC [5] semantics. • Thread service stack - thread-specific and inaccessible in client protection domain. Can store stack while thread is active in service code. • Parametric extensibility - writable only in service protection domain. Allows the client to specify application-specific service parameters. Parameters are first sent to the service which verifies that they do not violate acceptable bounds and the writes them to common

-3-


memory. Since the parameters are seen only by threads from one client, scope control is automatic. • Functional extensibility - writable only in service domain. The service could vector function calls through a function table in a common memory area. Individual clients could select between existing implementations or could request dynamic loading of new implementations. The service retains the right to “approve” an implementation since only the service can write to the table. This method can lead to dynamic, scope controlled virtual functions tables [17] and is based on the C++ object sharing technology developed in [3].

Protected shared libraries raise the same thread control issues as thread migration and LRPC [5] (Indeed, PSLs can be viewed as an enhancement to migrating threads with a slightly different view and implementation.) The problem is that a thread running in a PSL service library cannot be controlled in the same way as the same thread when it is running normal client code. It cannot be arbitrarily terminated just because the client task has a problem, and it must be terminable when the service gets into trouble. Unfortunately, thread control mechanisms are system-specific, and it is hard to give a generic solution. However, we consider the threads executing in the service as comprising a pseudo-process, where they are grouped only for the purpose of control. This kernel-level abstraction seems similar to shuttles in Spring [9].

4. Performance Adding protection reduces the responsiveness of shared libraries. However, early experiments have shown that the overhead for invoking a protected shared library routine is substantially less than that of all other widely used cross-domain cooperation. It is slower than a simple kernel trap, and appears comparable to thread migration. Table 1 shows the round-trip times for several implementations of a null service in AIX 3.2.5 running on a relatively slow RS/6000 Model 530. The first two numbers are for classic user-level IPC, and the third shows the value of hand-off scheduling [6]. Thread migration is a bit slower than a PSL call because it has added overhead of locating an appropriate stack. With PSL, the stack can be located in a thread-specific common memory area.

Table 1: Null-Service Performance Times Implementation

Round-Trip Time

User-Level Server Task - UDP-based

2000 µsec

User-level Server Task - System V IPC

900 µsec

User-Level Task - Hand-off Scheduling

190 µsec

User-Level Task - Thread Migration

40 µsec

Protected Shared Library - Service Gate

34 µsec

Kernel-Level - Trap

22 µsec

Note that both thread migration and PSL involve two entries into the kernel, but they do not take twice as long as a single kernel-level trap. This is because an implementation trick in AIX 3.2.5 and the POWER architecture [2], [13] allows a faster trap when very little is to be done in the kernel.

-4-


5. Conclusion The function of protected shared libraries is quite similar to that of thread migration. Both are efficient methods to move threads between protection domains and both raise important thread control issues. Libraries map better to objects than do processes, so they should make it easier to build high-level frameworks for system service implementations [16], [15], [4]. Also, PSLs have the ability to make memory access thread-specific. This makes them ideally suited to implement application-extensible operating system services. Designers of such systems must address three major issues: • Scope - Which clients are effected by a change? • Safety - Is an altered server guaranteed to provide proper service? • Performance - What is the overhead of adding flexibility? Protected shared libraries can provide the right answer for each of these questions.

6. References [1] Acetta M. et al., Mach: A new kernel Foundation for Kernel Development, Proc. Summer 86 USENIX Conference, Atlanta, GA, June 9-13, 1986, pp. 93-112. [2] Assembler Language Reference Manual for AIX Version 3, IBM Corp., 1990. [3] Banerji A. & D. Cohn, Shared Objects and Vtbl Placement in C++, Journal of C Language and Translation, September 1994. [4] Banerji A., D. Kulkarni, J. Tracey & D. Cohn, The Substrate Object Model and Architecture, Proc. 3rd Intl. Workshop on Object-Orientation in Operating Systems, IEEE, pp. 31-41, 1993. [5] Bershad B., Lightweight Remote Procedure Call, ACM Transactions on Computer Systems, *(1), February, 1990. [6] Black D., Scheduling support for Concurrency and Parallelism in the Mach Operating System, Unpublished. [7] Chase J. et. al, How to use a 64-bit virtual address Space, Technical Report 93-03-02, Department of Computer Science and Engineering, University of Washington, March, 1992. [8] Ford B., Lepreau J., Evolving Mach 3.0 to a migrating Thread Model, Technical Report, Department of Computer Science, University of Utah, 1993. [9] Hamilton G., M. Powell, J. Mitchell, Subcontract: A Flexible Base for Distributed Programming, Proc. 14th ACM Symp. on Operating Systems Principles, Operating Systems Review, 27[5], Dec 93, pp. 69-79. [10] Hamilton G., P. Kougiouris, The Spring Nucleus: a micro-kernel for objects, Proc. Summer 93 USENIX conference, Cincinnati, OH, pp. 147-159, 1993. [11] Kiczales G. et al, Report on the Open Implementation Workshop, October, 1994, to appear. [12] Kiczales G.& J. Lamping, Operating Systems: Why Object-Oriented?, Proc. 3rd Intl. Workshop on ObjectOrientation in Operating Systems, IEEE, pp. 25-30, 1993. [13] Hardware Technical Reference for the RISC/6000, IBM, 1990. [14] IBM Cset++ Toolkit: Online Documentation on Dynamic Linking, 1992. [15] Russo V., An Object-Oriented Operating System, Ph.D. Dissertation, Dept. of Computer Science, Univ. of Illinois at Urbana Champaign, Urbana, IL, 1990. [16] Schmidt D., The ADAPTIVE Communication Environment, Proc. 11th Sun User Group Conf., San Jose, CA, 1993. [17] Stousroup B., The C++ Programming Language, Addison-Wesley, 1990 [18] Waldo J., Personal Communications, 1994. [19] Yokote Y.et. al., The Muse Object Architecture: A New Operating System Structuring Concept, Operating Systems Review, 25(2), ACM, pp. 22-45, 1991. [20] Yokote Y, The Apertos Reflective Operating System: The Concept and its Implementation, Proc. OOPSLA `92, ACM, pp. 414-434, 1992.

-5-


-6-