Introduction to Windows kernel objects

The kernel object is only a memory block allocated by the operating system kernel and can only be accessed by the operating system kernel. The memory block is a data structure, and its members are responsible for maintaining various information about the object. Windows provides a set of functions to create and operate kernel objects. When you call a function that creates a kernel object, the function returns a handle that identifies the kernel object, which can be called by all threads in the current process. You can also share the kernel object across process boundaries for other processes to call.

 

Usage count. The kernel object has a count data member that identifies the number of processes that use the kernel object. In most cases, the kernel object is used only by the process that creates it. When the process exits, the Count of kernel objects will be reduced by one. If the Count of kernel objects is 0, the kernel object will be automatically destroyed. If the kernel object is used by multiple processes, its lifecycle may be longer than the process that created it. As long as the usage count of the kernel object is not 0, it will not be destroyed. When the current process exits, as long as other processes use this kernel object, it will not be destroyed. However, we do not need to worry about memory leakage caused by kernel objects. Even if the process does not manually close the kernel objects, the process will check its own handle table when exiting, if there are kernel objects used in the handle table, the operating system will close these handles for us. The Count of kernel objects referenced by these handles will be reduced by one. If the count is 0, the kernel object is automatically destroyed. As we can see from the above, the kernel object is not bound to the process that created it. The process that created it exits, and the kernel object may still survive. The operation owner of the kernel object is the operating system, instead of processes.

 

Kernel Object Security. The kernel object can be protected by a security descriptor, which describes who is the owner of the object, whether the group and user can access or use the objects, and whether the objects can be inherited. The security_attributes struct is used for security description. Its structure is as follows:

Typedef struct _ security_attributes {

DWORD nlength; // The length of the struct.

Lpvoid lpsecuritydescriptor; // point to a Security Descriptor

Bool binherithandle; // indicates that the kernel object is inherited by the quilt process.

} Security_attributes;

To identify whether an object is a kernel object, you can check whether the security_attributes parameter in the parameters for creating the object function. Some are kernel objects, but none are kernel objects. With this structure, the kernel object is protected, and other objects cannot be accessed at will, and the memory structure cannot be broken.

 

Process kernel object handle table. When a process is initialized, the system assigns a handle table to it. This handle table is only used by kernel objects and is not applicable to user objects and GDI objects. The structure of the handle table generally includes:

1: Index

2: pointer to the memory block of the kernel object

3: Access mask

4: Flag

When a process is initialized for the first time, its handle table is empty, that is, the process does not reference any kernel objects. When a thread in the process calls a function to create a kernel object, the kernel will allocate and initialize a memory block for this kernel object, and then the kernel will scan the handle table to find a blank record item, the pointer member points to the memory address of the newly created kernel object, and the access mask is set to have full access permissions. If this kernel object can be inherited, the flag Member is set to 1, if it cannot be inherited, It is 0. When you call closehandle, the corresponding record items in the handle table of the process that references the kernel object will be cleared, when a process exits, all records in the handle table will be cleared, and the count of all used kernel objects will be reduced by one. The kernel objects whose count is 0 will be automatically destroyed. Even if the kernel object is not manually closed, the kernel object will not be exposed when the process exits. When a kernel object is not referenced by any process, it will be automatically destroyed.

 

Sharing kernel objects across process boundaries. In many cases, you need to share kernel objects in different processes, such as semaphores, mutex volumes, and events, to allow synchronous execution of threads in different processes. In this case, you need to share kernel objects. There are three ways to share kernel objects:

1: Use the kernel object handle to inherit

2: Name the object

3: copy the object handle

1: Use the kernel object handle to inherit. The kernel object handle can be used for inheritance only when there is a parent-child relationship between processes. If an object process allows its child processes to inherit its handle, binherithandle, a member of the security_attributes parameter of the function that creates the kernel object, must be set to true when it creates an inherited kernel object, in this way, when a parent process creates a child process, the child process will copy the handle table of the parent process that can be inherited to its own handle table. Each process has its own handle table. The parent process and the child process are not shared handle tables. Therefore, after the child process is created, when a parent process creates a kernel object that can be inherited, only the process cannot access this kernel object because it does not know the existence of this kernel object, of course, the parent process does not know when a child process creates its own kernel object. Because Microsoft does not write moreCodeTo copy the inherited handles to the corresponding handle table. Therefore, the kernel object does not really inherit, but inherits the handle of the kernel object. That is to say, the handle is only a pointer to the kernel object, not a member of the kernel object.

We can use the sethandleinformation function to indicate whether the kernel object can be inherited by a quilt process. If there is a kernel object that can be inherited by a quilt process, but you do not want a process to inherit, mark this kernel object as non-inherited before creating this child process. When creating a child process, then, when the sethandleinformation function is called, the kernel object is marked as inherited. Other child processes to be created can share the kernel object.

Sethandleinformation (

_ In handle hobject, // handle of the kernel object

_ In DWORD dwmask, // tell the function which or which flag it wants to change

_ In DWORD dwflags // whether it can be inherited

);

 

2: Name an object. Many functions that create a kernel object have an lpname parameter that specifies the name of the kernel object, such as the following two functions:

Createmutexa (

Lpsecurity_attributes lpmutexattributes,

Bool binitialowner,

Lpstr lpname

);

 

Createeventw (

Lpsecurity_attributes lpeventattributes,

Bool bmanualreset,

Bool binitialstate,

Lpwstr lpname

);

 

The value of the last parameter lpname is the name of the kernel object. If null is input for this parameter, the kernel object is not named. The following code creates a mutex kernel object named CTH.

Handle mutexprocessa = createmutex (null, false, text ("CTH "));

Another process B also wants to create a mutex kernel object. The Code is as follows:

Handle mutexprocessb = createmutex (null, false, text ("CTH "));

The kernel does not immediately create a mutex kernel object. Instead, it first checks whether there is a mutex two kernel object named CTH. If yes, it checks whether there is permission. If yes, the existing mutex handle will be copied to process B's handle table, and the mutex handle will be returned to mutexprocessb. If there is no object named CTH, of course, it is to create one, if another type of kernel object named CTH exists, the creation fails and the function returns NULL. In other words, the kernel object belongs to the operating system and has little to do with which process to create it. In this way, it is easy to share the kernel object.

 

3: copy the object handle. Use the duplicatehandle function.

Duplicatehandle (

Handle hsourceprocesshandle,

Handle hsourcehandle,

Handle htargetprocesshandle,

Lphandle lptargethandle,

DWORD dwdesiredaccess,

Bool binherithandle,

DWORD dwoptions

);

This function obtains a record item in a process handle table, creates a copy of the record item in the handle table of another process, and then another process can access this kernel object.

Author:Chen taihan

Blog:Http://www.cnblogs.com/hlxs/