Read kernel perception-Camouflage scene-System Call Parameters

Source: Internet
Author: User

Source: http://www.top-e.org/jiaoshi/class/


The kernel occupies the hardware resources of the entire computer, as if it were a dictatorship. Sometimes he must be as fair as a judge, and sometimes he must be as cunning as a fox. The disguise scene is his masterpiece.

System calling is a special function, because it implements the conversion from user State to kernel state. To create a new process, the application cannot directly call sys_fork () in the user State (). This requires the kernel to disguise the call site as sys_fork.

For example, if fork () is called, it has a concise interface. However, its declaration in the corresponding function in the kernel is:

Asmlinkage int sys_fork (struct pt_regs regs)

If you are interested in the early Linux source code version (0.95), the statement is as follows:

Int sys_fork (long EBX, long ECx, long edX,

 

Long ESI, long EDI, long EBP, long eax, long ds,

 

Long es, long FS, long Gs, long orig_eax,

 

Long EIP, long CS, long eflags, long ESP, long SS)

How are these parameters. Why are user-state parameters inconsistent with kernel-state parameters?

For example, the number and type of user-state parameters of clone () and vfork () are different. But in kernel mode.

Asmlinkage int sys_clone (struct pt_regs regs)

Asmlinkage int sys_vfork (struct pt_regs regs)

Next, we can see how cleverly set the stack in the kernel makes the kernel function feel like the Upper-layer function is calling it.

 

It is easy to know that these parameters are used to push some registers into the kernel stack by the int 0x80 command and the save_all Macro when the system calls the kernel. The number and sequence of pushed registers are the same. They exactly correspond to struct pt_regs one by one. From this perspective, all system calls obtain the same parameters.

026 struct pt_regs {

 

027 long EBX;

 

028 long ECx;

 

029 long edX;

 

030 long ESI;

 

031 long EDI;

 

032 long EBP;

 

033 long eax;

 

034 int xds;

 

035 int xes;

 

036 long orig_eax;

 

037 long EIP;

 

038 int XCS;

 

039 long eflags;

 

040 long ESP;

 

041 int XSS;

 

042 };

XSS to EIP is pushed into the kernel stack by INT commands. Orig_eax to EBX is the entry (system_call) pressed into the stack. Orig_eax is the system call number. Eax is returned. EBP ~ EBX is used as the system call parameter.

 

In Linux, the corresponding function such as sys_fork () in the kernel has an asmlinage macro. It is defined:

# Define asmlinkage cpp_asmlinkage _ attribute _ (regparm (0 )))

That is to say, all parameters are passed through the stack. Note that the stack transfer is already in the kernel state, which is not in conflict with the system call parameter passing through the Register (that is, the previous switching from the user State to the kernel state ).

This means that we only need to cleverly set the stack so that sys_fork () has the illusion that a function on the upper layer directly calls sys_fork. In fact, sys_fork () can also be called directly in the kernel state.

We also observed that _ syscall0, _ syscall1, _ syscall2 ,... These macros are used to encapsulate system calls (only used by the kernel itself, and glibc does not use these macros .) The parameter passing method is as follows: parameter 1 ~ Parameter 6 is placed in EBX ECx edX esi edi ebp, which corresponds to the Order in pt_regs. Why is this order used?

1. This is related to compiler compilation rules. During Standard C function compilation, parameters are always pushed to the stack from right to left. When it is executed inside the function, parameters are retrieved from the stack in sequence based on such rules. So it is no exception in the kernel. When the application executes the system call, the entry (system_call) in the kernel state is called.

Call * sys_call_table (, % eax, 4)

All parameters are ready in the stack.

The specific understanding of these parameters depends on the definition of the function.

If the kernel stack contains a struct pt_regs, it can be defined

Asmlinkage int sys_fork (struct pt_regs regs)

If the kernel stack contains integers, it can be defined

Asmlinkage int sys_fork (long EBX, long ECx, long edX,

 

Long ESI, long EDI, long EBP, long eax, long ds,

 

Long es, long FS, long Gs, long orig_eax,

 

Long EIP, long CS, long eflags, long ESP, long SS)

Other system calls are similar.

The purpose of calling kernel functions is achieved through clever stack construction.

In addition to system calls, other functions such as do_page_fault () are also used in a similar way.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.