Hubbry Logo
search
logo
Loader (computing) avatar
Loader (computing)
Loader (computing)
current hub
L

Loader (computing)

logo
Community Hub0 Subscribers
Read side by side
Loader (computing)
View on Wikipedia
from Wikipedia

In computing, a loader is the part of an operating system that is responsible for loading programs and libraries. It is one of the essential stages in the process of starting a program, as it places programs into memory and prepares them for execution. Loading a program involves either memory-mapping or copying the contents of the executable file containing the program instructions into memory, and then carrying out other required preparatory tasks to prepare the executable for running. Once loading is complete, the operating system starts the program by passing control to the loaded program code.

All operating systems that support program loading have loaders, apart from highly specialized computer systems that only have a fixed set of specialized programs. Embedded systems typically do not have loaders, and instead, the code executes directly from ROM or similar. In order to load the operating system itself, as part of booting, a specialized boot loader is used. In many operating systems, the loader resides permanently in memory, though some operating systems that support virtual memory may allow the loader to be located in a region of memory that is pageable.

In the case of operating systems that support virtual memory, the loader may not actually copy the contents of executable files into memory, but rather may simply declare to the virtual memory subsystem that there is a mapping between a region of memory allocated to contain the running program's code and the contents of the associated executable file. (See memory-mapped file.) The virtual memory subsystem is then made aware that pages with that region of memory need to be filled on demand if and when program execution actually hits those areas of unfilled memory. This may mean parts of a program's code are not actually copied into memory until they are actually used, and unused code may never be loaded into memory at all.

Responsibilities

[edit]

In Unix and Unix-like systems, the loader is the handler for the system call execve().[1] The Unix loader's tasks include:

  1. validation (permissions, memory requirements etc.);
  2. memory-mapping the executable object from the disk into main memory;
  3. copying the command-line arguments into virtual memory;
  4. initializing registers (e.g., the stack pointer);
  5. jumping to the program entry point (_start).

In Microsoft Windows 7 and above, the loader is the LdrInitializeThunk function contained in ntdll.dll, which does the following:

  1. initialisation of structures in the DLL itself (i.e. critical sections, module lists);
  2. validation of executable to load;
  3. creation of a heap (via the function RtlCreateHeap);
  4. allocation of environment variable block and PATH block;
  5. addition of executable and NTDLL to the module list (a doubly-linked list);
  6. loading of KERNEL32.DLL to obtain several important functions, for instance BaseThreadInitThunk;
  7. loading of executable's imports (i.e. dynamic-link libraries) recursively (check the imports' imports, their imports and so on);
  8. in debug mode, raising of system breakpoint;
  9. initialisation of DLLs;
  10. garbage collection;
  11. calling NtContinue on the context parameter given to the loader function (i.e. jumping to RtlUserThreadStart, that will start the executable)

Relocating loaders

[edit]

Some operating systems need relocating loaders, which adjust addresses (pointers) in the executable to compensate for variations in the address at which loading starts. The operating systems that need relocating loaders are those in which a program is not always loaded into the same location in the (virtual) address space and in which pointers are absolute addresses rather than offsets from the program's base address. Some well-known examples are IBM's OS/360 for their System/360 mainframes, and its descendants, including z/OS for the z/Architecture mainframes.

OS/360 and derivatives

[edit]

In OS/360 and descendant systems, the (privileged) operating system facility is called IEWFETCH,[2] and is an internal component of the OS Supervisor, whereas the (non-privileged) LOADER application can perform many of the same functions, plus those of the Linkage Editor, and is entirely external to the OS Supervisor (although it certainly uses many Supervisor services).

IEWFETCH utilizes highly specialized channel programs, and it is theoretically possible to load and to relocate an entire executable within one revolution of the DASD media (about 16.6 ms maximum, 8.3 ms average, on "legacy" 3,600 rpm drives). For load modules which exceed a track in size, it is also possible to load and to relocate the entire module without losing a revolution of the media.

IEWFETCH also incorporates facilities for so-called overlay structures, and which facilitates running potentially very large executables in a minimum memory model (as small as 44 KB on some versions of the OS, but 88 KB and 128 KB are more common).

