次の方法で共有

How do transition from user mode to kernel mode takes place

  • [アーティクル]

NTDLL is used to call into the operating system, which is (generally) in the address range (0x80000000-0xFFFFFFFF). The operating system addresses are not accessible in user-mode; therefore a special protected mechanism (using a CPU instruction which is sysenter..earlier it used to be Int 2e) is used to control the transition from user-mode to kernel-mode. NTDLL loads the system service number into the EAX register, then copies the address the processor-specific kernel-mode transition code on the Kernel-User shared page (0x7FFE0000 + 0x300) into the EDX register, then calls through the EDX register.

MOV EAX, Service Number
MOV EDX, MM_SHARED_USER_DATA_VA + UsSystemCall
CALL EDX
RET n

The processor-specific kernel-mode transition code depends upon whether the CPU is Intel, AMD or Pentium2 and earlier (Win2K and earlier). INT 2E vectors through the IDT (entry number 0x2E), while SYSCALL and SYSENTER vector through model-specific registers that are initialized at system boot time. –these are better explained at

https://www.codeguru.com/Cpp/W-P/system/devicedriverdevelopment/article.php/c8223/

Win2K and earlier:
LEA EDX, [ESP+4]
INT 2E ; Ends up calling KiSystemService
RET

WinXP and later (Intel):
MOV EDX, ESP
SYSENTER ; Ends up calling KiFastCallEntry, which then calls
KiSystemService
RET

AMD K6 and later
MOV EDX, ESP
SYSCALL ; Ends up calling KiSystemCall, which then calls
KiSystemService
RET

 

KiSystemService uses the system service number(in EAX) as an index into the system service dispatch table, which contains the address of the routine in the operating system to call. This prevents an application from calling any random address in the system; an application can only call those routines that are listed in the system service dispatch table.

 

During the initialization of NTOSKRNL, it creates a function table, hereafter referred to as the System Service Dispatch Table (SSDT), for different services provided by NTOSKRNL. Each entry in the table contains the address of the function to be executed for a given service ID. The handler looks up this table based on the service ID passed in EAX register and calls the corresponding system service. The code for each function resides in the kernel. Similarly, another table called the System Service Parameter Table [SSPT]) provides the handler with the number of parameter bytes to expect from a particular service. The handler refers to the first entry in the Service Descriptor Table for service IDs less than 0x1000 and refers to the second entry of the table for service IDs greater than or equal to 0x1000. The handler checks the validity of service IDs. If a service ID is valid, the handler extracts the addresses of the SSDT and SSPT. The handler copies the number of bytes (equal to the total number of bytes of the parameter list) described by the SSPT for the service–from user-mode stack to kernel-mode stack–and then calls the function pointed to by the SSDT for that service.

 

Gaurav Anand

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments