pwn.college - Program Interaction - Linux Process Loading

Linux Process Loading

The lecture explains how a Linux program becomes a running process, using a small cat-like program and command-line demonstrations to illustrate the stages.

1. What a Process Contains

A process is a running instance of a program. The kernel tracks information such as its state and scheduling priority, parent and child relationships, resources, security context, and memory space. Processes generally have separate virtual memory spaces, so they cannot directly access one another’s memory.

2. Creating a Process and Running a Program

Linux commonly starts a new process by copying an existing one with a process-creation system call such as fork or clone. For example, a shell can create a child process to run a command. The child then calls execve to replace its program with the requested one.

execve replaces the program in the existing process; it does not create another process.

Before loading a program, the kernel checks whether it can be executed. Missing execute permissions, files, or dependencies can cause execution to fail.

3. How Linux Recognizes Executable Files

The kernel examines a file’s contents to determine how to run it; the filename extension is not decisive.

• Shebang scripts: A file beginning with #! specifies an interpreter. The kernel runs that interpreter and passes the script’s filename as an argument. Interpreter handling can be recursive if the interpreter is itself another script.
• binfmt_misc: This kernel facility lets the system recognize other formats by their contents and route them to a configured interpreter. The lecture demonstrates formats such as Java archives and binaries for other architectures.
• ELF executables: ELF is the usual Linux executable format. A statically linked ELF contains its needed libraries within the executable. A dynamically linked ELF specifies a dynamic loader, which the kernel starts to load the program’s shared-library dependencies.

An unavailable ELF interpreter or missing shared library can make execution fail even when the executable itself exists. The lecture uses ldd to inspect dependencies.

4. Dynamic Libraries and Loading Controls

The dynamic loader locates and maps the shared libraries a program needs. Libraries may depend on other libraries, and the loader may need to adjust references—called relocations—based on where the libraries are placed in memory.

The lecture demonstrates several ways to affect library loading:

• LD_PRELOAD: Loads a chosen library before the program’s ordinary dependencies. The example replaces read so a cat-like program repeatedly outputs data supplied by the replacement function. Preloaded libraries can also run code as they are loaded.
• LD_LIBRARY_PATH: Adds directories to the library search path.
• RPATH/RUNPATH: Executable metadata can specify additional library search locations.
• System configuration and cache: The loader also consults system library configuration and its cache, along with standard library directories.

Search behavior can depend on the executable and loader settings. The lecture cautions that system-wide preload configuration can break programs if configured incorrectly.

5. Process Memory Layout

Each process has its own virtual address space. It can contain the executable, shared libraries, a stack for function data and return information, and a heap used for dynamic allocation. The kernel maps these virtual addresses to physical memory.

The lecture inspects /proc/self/maps to show a process’s mapped regions, including its executable and libraries. Their addresses may be randomized, illustrating address-space layout randomization (ASLR).

6. Static and Dynamic Linking

A statically linked program includes its libraries in the executable. This simplifies loading and avoids separate shared-library mappings, but typically makes the file larger. Dynamic linking keeps libraries separate and can allow them to be shared across processes, but requires the loader to locate and initialize them.

The lecture also notes the security trade-offs: dynamic loading can make library locations less predictable, while a conventional static executable can expose predictable code locations. Position-independent static executables can address some of that predictability.

7. Initialization Before main

After the executable and its dependencies have been loaded, initialization code can run before the program’s main function. The lecture demonstrates a C constructor and shows that a preloaded library’s constructor can run before the program’s ordinary execution. This can be useful for initialization or debugging, but also has security implications.

Overall Loading Sequence

1. A shell or other parent process creates a child process.
2. The child calls execve to request a new program.
3. The kernel checks permissions and identifies the file format.
4. The kernel handles a script or executable format and maps the ELF program and, when needed, its dynamic loader.
5. The loader finds and loads shared libraries and performs required relocations.
6. Initialization routines run, followed by the program’s normal execution.

Speakers and Sources Featured

• Jan — the lecture’s presenter and instructor.
• Technical sources and tools demonstrated: Linux kernel process and executable-loading mechanisms; execve, fork/clone, binfmt_misc, /proc/self/maps, ldd, strace, LD_PRELOAD, LD_LIBRARY_PATH, and ELF-related tools.