The OS's nucleus (the always resident portion of the Supervisor) itself is formatted in a way that is compatible with a stripped-down version of IEWFETCH. Unlike normal executables, the OS's nucleus is "scatter loaded": parts of the nucleus are loaded into different portions of memory; in particular, certain system tables are required to reside below the initial 64 KB, while other tables and code may reside elsewhere.

The system's Linkage Editor application is named IEWL.[3] IEWL's main function is to associate load modules (executable programs) and object modules (the output from, say, assemblers and compilers), including "automatic calls" to libraries (high-level language "built-in functions"), into a format which may be most efficiently loaded by IEWFETCH. There are a large number of editing options, but for a conventional application only a few of these are commonly employed.

The load module format includes an initial "text record", followed immediately by the "relocation and/or control record" for that text record, followed by more instances of text record and relocation and/or control record pairs, until the end of the module.

The text records are usually very large; the relocation and/or control records are small as IEWFETCH's three relocation and/or control record buffers are fixed at 260 bytes (smaller relocation and/or control records are certainly possible, but 260 bytes is the maximum possible, and IEWL ensures that this limitation is complied with, by inserting additional relocation records, as required, before the next text record, if necessary; in this special case, the sequence of records may be: ..., text record, relocation record, ..., control record, text record, ...).

A special byte within the relocation and/or control record buffer is used as a "disabled bit spin" communication area, and is initialized to a unique value. The Read CCW for that relocation and/or control record has the Program Controlled Interrupt bit set. The processor is thereby notified when that CCW has been accessed by the channel via a special IOS exit. At this point the processor enters the "disabled bit spin" loop (sometimes called "the shortest loop in the world"). Once that byte changes from its initialized value, the CPU exits the bit spin, and relocation occurs, during the "gap" within the media between the relocation and/or control record and the next text record. If relocation is finished before the next record, the NOP CCW following the Read will be changed to a TIC, and loading and relocating will proceed using the next buffer; if not, then the channel will stop at the NOP CCW, until it is restarted by IEWFETCH via another special IOS exit. The three buffers are in a continuous circular queue, each pointing to its next, and the last pointing to the first, and three buffers are constantly reused as loading and relocating proceeds.

IEWFETCH can, thereby, load and relocate a load module of any practical size, and in the minimum possible time.

Dynamic linkers

[edit]

Dynamic linking loaders are another type of loader that load and link shared libraries (like .so files, .dll files or .dylib files) to already loaded running programs.

Where such shared libraries can be shared by multiple processes, with only one single copy of the shared code possibly appearing at a different (virtual) address in each process's address space, the code in the shared library is required to be relocatable, ie the library must only use self-relative or code segment base-relative internal addresses throughout. Some processor have instructions that can use self-relative code-references in order to facilitate this.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Loader (computing)

View on Grokipedia
from Grokipedia
In computing, a loader is a system program that transfers object code or executable files from secondary storage into main memory, translating and preparing it for execution by adjusting addresses and setting the program's starting point.[1] This process enables the operating system to run user programs efficiently by managing memory allocation and resolving any relocation needs during loading.[2] Loaders perform essential functions such as copying binary code into fixed or dynamic memory locations, relocating address constants to fit the actual memory layout, and initiating program control transfer to the processor.[3] They are typically invoked by the operating system's shell when a user executes a program, distinguishing them from earlier stages like compilation and linking, where source code is transformed into relocatable object modules.[2] In modern systems, loaders often integrate with formats like ELF (Executable and Linkable Format) on Unix-like platforms to handle dependencies and shared libraries seamlessly.[2] Loaders are classified into several types based on their capabilities: absolute or binary loaders, which handle fixed-address code without modification; relocating loaders, which adjust addresses for flexible placement in memory; and linking loaders, which also resolve external references to libraries or other modules during the load process.[3] Bootstrap loaders represent a specialized variant used to initialize the operating system itself from ROM or disk during system startup.[1] Historically, loaders evolved from manual bootstrapping methods in the 1960s, where code was entered via switches, to sophisticated components in contemporary operating systems that enhance security, efficiency, and modularity in program execution.[1]

Fundamentals

Definition

