2017-2018-1 20179203 "Linux kernel Fundamentals and analysis" Eighth week assignment

Grasping Writer: Li Pengju No.: 20179203
( original Works reproduced please specify the source )
(Study course: "Linux kernel Analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000)

First, the experimental requirements:

1. Understand the process of compiling links and the elf executable file format, refer to the first section of this week for details;
2. Programming using the exec* library function to load an executable file, dynamic link is divided into executables when loading dynamic link and runtime dynamic link, programming exercises dynamic link Library of these two ways of use, the details refer to the second section of this week;
3. Use GDB trace to analyze a EXECVE system call kernel processing function SYS_EXECVE, verify your understanding of the process required to load the executable program Linux system, the details of this week in the third section, recommended in the experimental Building Linux virtual machine environment to complete the experiment.
4. Paying particular attention to the commencement of the new executable process? Why does the new executable program execute smoothly after the EXECVE system call returns? What is the difference between a static-linked executable program and a dynamically-linked executable EXECVE system call return?

Second, the experimental process:

1. Start updating the kernel first and then overwrite the test.c with TEST_EXEC.C:

1. The Exec system call is added to the test.c file, and the makefile file adds Gcc-o Hello hello.c-m32-static, starts the kernel, and verifies that the EXECV function is correct:
   
   

2. Finally, start GDB debugging:
   

3. Set breakpoints at Sys_execve and elsewhere and step into it:
   

5. Finally exit the debug state and enter Redelf-h hello to see the EIF header of Hello:

Three, experimental analysis: 1.elf head Analysis:

The elf head size is 52 bytes, and the first 52 bytes are analyzed with the dump command 16 binary read
Command: Hexdump–x hello–n 52

Analysis:
First line, corresponding to E_ident[ei_nident]. The small-end method actually represents the content of 7f454c46010101000000000000000000, the first four bytes are elf fixed beginning 7f454c46 (0x45,0x4c,0x46 is ' e ', ' l ', ' f ' corresponds to the ASCII encoding), Indicates that this is an Elf object. The next byte 01 represents a 32-bit object, and the next byte 01 represents the small-end method, and the next byte 01 represents the file header version. The remaining defaults are set to 0.
The second line, the E_type value is 0x0002, represents an executable file. The E_machine value is 0x0003, which represents the Intel80386 processor architecture. The E_version value is 0x00000001, which indicates the current version. The E_entry value is 0x04080a8d, which represents the entry point. The E_phoff value is 0x00000034, which indicates that the offset of the program Header table is 0x34, which is 52 bytes just the elf head size.
In the third row, the E_shoff value is 0x000a20f0, which represents the offset address of the section Header table. The E_flags value is 0x00000000, which indicates an unknown processor-specific flag. The E_ehsize value is 0x0034, which represents an elf file header size of 52 bytes. E_phentsize represents the length of the entry (program header) in a Program Header table, with a value of 0x0020 that is 32 bytes. The value of E_phnum is 0x0006, giving the number of entries in the Program Header table. A e_shentsize value of 0x0028 indicates that the Header table entry (section header) is 40 bytes in size.
Row four, the E_shnum value is 0x001f, indicating that there are 31 Header table entries. The E_shstrndx value is 0x001c, which represents the index number in the section table of the section name string table.

2.exec () function structure analysis

  int do_execve (struct filename *filename, const char __user *const __user *__argv, const char __user *cons  T __user *__envp) {return Do_execve_common (filename, argv, envp);} static int Do_execve_common (struct filename *filename, struct user_arg_ptr argv, struct user     _arg_ptr envp) {//Check the number of processes limit//Select the minimum load CPU to execute the new program sched_exec ();     Filling LINUX_BINPRM Structure retval = PREPARE_BINPRM (BPRM);    Copy file name, command line arguments, environment variable retval = Copy_strings_kernel (1, &bprm->filename, BPRM);    retval = Copy_strings (BPRM->ENVC, ENVP, BPRM);     retval = Copy_strings (BPRM->ARGC, argv, BPRM);     Call inside the Search_binary_handler retval = EXEC_BINPRM (BPRM); EXEC executes successfully} static int exec_binprm (struct LINUX_BINPRM *bprm) {//Scan formats linked list, depending on the text format, choose different load function ret = Search_b    Inary_handler (BPRM); ... return ret;}  

In the last week's learning experiment, I learned the single step of the fork () and saw the structure of the fork () function. I also looked at and analyzed the structure of the EXEC () function that I learned this week.
by the above code, Do_ Execve call Do_ execve_ Common, and do_ execve_ Common and mainly rely on Exec_ BINPRM, in Exec_ BINPRM has a vital function, called Search_ Binary_ handler. This is the internal process of SYS_EXECVE. The focus of this week's study is the process of file processing:
Preprocessing: Gcc–e–o hello.cpp Hello.c-m32 (responsible for including the include file, macro substitution)
Compilation: Gcc-x cpp-output–s Hello.s–o Hello.cpp-m32 (Gcc–s call CCL, compiled into assembly code)
Assembly: Gcc-x assembler–c Hello.s–o hello.o; (Gcc-c call as, get binary)
Link: gcc–o He Llo hello.o; gcc-o (call ld form target executable)
links are classified as static links and dynamic links. Static chaining is delivered to three main elf target files:
1. relocatable Files: Save code and appropriate data to create an executable file or a shared file with other object files. Mainly the. o file.
2. executable file: Save a program to execute, indicating how exec (Ba_os) created the process image of the program, how to load it out, and where to start execution.
3. Shared file: The code and data are saved to be linked by the following two linker.
One is the link compiler, you can create additional object files with other relocatable and shared files;
The other is a dynamic linker that unites an executable file and other shared files to create a process image. The main is the. so file.
Eip is also an important concept, for EIP, if it is a statically linked executable file, then the EIP point to the elf file header E_entry refers to the entry address;
If it is a dynamic link, the EIP points to the dynamic linker. For Execve, when performing a static linker, modify the value of the EIP saved in the kernel stack as a starting point for the new process.

2017-2018-1 20179203 Linux kernel Principles and analysis eighth week of work