OBJ_KERNEL_HANDLE and PsCreateSystemThread

28 Aug, 21

Hello, what does OBJ_KERNEL_HANDLE do exactly? Does it simply mean that if the handle is created in a non system process context, it cannot be accessed
by usermode code? Or are there other implications as well (.e.g for the registry key DDIs does it guarantee that the handle would be in the system process table, or is it simply the current process handle table)?

For PsCreateSystemThread, the DDK states that:

Drivers for Windows 2000 and Windows 98/Me must only call PsCreateSystemThread from the system process context

Why? Won't a NULL process pointer guarantee that the thread will be created in the system process? Or is it that the DDI cannot work properly in non system process
context? Is there another reason?

1 Comment

28 Aug, 21

OBJ_KERNEL_HANDLE places the handle in the system process's handle table rather than in that of the current process. It also sets the high bit in the handle to indicate to other OB functions that the handle should be looked up in the system process table rather than that of the current process.

WDM DDIs that act on handles often take an "AccessMode" parameter. Among many things this changes, one is whether the function will accept a kernel-handle. If the AccessMode is user-mode and you provide a kernel handle you'll get STATUS_INVALID_HANDLE since a user-mode process should never hand you a kernel handle. If it's kernel-mode and you provide a kernel handle then it will go through just fine. Routines that don't take an AccessMode parameter generally look at the thread's PreviousMode to determine if the handle can be used.

I'm not sure on the reasoning for the PsCreateSystemThread documentation you cite, but I suspect you're right on. It probably assumed that it was running in the context of the system process and opened a security hole if run outside that process by creating the thread handle in the process it was called from.