In computing, a loader is a computer program that loads executable code into main memory, preparing it for execution by the operating system or runtime environment.[1] It takes object code or executable files from secondary storage, such as disk, and places them into the appropriate memory locations.[4] The primary role of a loader in the program execution lifecycle is to facilitate the transition from stored code to runnable form by resolving addresses and dependencies as needed, after which control is transferred to the loaded program.[1] This process ensures that the code is positioned correctly in memory and any required adjustments, such as relocation, are performed before execution begins.[5] Loaders originated in early batch processing systems of the 1950s and 1960s, where they automated the loading of programs from punched cards or tape to eliminate manual intervention and improve efficiency in mainframe environments.[6] Key characteristics of loaders include their integration as part of the operating system kernel, as seen in Unix-like systems where loading occurs via system calls like exec; as a separate utility program in some environments; or as components of runtime libraries, such as dynamic loaders handling shared objects.[5] They typically support standard executable formats, including ELF (Executable and Linking Format) for Unix-like systems, PE (Portable Executable) for Windows, and COFF (Common Object File Format) as a basis for others.[7]

Core Responsibilities

The loader performs a series of essential tasks to prepare an executable program for execution, ensuring a smooth transition from storage to active runtime. Central to this process is validation, where the loader examines the executable file to confirm its integrity, format, permissions, and system compatibility. It parses the file header to verify structural integrity and adherence to the expected format, such as checking for a magic number or signature that identifies valid executables like ELF files.[8] Additionally, the loader ensures the file possesses execute permissions as defined by the file system, preventing unauthorized or malformed programs from proceeding. Finally, it confirms architectural compatibility by inspecting fields like the machine type in the executable header, rejecting binaries intended for incompatible processors. Once validated, the loader allocates memory for the program, reserving distinct regions in virtual or physical address space for key segments including code (text), initialized data, uninitialized data (BSS), stack, and heap. This allocation is guided by the executable's header, which specifies segment sizes and attributes, allowing the loader to map pages or contiguous blocks while maintaining process isolation through mechanisms like page tables.[8] In systems supporting virtual memory, the loader initializes page directories and may employ demand paging to load segments lazily, optimizing resource use without immediate full commitment.[9] The loader then handles argument passing by copying command-line arguments, environment variables, and related metadata into program-accessible memory locations, often the stack, where they become available via standard entry point parameters like argc, argv, and envp.[8] This setup ensures the program can access invocation context without additional system calls. Initialization follows, where the loader configures runtime essentials such as setting the stack pointer and other registers, establishing the heap for dynamic allocation, and performing preliminary error checks for conditions like allocation failures.[8] It may also briefly adjust absolute addresses for relocation or resolve basic library dependencies, though these are elaborated in specific loader types. With preparations complete, the loader transfers control by jumping to the program's designated entry point, such as _start, initiating autonomous execution while the operating system monitors for termination or faults.[8]

Types of Loaders

Absolute Loaders

Absolute loaders are system programs that load object code directly into memory at fixed, predetermined addresses specified during assembly or linking, without performing any relocation or address modification.[10] This mechanism involves reading the object file—typically from a storage medium such as punched cards, paper tape, or disk—and copying the machine instructions and data sequentially into the exact memory locations indicated in the file.[10] Once loaded, control is transferred to the program's starting address, allowing immediate execution without further adjustments.[10] The simplicity of this process stems from the assumption that all addresses are resolved at compile time, making it one of the earliest and most straightforward loading techniques in computing history.[10] The primary advantages of absolute loaders lie in their efficiency and minimal resource requirements. They execute quickly because no additional processing for address resolution or relocation tables is needed, resulting in low overhead and suitability for resource-constrained environments.[10] This design also eliminates the need for specialized hardware or software to handle dynamic addressing, allowing for straightforward implementation in basic systems.[10] Furthermore, their fixed-address approach ensures predictable memory placement, which can simplify debugging and verification in controlled settings.[10] Despite these benefits, absolute loaders have significant limitations that restrict their use in more advanced computing scenarios. They require programmers to specify exact memory addresses during development, which demands precise knowledge of the system's memory layout and can lead to errors if allocations change.[10] In multitasking or multi-programming environments, this inflexibility prevents programs from being loaded into variable memory partitions, often resulting in overlaps, wasted space, or the inability to run multiple programs concurrently.[10] Consequently, they are ill-suited for modern operating systems that rely on dynamic memory management.[10] Absolute loaders found primary application in early computing systems and environments with static memory configurations, such as embedded systems and real-time applications where memory layout remains unchanged during operation.[10] They were particularly common in single-tasking setups, including batch processing on minicomputers, where predictability outweighed the need for flexibility.[10] A representative example is the absolute binary loader (ABSLDR) used in the PDP-8 minicomputer family, introduced by Digital Equipment Corporation in 1965, which loaded programs directly from paper tape into fixed core memory locations starting at address 0, enabling simple execution on this 12-bit machine without relocation support.[11] This approach contrasted with later relocating loaders by prioritizing speed over adaptability in resource-limited hardware.[10]

Relocating Loaders

A relocating loader is a system program that loads an object program into memory at an arbitrary location and modifies its address references to reflect the actual starting address, enabling flexible placement without requiring recompilation.[3] This contrasts with fixed-address loading by allowing programs to execute from variable memory positions, which supports multiprogramming and better resource utilization.[12] The relocation process begins with the loader scanning the relocatable object code, which includes metadata such as relocation bits or modification records indicating address fields that require adjustment.[3] For each identified field, the loader adds an offset—typically the difference between the program's starting address and its assumed origin during compilation—to update absolute or relative addresses, ensuring correct references to data and code within the module.[13] This adjustment occurs after allocating memory space but before transferring control to the program, often using a relocation table that lists the byte positions needing modification.[12] Relocating loaders primarily employ static relocation, performed once at load time to fix addresses for the duration of execution.[3] Static methods suffice for most cases, binding addresses definitively upon loading.[13] These loaders enable key benefits in multiprogramming environments, such as memory protection by isolating programs in non-overlapping regions and efficient sharing of relocatable modules across processes.[12] By supporting variable loading positions, they reduce fragmentation and allow the operating system to optimize memory allocation dynamically.[3] However, relocating loaders face challenges, including the need for specialized relocatable object formats that embed relocation information, which complicates code generation during assembly or compilation.[13] The scanning and modification process also increases load time compared to absolute loading, as the loader must parse and update potentially numerous address fields.[12] A central element is the relocation dictionary or table within the executable, which enumerates addresses or instructions requiring offset application, often implemented as a list of modification records specifying length and location for precise updates.[3] This structure ensures systematic relocation without altering non-address constants.[13]

Linking Loaders

Linking loaders extend relocating loaders by also resolving external references to symbols in other modules or libraries at load time.[3] This allows multiple object files to be combined into a single executable without prior static linking, supporting modular program development. The process involves building an external symbol table during a first pass to assign addresses to symbols defined in the modules, then using this table in a second pass to replace references to external symbols with their actual addresses, combined with relocation adjustments.[12] Modification records guide updates to address fields referencing external symbols, ensuring all dependencies are resolved before execution.[13] Linking loaders are particularly useful in systems like IBM OS/360, where they facilitate batch processing of multiple programs with shared subroutines, improving efficiency over separate compilation and linking stages.[3] However, they increase load time due to symbol resolution and require consistent symbol naming across modules.

Dynamic Loaders

