Problems encountered when trying to cache handle (file object) in kernel mode and Their Solutions
In the implementation of the kernel-mode Log Module, considering the high overhead of frequently opening and closing user-mode log files, consider caching handle (or corresponding file object ).
Ideas:
Get handle through zwcreatefile () for the first time, use obreferenceobjectbyhandle () to obtain the corresponding file object, cache the obtained file object, and use it to directly read and write the file later.
Implementation found this method existsProblem:
If handle is disabled after the file object is obtained, the driver cannot use the file object to read and write the file in the future. The error is: "status_file_closed". It does not work if you call obreferenceobject () multiple times.
If handle is not disabled, the user State cannot open the file and an error is returned: "the file has been opened in another process."
Cause:
Search engine + wdk found that if obj_kernel_handle is specified in initializeobjectattributes (), the handle can only be accessed by any thread in the kernel state;
If this parameter is not specified, it can only be accessed in the context of the process for creating the file. The two can only take one of them, so the previous ideas won't work.
Solution:
The creation, reading, and writing of log files are all performed in the system thread, and the handle is kept intact. When the user State needs to obtain the log information, the ioctl is sent to the driver, which is read by the system thread from the log file and then sent back to the user State.
This requires that the actual file creation, reading, and writing of the log function be put in the system worker queue. In addition, the user State Program is also required. This program receives user input and converts it to IOCTL, then, output the obtained log information to the user (for example, convert the obtained information to a file ).