← Interview Prep

Linux Kernel — Program Execution

From command to running code: the fork+exec idiom, what execve does (binfmt/ELF, tearing down & rebuilding the address space, the stack with argv/envp/auxv, jump to entry), static vs dynamic linking and ld.so with PLT/GOT lazy binding, shebang scripts, O_CLOEXEC, setuid and ASLR/PIE.

What happens between typing a command and its code running — how the kernel replaces a process's memory with a new program and hands control to it. Original, interview-focused notes; builds on Processes and the Address Space.

The Unix idiom is fork + exec: fork() makes a copy of the calling process, then exec() replaces that copy's address space with a new program. fork creates the process; exec loads the code. Same PID, brand-new memory.

fork then exec

• A shell runs a command by fork()-ing itself, then the child calls execve() — so the parent (the shell) survives and can wait() for the child.
• exec does not return on success — the old program is gone, so there's nothing to return to. It returns only on failure (e.g. file not found).
• File descriptors survive exec unless marked O_CLOEXEC — how the shell wires up pipes/redirections before exec, and why you should set close-on-exec on fds a child shouldn't inherit.

What execve() actually does

1. Find the format: the kernel checks the file's magic against registered binfmt handlers — ELF for binaries, script for #! files, misc for others (Java, Wine via binfmt_misc).
2. Tear down & rebuild the address space: discard the old VMAs and map the new program's segments — text (code, read-only, shared), data/bss, and set up a fresh heap and stack.
3. Set up the stack: push argv, envp, and the auxiliary vector (auxv) — kernel-supplied info (page size, entry point, the vDSO address, ASLR random bytes) the loader needs.
4. Jump to the entry point in user mode.

Static vs dynamic linking & the loader

• A statically-linked binary contains all its code — the kernel jumps straight to it.
• A dynamically-linked binary names an interpreter (ld.so). The kernel maps the dynamic linker and jumps to it first; ld.so loads the shared libraries (from the auxv/ELF), resolves symbols, and then calls the program's entry.
• Symbol resolution is lazy via the PLT/GOT: the first call to a library function goes through the PLT stub, the linker resolves it and patches the GOT, subsequent calls are direct. (ldd shows the libraries; LD_PRELOAD/LD_LIBRARY_PATH influence loading.)

Scripts, security & hardening

• #! (shebang): the kernel reads the interpreter line and effectively execs that interpreter with the script as an argument — scripts aren't run by the kernel directly.
• setuid: a setuid binary runs with the file owner's privileges — exec is where the credential change happens (and why setuid is a security-sensitive surface).
• ASLR / PIE: a Position-Independent Executable lets the kernel randomize even the program's load base (via the auxv random seed), so exploit addresses aren't predictable; W^X keeps no page both writable and executable.