[Windows Kernel Principle and Implementation] Reading Notes (III)

Windows Kernel Object Management

The basic design intent of Windows Object Manager is:

• Provides a unified and scalable definition and control mechanism for the data structure of the execution body.
• Provides a unified security access mechanism.
• You do not need to modify the existing systemCodeTo add a new object type.
• Provides a set of standard APIs to perform various operations on objects.
• Provides a naming mechanism that is integrated with the naming mechanism of the file system.

Each object consists of two parts: the object header and Object Body. All object headers have a uniform format. The object header contains the basic information required for object management, including the object name, type, reference count, and security descriptor. In Windows, each object requires a corresponding type object (I .e., object_type object ). The types of objects defined by the system are limited. wrk supports 31 objects (built-in), each of which has a global pobject. The Type Variable points to its type object.

The wrk limit cannot exceed 48 type objects. The system global variable obpobjecttypes Array records all created type objects.

The object construction is completed in two parts: (1) Call obcreateobject to initialize the object header Based on the specified type object, and allocate the Object Body memory according to the specified size; (2) initialize the Object Body. The former can be completed in a unified manner, while the latter cannot, because various types of objects have their own initialization logic.

Type objects can trace and record all objects of this type. Because all objects are allocated and released in obpallocateobject and obpfreeobject.

The obopenobjectbyname and obreferenceobjectbyname functions of the Object Manager enable or reference objects through obplookupobjectname. The other interface function is obinsertobject, it inserts an object into a process handle table. It also uses obplookupobjectname to verify whether the object to be inserted does not exist in the global namespace.

The basic execution logic of obplookupobjectname:

• Parameter check
• If the caller specifies the rootdirectoryhandle parameter, the system uses the rootdirectory parse method to parse the object until the parsing is successful or fails, or indicates parsing from scratch.
• If the caller does not specify the rootdirectoryhandle parameter, the system starts parsing from the global root directory obprootdirectoryobject. In this case, the name of the passed object must start. If the name to be searched is only "\", special processing is performed. Otherwise, execute the following logic: (1) first determine whether the name is "\?? \ ". If yes, you need to obtain the devicemap (device table) of the current process for further query. (2) if the name is exactly "\?? ", The system returns the devicemap of the current process as the result. (3) Call the obplookupdirectoryentry function to perform step-by-step operations, or encounter an object with the parse method to parse the remaining name string or encounter a subdirectory object, in this way, you can further query the name of the next level in the subdirectory object.

If a process needs to use an object, it must be completed through a handle. In the kernel, you can use the obreferenceobjectbyhandle function to convert a handle to a corresponding object.

The object's declaration cycle is managed by the object's reference count. Once the reference count is zero, the object's declaration cycle ends, and the memory it occupies can also be recycled. The reference count of an object comes from two aspects: (1) pointer reference in the kernel; (2) a process opens an object and obtains a handle, which will then reference this object through this handle.