Dynamic loaders, also known as dynamic linkers, are runtime components responsible for loading and linking shared object modules, such as .so files in Unix-like systems or .dll files in Windows, into a running program's address space on demand. Unlike static linking, where all dependencies are resolved and embedded at compile or link time, dynamic loaders defer this process to runtime, allowing the operating system to map libraries into memory as needed and resolve symbols through dynamic linking tables like the Procedure Linkage Table (PLT) or Import Address Table (IAT). This mechanism enables efficient sharing of code across multiple processes without duplicating library instances in memory.[14][15] The loading process begins when the dynamic loader parses the dependency list from the executable's dynamic section, identifying required shared objects via entries like DT_NEEDED in ELF format or the Import Directory Table in PE format. It then recursively loads these libraries in a breadth-first order, appending dependencies to a link chain to avoid duplicates and ensuring all prerequisites are mapped into memory before proceeding. Symbol resolution occurs lazily during execution: the loader searches symbol tables (e.g., .dynsym in ELF) and hash tables to match undefined references, updating indirect jump tables such as the PLT for subsequent direct calls without further intervention. For PE files, the loader populates the Import Address Table (IAT) with actual function addresses from loaded DLLs, facilitating runtime binding. This recursive and on-demand approach contrasts with initial program relocation by focusing on modular extensions rather than fixed offsets.[16][17][14] To support flexible placement in memory, dynamic loaders rely on position-independent code (PIC), which compiles libraries to execute at any address without modification by using relative addressing and indirection tables like the Global Offset Table (GOT). PIC avoids the need for text segment relocations, preserving read-only sharability and reducing startup overhead, though it may introduce minor runtime performance costs due to indirect accesses. In ELF, the .dynamic section provides essential metadata for this, including pointers to relocation tables (DT_RELA or DT_REL) that the loader applies post-loading. Similarly, PE import tables guide the Windows loader in adjusting addresses without altering the original DLL code.[18][16][17] Dynamic loaders offer significant advantages over static approaches, including reduced memory usage through code sharing—where multiple applications load the same library at a shared base address, minimizing physical memory footprint and swapping—and support for modular software architectures like plugins, which can be added or updated without recompiling the main program. This runtime flexibility also enables post-deployment updates to libraries for bug fixes or new features, provided interfaces remain compatible, and promotes interoperability across programming languages using standard calling conventions. However, these benefits come with the trade-off of potential startup delays from symbol resolution.[19][14]

Historical Examples

Early Loaders

The origins of computer loaders trace back to the 1940s, when programming early electronic computers like the ENIAC required manual intervention. Operators loaded programs by physically setting thousands of switches and connecting cables to configure the machine's wiring panels, a process that could take days for each new task due to the absence of automated input mechanisms.[20][21] This labor-intensive approach limited efficiency and scalability, as every program change demanded reconfiguration from scratch. By 1951, the UNIVAC I introduced automation through magnetic tape readers, allowing programs and data to be loaded sequentially from reels of phosphor-bronze tape, marking a shift from purely manual methods to semi-automated batch processing.[22][23] In the 1950s, loaders evolved to support absolute addressing, as seen in systems like the IBM 701, where programs were loaded into fixed memory locations without relocation, requiring programmers to compute exact addresses manually.[24] This absolute loader design simplified implementation but constrained flexibility, as code could not be repositioned in memory. To address addressing challenges, symbolic loaders emerged, allowing the use of labels and symbols instead of numeric addresses, which were resolved during the loading process; this innovation, pioneered in machines like the IBM 704, reduced errors and improved programmer productivity.[24][25] The 1960s brought advancements for time-sharing and memory-limited environments, with relocating loaders introduced in systems such as CTSS and Multics. These loaders adjusted program addresses dynamically during loading to fit available memory, supporting multiple users by relocating code as needed in the IBM 7094's architecture.[26][27] For memory-constrained batch systems, overlay loaders managed hierarchical program structures, loading only active modules into memory while swapping inactive ones from secondary storage, a technique essential for fitting large applications into limited core.[28] A pivotal milestone occurred in 1964 with the IBM System/360, whose OS/360 incorporated standardized loader concepts, including linkage editing for modular programs and support for both absolute and relocating modes, influencing subsequent mainframe designs.[29][30] Early loaders, however, were inherently tied to specific hardware architectures, lacking portability across machines and requiring custom adaptations for each system. Additionally, they provided no support for dynamic linking, forcing all resolutions to occur at load time rather than runtime, which restricted modularity in evolving software environments.[31]

OS/360 and Derivatives

