I want to specify a thread in a user mode call to a kernel mode driver, via DeviceIoControl(). It doesn’t appear that in the driver, either a user mode thread handle or thread ID have any meaning, rather threads are pointers to some _KTHREAD in the system.
So how can my driver identify the thread that the user’s parameter is referring to?
ObReferenceObjectByHandle() is your friend. It will validate the handle type, allow you to check access rights and convert a handle into the appropriate kernel pointer for you.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-369735-
xxxxx@lists.osr.com] On Behalf Of xxxxx@pdsys.biz
Sent: Friday, June 12, 2009 2:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How can a user mode program identify a thread to a kernel
driver?I want to specify a thread in a user mode call to a kernel mode driver, via
DeviceIoControl(). It doesn’t appear that in the driver, either a user mode
thread handle or thread ID have any meaning, rather threads are pointers to
some _KTHREAD in the system.So how can my driver identify the thread that the user’s parameter is
referring to?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks, Peter. Looks like a very useful function to call.
I also since noticed the PsGetCurrentThreadId function. As it happens, all
I want to do is know if the current thread context for the ISR is the same
as one specified by an earlier IOCTL call. I have a sort of profiler, so I
want to collect information only when the target thread is currently running
at the time of the interrupt. The user can specify the thread ID of the
desired thread, and my driver doesn’t actually need to translate that to a
PKTHREAD.
Just to be sure, can you verify that user mode and kernel mode use the same
thread IDs for the same threads?
Also does a “handle” for a kernel object have the same value in user mode
and kernel mode?
> Just to be sure, can you verify that user mode and kernel mode use the same thread IDs for
the same threads?
What do you think yourself??? it would just defeat the very purpose of uniquely identifying the thread if the same thread could have different TIDs at the different stages of its lifetime, don’t you think…
Also does a “handle” for a kernel object have the same value in user mode and kernel mode?
Well, the question in a form that it has been presented does not seem to make sense, taking into account that the same description may be referred to by multiple descriptors. Therefore, you are, apparently, asking whether UM handles are usable by the kernel-mode code, and vice versa.
Kernel-mode code can use UM handle, but only in context of a process that opened it (which may be done by both KM and UM code). Furthermore, if KM code opens a handle for UM access UM code will be able to use this handle (which will refer to the description in an object table of a calling process and have it most significant bit off).
If KM code wants to be able to use a handle in context of any process it will open a handle for kernel-mode access. Such handle will have its most significant bit on, and it will refer to the description in a process table of a “System” process, rather than that of a calling one…
Anton Bassov
Thanks, Anton. This is helpful. I didn’t realize that handles were only
unique in a specific process context.
My driver’s DispatchControl is called (it is a highest level driver) in the
context of the calling user thread, so if I get passed a handle, I can
interpret that in the context of the current process. If I want the driver
to know about a handle in some other process, then it has to be told what
process the handle belongs to. CMIIW.
A related question:
What about thread IDs? Are they unique within the system, and are thread
IDs usable between user and kernel?
Thread IDs are globally unique but can be easily reused so they are usually not that valuable for tracking a thread that you have no control over
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Michael Rolle
Sent: Saturday, June 13, 2009 3:26 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] How can a user mode program identify a thread to a kernel driver?
Thanks, Anton. This is helpful. I didn’t realize that handles were only
unique in a specific process context.
My driver’s DispatchControl is called (it is a highest level driver) in the
context of the calling user thread, so if I get passed a handle, I can
interpret that in the context of the current process. If I want the driver
to know about a handle in some other process, then it has to be told what
process the handle belongs to. CMIIW.
A related question:
What about thread IDs? Are they unique within the system, and are thread
IDs usable between user and kernel?
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thread IDs are the same between user-mode and kernel-mode. Thread IDs are not a good way to track a particular thread, however, as the thread can be terminated and if that happens it’s possible (I don’t know for sure) that the thread ID could be reused.
There may be many handles to an object. Handles are just indexes into the handle table for the current process (or into the system handle table if they are created with the OBJ_KERNEL_HANDLE flag specified). A handle from a user-mode process will be valid in kernel-mode as long as you use/reference it within the context of that process. A handle from the system handle table cannot be used in user-mode but can be used from kernel-mode in any process context.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Rolle
Sent: Friday, June 12, 2009 11:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How can a user mode program identify a thread to a kernel driver?
Thanks, Peter. Looks like a very useful function to call.
I also since noticed the PsGetCurrentThreadId function. As it happens, all I want to do is know if the current thread context for the ISR is the same as one specified by an earlier IOCTL call. I have a sort of profiler, so I want to collect information only when the target thread is currently running at the time of the interrupt. The user can specify the thread ID of the desired thread, and my driver doesn’t actually need to translate that to a PKTHREAD.
Just to be sure, can you verify that user mode and kernel mode use the same thread IDs for the same threads?
Also does a “handle” for a kernel object have the same value in user mode and kernel mode?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
To further expand on what Doron said, a thread / process id is only guaranteed to remain unique while that thread or process has a reference outstanding (i.e. it’s the current thread, or you have opened a handle or other reference to it).
This means that you can’t, in the general case, reliably hang on to a thread id for general use in, say, comparisons unless you also “hold the door open” by holding a reference of some sort to it.
-----Original Message-----
From: Doron Holan
Sent: Saturday, June 13, 2009 16:55
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How can a user mode program identify a thread to a kernel driver?
Thread IDs are globally unique but can be easily reused so they are usually not that valuable for tracking a thread that you have no control over
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Michael Rolle
Sent: Saturday, June 13, 2009 3:26 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] How can a user mode program identify a thread to a kernel driver?
Thanks, Anton. This is helpful. I didn’t realize that handles were only
unique in a specific process context.
My driver’s DispatchControl is called (it is a highest level driver) in the
context of the calling user thread, so if I get passed a handle, I can
interpret that in the context of the current process. If I want the driver
to know about a handle in some other process, then it has to be told what
process the handle belongs to. CMIIW.
A related question:
What about thread IDs? Are they unique within the system, and are thread
IDs usable between user and kernel?
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Peter and Skywing:
FYI, or anyone else reading this… I’ve got the Windows Internals book (4th
edition). It says that process and thread IDs do get reused after the
process or thread terminates. Process and thread IDs never collide.
By “holding the door open”, I think you mean to hold a reference to the
thread handle, which wouldn’t keep the thread from terminating, but it
*might* keep the thread ID from being reused until the handle disappears
from the object manager.
I concur that tracking a thread is better done in the driver by holding a
handle to the thread (actually I guess it’s a counted reference to the
internal thread object, via the ObReference… function). That’s a clean
and reliable technique.
Thanks for your contributions.
Thread and process IDs are tied to the lifetime of their respective OB objects, and not their termination state. Their respective CID IDs are released when the last reference to the PETHREAD/PEPROCESS goes away and rundown for that object happens and not immediately when the object is terminated.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Rolle
Sent: Sunday, June 14, 2009 8:27 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] How can a user mode program identify a thread to a kernel driver?
Peter and Skywing:
FYI, or anyone else reading this… I’ve got the Windows Internals book (4th
edition). It says that process and thread IDs do get reused after the
process or thread terminates. Process and thread IDs never collide.
By “holding the door open”, I think you mean to hold a reference to the
thread handle, which wouldn’t keep the thread from terminating, but it
*might* keep the thread ID from being reused until the handle disappears
from the object manager.
I concur that tracking a thread is better done in the driver by holding a
handle to the thread (actually I guess it’s a counted reference to the
internal thread object, via the ObReference… function). That’s a clean
and reliable technique.
Thanks for your contributions.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer