5.16.2 Library linking mechanism
On SLES, a binary executable automatically causes the program loader /lib/ld-linux.so.2 to be
loaded and run. This loader takes care of analyzing the library names in the executable file, locating the
library in the system directory tree, and making requested code available to the executing process. The loader
does not copy the library object code, but instead performs a memory mapping of the appropriate object code
into the address space of the executing process. This mapping allows the page frames containing the object
code of the library to be shared among all processes that invoke that library function.
Page frames included in private regions can be shared among several processes with the Copy On Write
mechanism. That is, the page frames can be shared as long as they are not modified. The page frames
containing the library object code are mapped in the text segment of the linear address space of the program.
Because the text segment is read-only, it is possible to share executable code from the library among all
currently executing processes.
The kernel carries out this mapping of page frames in a read-only text segment, without any input from the
user. Object code is shared in read-only mode, preventing one process from making an unauthorized
modification to another process’s execution context, thus satisfying the DAC requirement. Page frames used
for this mapping are allocated with the demand paging technique, described in Section 5.5.2.5.6, which
satisfies the object reuse requirement.
On SLES systems, the administrator can control the list of directories that are automatically searched during
program startup. The directories searched are listed in the /etc/ld.so.conf file. A normal user is not
allowed write access to the /etc/ld.so.conf file. The loader also allows certain functions to be
overridden from shared libraries with environment variables LD_PRELOAD and LD_LIBRARY_PATH.
The LD_PRELOAD variable lists object files with functions that override the standard set. The
LD_LIBRARY_PATH variable sets up lists of directories that are searched before loading from the standard
directory list. In order to prevent a normal user from violating the security policy, these variables are ignored,
and removed from the process’s environment when the program being executed is either setuid or setgid.
The system determines if a program is setuid or setgid by checking the program's credentials; if the UID and
EUID differ, or the GID and the EGID differ, then the system presumes the program is setuid or setgid, or
descended from one, and does not allow preloading of user-supplied functions to override ones from the
standard libraries. Similarly if the program execution results in domain transition then the system checks to
see if the resulting domain possesses the type enforcement permission noatsecure. If noatsecure is not present
then the system clears LD_PRELOAD and LD_LIBRARY_PATH variables and thus does not allow preloading
of user-supplied functions to override ones from the standard libraries.
When an executable is created by linking with a static library, the object code from the library is copied into
the executable. Because there is no sharing of page frames with other executing processes, there are no DAC
or object reuse issues with static libraries.
5.16.3 System call linking mechanism
A system call is an explicit request to the kernel made via a software interrupt. The implementation of this
interrupt is dependent on the hardware architecture. The following subsections briefly describe the system
call interrupt setup for the different hardware architectures that are part of the TOE.

5.16.3.1 System x

On System x systems, the Interrupt Descriptor Table (IDT) for the Intel processors is initialized to allow a
trap gate that can be accessed by a user-mode process. The trap_init() routine does this mapping at
215