How does kernel get an executable binary file running under linux?

It seems a simple question, but anyone can help me dig deep? How the file is loaded to memory and how execution code get started?

Can anyone help me and tell what's happening step by step?

Best moments of the exec system call on Linux 4.0

The best way to find all of that out is to GDB step debug the kernel with QEMU: How to debug the Linux kernel with GDB and QEMU?

fs/exec.c defines the system call at SYSCALL_DEFINE3(execve

Simply forwards to do_execve.
do_execve

Forwards to do_execveat_common.
do_execveat_common

To find the next major function, track when return value retval is last modified.

Starts building a struct linux_binprm *bprm to describe the program, and passes it to exec_binprm to execute.
exec_binprm

Once again, follow the return value to find the next major call.
search_binary_handler
- Handlers are determined by the first magic bytes of the executable.
  
  The two most common handlers are those for interpreted files (#! magic) and for ELF (\x7fELF magic), but there are other built-into the kernel, e.g. a.out. And users can also register their own though /proc/sys/fs/binfmt_misc
  
  The ELF handler is defined at fs/binfmt_elf.c.
  
  See also: Why do people write the #!/usr/bin/env python shebang on the first line of a Python script?
- The formats list contains all the handlers.
  
  Each handler file contains something like:
```
static int __init init_elf_binfmt(void)
{
    register_binfmt(&elf_format);
    return 0;
}
```
  and elf_format is a struct linux_binfmt defined in that file.
  
  __init is magic and puts that code into a magic section that gets called when the kernel starts: What does __init mean in the Linux kernel code?
  
  Linker-level dependency injection!
- There is also a recursion counter, in case an interpreter executes itself infinitely.
  
  Try this:
```
echo '#!/tmp/a' > /tmp/a
chmod +x /tmp/a
/tmp/a
```
- Once again we follow the return value to see what comes next, and see that it comes from:
```
retval = fmt->load_binary(bprm);
```
  where load_binary is defined for each handler on the struct: C-style polymorsphism.
fs/binfmt_elf.c:load_binary

Does the actual work:
- parse the ELF file according to the ELF specification, here is an overview of the ELF file format: How to make an executable ELF file in Linux using a hex editor?
- set up the process initial program state based on the parsed ELF file, most notably:
  - initial register setup in a struct pt_regs
  - initial virtual memory setup, the memory is specified in the ELF segments: What's the difference of section and segment in ELF file format
  - call start_thread, which marks the process as available to get to be scheduled by the scheduler
eventually the scheduler decides to run the process, and it must then jump to the PC address stored in struct pt_regs while also moving to a less privileged CPU state such as Ring 3 / EL0: What are Ring 0 and Ring 3 in the context of operating systems?

The scheduler gets woken up periodically by a clock hardware that generates interrupts periodically as configured earlier by the kernel, for example the old x86 PIT or the ARM timer. The kernel also registers handlers which run the scheduler code when the timer interrupts are fired.

TODO: continue source analysis further. What I expect to happen next:

the kernel parses the INTERP header of the ELF to find the dynamic loader (usually set to /lib64/ld-linux-x86-64.so.2).
if it is present:
- the kernel mmaps the dynamic loader and the ELF to be executed to memory
- dynamic loader is started, taking a pointer to the ELF in memory.
- now in userland, the loader somehow parses elf headers, and does dlopen on them
- dlopen uses a configurable search path to find those libraries (ldd and friends), mmap them to memory, and somehow inform the ELF where to find its missing symbols
- loader calls the _start of the ELF
otherwise, the kernel loads the executable into memory directly without the dynamic loader.

It must therefore in particular check if the executable is PIE or not an if it is place it in memory at a random location: What is the -fPIE option for position-independent executables in gcc and ld?

Two system calls from the linux kernel are relevant. The fork system call (or perhaps vfork or clone) is used to create a new process, similar to the calling one (every Linux user-land process except init is created by fork or friends). The execve system call replace the process address space by a fresh one (essentially by sort-of mmap-ing segments from the ELF executable and anonymous segments, then initializing the registers, including the stack pointer). The x86-64 ABI supplement and the Linux assembly howto give details.

The dynamic linking happens after execve and involves the /lib/x86_64-linux-gnu/ld-2.13.so file, which for ELF is viewed as an "interpreter".

After reading the ELF docs already referenced, you should just read the kernel code that actually does it.

If you have trouble understanding that code, build a UML Linux, and you could step through that code in the debugger.

You can start by understanding executable file formats, such as ELF. http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

The ELF file contains several sections with headers that describes how and where parts of the binary should be loaded into memory.

Then, I suggest reading up on the part of linux that loads binaries and handles dynamic linking, ld-linux. This is also a good description of ld-linux: http://www.cs.virginia.edu/~dww4s/articles/ld_linux.html

How does kernel get an executable binary file running under linux?

Related

Recent Posts