In IBM's OS/360 operating system, introduced in 1964, the relocating loader was a key component for preparing and executing programs on System/360 mainframes, handling the transition from object modules to relocatable load modules that could be placed in memory at runtime. The primary tool for this process was the linkage editor, IEWL (IBM Executive Work Load), which combined multiple object modules generated by compilers or assemblers, resolved external references, and produced executable load modules stored in partitioned data sets.[32] These load modules were then fetched into main storage using programs like IEFETCH (for multiprogramming with a variable number of tasks, MVT) or IEWFETCH (for multiprogramming with a fixed number of tasks, MFT), which employed channel programs to efficiently transfer data from direct-access storage devices such as the IBM 2311 or 2314 disks.[32][33] Relocation in the OS/360 loader was hardware-assisted through the use of base registers, which allowed address constants in the load module to be modified dynamically at load time based on the relocation dictionary (RLD) embedded in the module.[32] This mechanism enabled programs to be loaded at any available memory location without prior knowledge of the exact address, supporting the System/360's architecture where programs were designed to be position-independent relative to base registers. To accommodate large programs in systems with limited main memory—typically 44 KB to 128 KB on early models—the loader supported overlays, organizing code into segments and up to four regions, with a maximum of 255 segments per module, allowing only necessary parts to be loaded dynamically during execution.[32] The loader's design emphasized performance through direct-access storage, which minimized seek times and improved I/O efficiency compared to tape-based systems, with supported record sizes up to 18 KB on devices like the 2314 disk pack.[32] By integrating buffering improvements and eliminating redundant I/O operations during the edit-and-load process, the OS/360 loader reduced overall editing and loading times by approximately 50% relative to separate linkage editor invocations, making it suitable for batch processing environments.[33] Unique to the OS/360 loader were provisions for minimum memory configurations, requiring as little as 15 KB for basic level E operations plus additional space for program size and tables (e.g., 4 bytes per segment plus 24 bytes overhead in the segment table), enabling deployment on smaller System/360 models.[32] It also featured scatter-loading via the SCTR option, permitting non-contiguous placement of control sections (CSECTs) and segments in memory or storage hierarchies to optimize resource usage in constrained environments.[32] In derivatives like z/OS, the loader evolved to leverage virtual storage, assigning relative virtual addresses to CSECTs and entry points during linkage editing, which resolved references and supported larger address spaces beyond physical limits.[34] Load modules in z/OS retain core formats from OS/360, including defined entry points via END statements and CSECT mappings for debugging and relocation, but incorporate enhancements like program objects for 64-bit addressing and integration with the binder utility, which superseded IEWL for modern program management.[34][32]

Modern Implementations

Unix-like Systems

In Unix-like systems, such as Linux and BSD variants, the kernel plays a pivotal role in initiating executable loading via the execve() system call, which replaces the current process image with a new program. The kernel first validates the binary as an ELF file using the binfmt_elf module, which parses the ELF header and program header table to identify loadable segments marked with PT_LOAD. These segments are then mapped into the process's virtual address space using the mmap() system call, with memory protections (read, write, execute) set according to the p_flags field in each program header; for instance, code segments are typically mapped read-only and executable, while data segments allow writing. The kernel also initializes the process stack, argc/argv environment, and auxiliary vector before jumping to the ELF entry point, thereby establishing the foundational address space for user-mode execution.[35] User-space loading is handled by the dynamic linker, invoked via the PT_INTERP program header that specifies its path (e.g., /lib/ld-linux.so.2 on Linux). In Linux with glibc, ld.so parses the ELF headers of the main executable and dependent shared libraries, loading their PT_LOAD segments into memory and consulting the .dynamic section for dependency lists and symbol tables. It resolves relocations for position-independent code (PIC), applying types such as R_X86_64_RELATIVE to adjust relative addresses without fixed base dependencies, enabling libraries to load at arbitrary locations. FreeBSD's rtld-elf.so.1 performs analogous tasks, processing ELF structures to link objects dynamically. For runtime flexibility, the linker exposes interfaces like dlopen() to load additional shared objects on demand and dlsym() to retrieve symbol addresses, facilitating plugin architectures and deferred loading.[36][37][38] To optimize performance and security, Unix-like loaders support prelinking, which precomputes relocations and assigns virtual address slots to binaries and libraries during installation, reducing dynamic linker overhead at startup by up to 30-50% for complex applications like web browsers. Address Space Layout Randomization (ASLR) further enhances security by randomizing load addresses for the stack, heap, mmap'ed regions, and PIE executables during kernel mapping and linker operations, controlled by the kernel's /proc/sys/kernel/randomize_va_space parameter (values 1 or 2 enable partial or full randomization). In practice, glibc's ld.so integrates these features seamlessly for Linux ELF binaries, while FreeBSD's rtld-elf provides equivalent support with BSD-specific optimizations, such as efficient symbol caching.[39][40][36][37]

