An analysis of the Windows Kernel Learning notes system call

In the book "Principles and implementations of Windows kernel", teacher pan resolves the system calls made by Windows applications. This is illustrated below.

As you can see from the graph, the service (function) provided by the system call is running in the kernel, that is, in system space.

The user space is different from the memory interval in which the system space is located, and the CPU's running state is different for both of these zones.

In user space, the CPU is in "User state"; In system space, the CPU is in "System State".

It is easy for the CPU to enter the user state from the system state, because it can execute some special privileged commands to enter the user state.

On the contrary, it is not easy to enter the system state because the user state cannot execute the privileged instruction.

Therefore, there are generally three ways to make the CPU into the system state (that is, into the system space execution): interrupts, anomalies, self-trapping.

about Directive int 2e.

The Intel X86 processor finds 2e items in the IDT (Interrupt Description service table), Idtentry contains a segment selector and an intra-segment offset of the interrupt history, so the processor also needs to be checked again in the GDT (Global description table) to get the virtual address of the segment specified by the segment selector. The Subgrade address, plus the interrupt routine offset, eventually gets the virtual address of the interrupt routine.

The processor uses different stacks in different modes, user-mode code uses the user stack, kernel-mode code uses the kernel stack, so it must be accompanied by changes in the stack when it is cut from user mode to the kernel.

The main difference between Int 2e and Sysenter is the way the stack is switched. However, either way, in essence, the kernel stack is first obtained and then saved in user mode Ss,esp,eflags.cs.eip to the kernel stack, and after the system call is performed, the user space is restored by the saved value.

First, we first analyze the stack switch of the int 2e/iret.

How do I get the SS and ESP for the kernel stack first?

The processor's task register points to the TSS of the current task environment, where the RING0 ESP is located in the tss+4 location. Every time Windows switches threads, the RING0 esp in TSS is always set up.

After the interrupt processing is completed, the EIP,CS,EFLAGS,ESP,SS is ejected from the kernel stack via Iret, and the control is given to the user-mode code pointed to by the EIP.

Obviously, there are many processes involved in the mode switching process through int 2e/iret, which is expensive. So after XP introduced Sysenter/sysexit, fast system call.

Then look at the sysenter/sysexit stack switch.

To avoid excessive memory access, Sysenter adds three MSR registers to specify the jump target and stack position.

Let's try to follow the example of NT under XP.

kd> u ntdll!ntwritefile
ntdll! Zwwritefile:
7C92DF60 b812010000 mov eax,112h
7C92DF65 ba0003fe7f mov edx,offset shareduserdata! SystemCallStub (7ffe0300)
7C92DF6A Ff12 call DWORD ptr [EDX]
7C92DF6C c22400 ret 24h
7C92DF6F-NOP

First you see Ntdll in Ntwritefile to save the index into EAX, and then call the Callsystemstub function pointer in the SHAREUSERDATA structure.

We continue to follow the Shareuserdata structure (_kuser_shared_data)

kd> DT _kuser_shared_data 0x7ffe0000
Ntdll!_kuser_shared_data

.

.

.

+0x300 systemcall:0x7c92e4f0
+0x304 Systemcallreturn:0x7c92e4f4

.

.

So we can see clearly the function pointer at the 0x300.

kd> u 0x7c92e4f0
ntdll! Kifastsystemcall:
7C92E4F0 8BD4 mov edx,esp; note that esp at this point represents a parameter block
7C92E4F2 0f34 Sysenter

ntdll! Kifastsystemcallret:
7C92E4F4 c3 ret

The Sysenter command then enters the kernel's kifastcallentry () function.

kd> u kifastcallentry L 50
Nt! Kifastcallentry:
.

.

.

8053e612 8bf2     mov esi,edx      ; esp for user space

8053e614 8b5f0c     mov ebx,dword ptr [edi+0ch]
8053e617 33c9       & nbsp         XOR ecx,ecx
8053e619 8a0c18              mov cl,byte ptr [EAX+EBX]      &NBSP
8053e61c 8b3f                  mov E Di,dword ptr [edi]        ,
8053e61e 8b1c87              mov ebx, DWORD ptr [edi+eax*4]

8053e623 c1e902              SHR E cx,2
8053e626 8BFC                  mov EDI , esp
8053e628 3b35d4995580  cmp esi,dword ptr [nt! Mmuserprobeaddress (805599D4)]
8053e62e 0f83a8010000 Jae nt! kisystemcallexit2+0x9f (8053E7DC)

The above is a system call process initiated from the RING3 layer, it is interesting that the RING0 layer will recursively enter kifastcallentry if the ZW function is called, and then call the NT function.

This is the biggest difference between the kernel ZW function and the NT function! (The ZW function in Ntdll does not differ from the NT function)

So it is tedious to return kifastcallentry, mainly because the stack that originated the system call is determined by the previous pattern to be the user control or the system space, and then the different processing.

Initiating system call ingress kernel routines return instruction return kernel routines

int 2e KiSystemService Iret kisystemcallexit

Sysenter (Intel) kifastcallentry sysexit KiSytemcallExit2

Syscall (AMD) kifastcallentry Sysreturn KiSystemCallExit3

An analysis of the Windows Kernel Learning notes system call