> Hello. What does OBJ_KERNEL_HANDLE do exactly?
First of all, it creates a handle which principally cannot be accessed from
user mode. Even if the handle value is passed to any user-mode code - it will
be defunct for it.
On the other hand, OBJ_KERNEL_HANDLE leaves its trace in the value of the
created handle (IIRC some junior bit is set) and so this handle can be used in
the kernel mode code in ANY process context. This “any process context while in
kernel mode” is second good property of the kernel handle.
Yes, the System process’s handle table is used to generate this handle, and
this “junior bit set” directs ObReferenceObjectByHandle, ZwClose and other
handle-using routines from other process context to use the System’s handle
table, and not the current process’s one.
The pseudocode for ObReferenceObjectByHandle internals:
if( (ULONG_PTR)Handle & KERNEL_HANDLE_JUNIOR_BIT )
{
if( RequestorMode != KernelMode )
return STATUS_ACCESS_DENIED;
HandleTable = PspSystemProcess->HandleTable;
}
else
HandleTable = PsGetCurrentProcess()->HandleTable;
// Then index HandleTable by Handle and check DesiredAccess
// Then check the object type if asked for
// Then addref the object and return it
Possibly the “KERNEL_HANDLE_JUNIOR_BIT” is documented somewhere. I just do not
remember.
This is a security measure. This handle belongs to something really secure and
important for your driver, and you do not want any user process to use this
handle by accident (or intent) by guessing (or scanning for) the handle value.
Be careful. OBJ_KERNEL_HANDLE (the bit 0x400) is a no-op on NT4. In some
scenarios I had, this leads to closing the raw input thread’s keyboard handle
instead :-). A very funny bug.
On NT4, use ExQueueWorkItem and ZwCreatexxx in this work item to do the same as
OBJ_KERNEL_HANDLE does. Same must be done on any access to this handle and on
close.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com