Windows Systems

In Microsoft Windows systems, the loader is implemented primarily in the user-mode library ntdll.dll and handles the loading of executable images in the Portable Executable (PE) format, which is based on the Common Object File Format (COFF). The primary components include functions in ntdll.dll, such as LdrpInitializeProcess for initializing loader routines and LdrInitializeThunk as the initial entry point for process initialization, which sets up the loader, heap manager, and thread-local storage. Wrappers in kernel32.dll, like LoadLibrary, provide higher-level APIs that invoke ntdll.dll's LdrLoadDll to dynamically load modules.[41][42] The loading process begins with validation of the PE/COFF format, where the loader reads the file offset at 0x3C (e_lfanew) to locate and verify the PE signature, verifies the optional header magic number (0x10B for PE32 or 0x20B for PE32+), and ensures alignment of data directories like the import table. Sections are then mapped into memory using NtMapViewOfSection, with file offsets (PointerToRawData) aligned to virtual addresses (VirtualAddress), zero-padding gaps if necessary, and sections ordered contiguously by relative virtual address (RVA). Imports are resolved via the Import Address Table (IAT) in the .idata section, where LdrpWalkImportDescriptor locates DLL dependencies and LdrpSnapIAT updates the IAT with actual function addresses, handling forwarded exports recursively. DLL entry points, such as DllMain, are called recursively during loading to initialize dependencies, with load counts updated via LdrpUpdateLoadCount to track reference usage.[17][41] Windows NT, released in 1993, introduced protected loading through its protected subsystems, ensuring that user-mode processes operate in isolated environments with kernel-enforced memory protection during image mapping and execution. Process initialization includes heap creation via RtlCreateHeap in LdrInitializeThunk, a standard part of the NT design since its inception, as well as setting up thread contexts for better concurrency support. The loader supports delay-loading for optional DLLs, enabled by the /DELAYLOAD linker option, which defers loading until a function call via a helper routine, reducing startup overhead for unused modules. For .NET assemblies, the Common Language Runtime (CLR) loader dynamically loads managed code into application domains using Assembly.Load, with unloading managed through AssemblyLoadContext in .NET Core. Recursive loading ensures all dependencies are resolved before execution, while error handling during process creation, such as via NtCreateProcessEx, propagates status codes like STATUS_INVALID_IMAGE_FORMAT for malformed PE files.[43][42][44][45][46]

Security Considerations

Loaders in computing systems are susceptible to various security vulnerabilities that can compromise the integrity of loaded modules. Buffer overflows, particularly in path parsing components, have been exploited in graphics loaders like GDI+, where malformed inputs such as JPEG images lead to heap-based overflows allowing remote code execution.[47] Similarly, DLL hijacking exploits the search order used by loaders to locate dynamic libraries, enabling attackers to substitute malicious DLLs in directories searched before trusted paths, thereby injecting code during loading.[48][49] To mitigate these risks, loaders incorporate code signing verification mechanisms. In Windows, Authenticode signatures are checked during module loading to ensure binaries originate from trusted publishers and remain untampered.[50] In some Unix-like systems, such as Oracle Solaris, signatures based on SHA-256 checksums of ELF sections can be verified to confirm integrity before execution.[51] Sandboxing further isolates loader operations, restricting potentially malicious code to controlled environments that prevent system-wide impact.[52] Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) are integral to loader security. ASLR randomizes the base addresses of loaded modules to hinder exploitation of memory corruption vulnerabilities by making return addresses unpredictable.[53] DEP complements this by marking non-executable memory regions, such as stacks, as inaccessible for code execution during the loading process.[53] Modern threats to loaders include supply-chain attacks, as demonstrated in the SolarWinds incident, where attackers tampered with software updates that loaders subsequently executed, enabling persistent backdoors across networks.[54] To counter such risks, integrity checks are performed during key loading APIs; for instance, Linux's execve() leverages Integrity Measurement Architecture (IMA) to validate file hashes against known good values, while Windows' LdrLoadDll can enforce signature requirements via linker flags.[55][56] Best practices for loader security emphasize precursors like secure boot processes, which verify bootloader signatures before OS loaders activate, preventing root-level compromises.[57] Runtime integrity monitoring, using tools like IMA, continuously attests to loaded module states post-execution to detect tampering.[55]

References

  1. Lecture 7, Object Codes, Loaders and Linkers - University of Iowa
  2. [PDF] Linking - Computer Systems: A Programmer's Perspective
  3. [PDF] Linkers and Loaders LEON PRESSER AND JOHN R. WHITE
  4. https://www.cs.csi.cuny.edu/~yumei/csc718/Compiler%2C%2520Linker%2C%2520Loader%2520-%2520An%2520Intro%2520To%2520Relocatable%2520Modules.htm
  5. linking.html
  6. [PDF] History of Operating Systems: Phases - UT Computer Science
  7. [PDF] Assemblers, Linkers, and Loaders - Cornell: Computer Science
  8. None
  9. [PDF] Chapter 2: Operating-System Structures
  10. [PDF] Abraham-Silberschatz-Operating-System-Concepts-10th-2018.pdf
  11. OS/8 Command Reference - PDP-8
  12. [PDF] Chapter 3 Loaders and Linkers | Atria | e-Learning
  13. [PDF] LOADER AND LINKER - Prof. Anand Gharu
  14. [PDF] The inside story on shared libraries and dynamic loading - UCSD CSE
  15. [PDF] From Dynamic Loading to Extensible Transformation - USENIX
  16. Dynamic Linking
  17. PE Format - Win32 apps - Microsoft Learn
  18. Position-Independent Code - Linker and Libraries Guide
  19. Advantages of Dynamic Linking - Win32 apps - Microsoft Learn
  20. 4.8 Project PX and the ENIAC | Bit by Bit
  21. ENIAC - CHM Revolution - Computer History Museum
  22. UNIVAC I - U.S. Census Bureau
  23. [PDF] An Introduction to the Univac File-Computer System, 1951
  24. [PDF] John Backus - Software Preservation Group
  25. [PDF] Contents - David Salomon
  26. [PDF] The Compatible Time-Sharing System - People | MIT CSAIL
  27. The IBM 7094 and CTSS - Multics
  28. [PDF] Virtual Memory - the denning institute
  29. The IBM System/360
  30. Big Ideas in the History of Operating Systems - Paul Krzyzanowski
  31. [PDF] Types for the Chain of Trust: No (Loader) Write Left Behind
  32. [PDF] IBM OS - Bitsavers.org
  33. [PDF] Systems Reference Library IBM System/360 Operating System ...
  34. How a load module is created - IBM
  35. elf(5) - Linux manual page - man7.org
  36. ld.so(8) - Linux manual page - man7.org
  37. https://man.freebsd.org/cgi/man.cgi?query=rtld&sektion=1
  38. dlopen(3) - Linux manual page - man7.org
  39. [PDF] Prelink - Red Hat People
  40. Documentation for /proc/sys/vm - The Linux Kernel documentation
  41. What Goes On Inside Windows 2000: Solving the Mysteries of the ...
  42. [PDF] Sample Chapters from Windows Internals, Sixth Edition, Part 1
  43. [PDF] Custer_Inside_Windows_NT_19...
  44. Linker support for delay-loaded DLLs | Microsoft Learn
  45. How to: Load and unload assemblies - .NET - Microsoft Learn
  46. [PDF] Lost in Transaction: Process Doppelgänging - Black Hat
  47. CVE-2025-53766 Detail - NVD
  48. Dynamic-Link Library Security - Win32 apps | Microsoft Learn
  49. Hijack Execution Flow: DLL, Sub-technique T1574.001 - Enterprise
  50. Authenticode Digital Signatures - Windows drivers - Microsoft Learn
  51. Verified Boot and ELF Signatures - Oracle Help Center
  52. Windows Sandbox | Microsoft Learn
  53. On the effectiveness of DEP and ASLR - Microsoft
  54. Deep dive into the Solorigate second-stage activation - Microsoft
  55. Runtime Integrity Monitoring - Keylime Documentation
  56. /INTEGRITYCHECK (Require signature check) | Microsoft Learn
  57. Windows Secure Boot Key Creation and Management Guidance
User Avatar
No comments yet.