Dynamic linker

Abstract: A dynamic linker links a subprogram into an already complete program while the program is running. The linking is performed by initially creating a procedure in the subprogram with a name that matches a present procedure name within the program. The dynamic linker then compares the names to find the present procedure and replaces it with the subprogram procedure. The subprogram may contain one or more procedures that include additional functions. Procedure replacement techniques are described for RAM-and ROW-based systems. Unlike conventional linkers, the linking occurs while the program continues to run, preserving the program's data and state while changing or augmenting its functions.

Abstract: The authors describe an algorithm and implementation of dynamic linking that allows one user process to link a program in another address space without compromising the security of the other address space and without requiring the linking process to enter kernel mode. The same technique can also be used to load program code into an existing address space, e.g., for debugging or other purposes. The implementation makes extensive use of objects in the Spring object-oriented operating system. They have extracted the dynamic linking function from the operating system, and made it available to user programs as a replaceable library service. In the process, they have taken advantage of features present in a modern, object-oriented operating system to simplify the dynamic linker. >

Abstract: Program counter is the only mechanism for processor to access instruction to execute. Protecting program counter is the fundamental defense for securing computer system. This paper presents a scheme of protecting program counter by encoding function pointers. In the scheme, every function address is encoded by linker. Compiler inserts instructions for decoding function addresses before call instruction. Encoding code pointers, function addresses as well as return addresses in stack frame, provides substantial coverage of protecting program counter. Several suggestions are also made to detect compromised code pointers at run-time without memory space for sensor mechanism. A demo Linux system has been under construction with the proposed scheme. Experimental data shows performance slowdown less than 10% when all return addresses and function addresses are encoded. With a Pentium III processor of 866MHz, the overhead for each function call is on the order of nanoseconds. We plan to migrate parts of our code pointer encoding scheme from linker to dynamic linker, which should improve security and performance.

Abstract: The protection of operating system code from user code in most systems is based on the separation provided by an architecturally enforced user/kernel boundary. The boundary isolates an application from the kernel and from other applications. Only through the system call interface can applications interact with kernel services or one another. The system call interface has worked well in the past because the number of services and service interfaces o ered by the operating system has been relatively small and static, and the frequency of service interaction has been low. Consequently, trust relationships could be accurately and e ciently expressed through the user/kernel boundary. Operating system requirements are changing, though, and thereby changing the structure of systems. Systems are now being used to support a variety of applications, such as multimedia [Rad93], multiprocessing [WW94], and distributed memory management [FMP95] that were once considered \fringe" services. In response to these changing demands, systems are now being designed to support application-speci c extensions that change the behavior, and commonly the interfaces, of the operating system. In this paper, we describe the dynamic linking mechanisms used to de ne and access service interfaces in the SPIN operating system. SPIN is an extensible system that provides extensive support for executing safe code in the kernel's address space. Code is safe if it cannot violate the interfaces against which it has been compiled without causing a checked runtime error. Safety requires that interfaces can not be circumvented using unsafe memory operations such as pointer casting. For example, a program using unsafe memory operations could force a call to a system-private function (such as HALT) by forging a pointer to a function through a cast operation. Clearly, such casts must be disallowed if dynamically linked code is to execute safely. Several projects, including our own [BSP95], are now exploring the use of kernel extension technologies which preclude unsafe pointer operations [WLAG93, Luc95, VGA94, EKJ95]. With SPIN, applications de ne system extensions using the well-de ned safe subset of Modula-3 [Nel91]. Once an infrastructure for the safe execution of code is in place, though, it is necessary to consider the machinery for naming and linking that safe code into a running system. In this paper we describe a dynamic linker that provides for the safe presentation and occlusion of interface implementations for safe code executing within the kernel. Our linker de nes the environment in which safe code executes, enabling code to name, combine, communicate, and authorize interfaces and collections of interfaces safely within the kernel. The key attributes of our linker are: