User Mode and Kernel Mode-WDM Learning (1)

User Mode and Kernel Mode

From intel80386, the series of CPUs can run onRing0 ~ Ring3There are four different permission levels from high to low, and four protection levels are also provided for data. Running at a lower levelCodeYou cannot call high-level code or access high-level data at will, and only the code running on the ring0 layer can directly access the physical hardware. WindowsNT is an operating system that supports multiple platforms. To be compatible with other platforms, it only uses two CPU running levels. AKernel ModeCorresponding to the ring0 layer of 80x86, which is the core part of the operating system and the device driverProgramIs to run in this mode; the other is calledUser ModeCorresponding to Layer 3 of ring80 x86, the user interface of the operating system (that is, the Win32 API we usually call) and all user applications run at this level. The operating system does not defend the code running in kernel mode. Therefore, programming in kernel mode is worth studying, whether it is construction or destruction.

As shown in the following figure:

 

WindowsThe driver can run in both user and core modes.

Differences between user-mode and core-level Drivers

User-mode drivers run in nonprivileged processor mode, and some other protected subsystem code also run in this mode. User-mode drivers cannot access system data unless Win32 APIs or system services are called.

The core-state driver is executed as an integral part of the operating system. It supports the underlying components of the operating system of one or more protected subsystems.

The user-state and core-state drivers have different structures, different endpoints and different system interfaces. Whether a device requires a user-mode driver or a core-mode driver depends on the type and operating system of the device.

Some device drivers can run completely or partially in user mode. The user-mode driver has no restrictions on stack space. It can access Win32 APIs and is easy to debug.

Most device drivers run in the core state. The core-state driver can complete some protected operations and access the system struct that the user-state driver cannot access (system sturcture ). However, the improvement of access permissions also requires a corresponding price-debugging is difficult, and the system is at risk of destruction at any time. When the code runs in a privileged core environment, the operating system checks the integrity and validity of the data requested by the Code.

For convenience, high-level language should be used to write the driver. Generally, C is suitable for compiling the core-state driver, C or C ++ is suitable for compiling user-mode drivers.

How does the user mode interact with the kernel mode?When the user mode program needs to read device data, it calls the Win32 API function, suchReadfile. The Win32 subsystem module (such as kernel32.dll) calls the platform-Related System Service Interface to implement this API, and the platform-related system service calls the kernel mode support routine. InReadfileThe call first arrives at an entry point in the system DLL (NTDLL. dll,NtreadfileFunction. Then the user-mode ntreadfile function calls the System Service Interface, and finally the System Service Interface calls the service routine in kernel mode, which is also named ntreadfile.

There are many service routines similar to ntreadfile in the system. They also run in kernel mode to provide services for application requests and interact with devices in some way. They first check the parameters passed to them to protect system security or prevent unauthorized access to data by user mode programs, and then create a data structure called "I/O Request Packet (IRP, and send the data structure to the entry point of a driver. In the call to readfile just now, ntreadfile will create an IRP whose main function code is irp_mj_read (a constant in the DDK header file. The actual processing details may be different, but for the ntreadfile routine, the possible result is that the user mode caller obtains a returned value, indicating that the operation represented by this IRP has not been completed. The user mode program may continue other work and wait for the Operation to complete, or enter the waiting status immediately. Either way, the device driver processes the IRP regardless of the application.

After the driver completes an I/O operation, it calls a special kernel mode service routine to complete the IRP. The complete operation is the final action of processing the IRP, which restores the waiting application.