Hello,
I’d like to know if it’s safe to call functions with potentially invalid handles (which would then return STATUS_INVALID_HANDLE) or if I have to make sure that these handles remain valid throughout use.
In my case, I have two threads sharing one (kernel-mode) handle.
One thread actually makes use of it and terminates itself in case of an error, while the other one (DriverUnload) only closes it as some sort of notification.
I think this implementation is unsafe, but would like to have your opinions.
Thank you.
What do you mean by ‘safe?’ If you handle any failures, then it should
be fine.
mm
xxxxx@hushmail.com wrote:
Hello,
I’d like to know if it’s safe to call functions with potentially invalid handles (which would then return STATUS_INVALID_HANDLE) or if I have to make sure that these handles remain valid throughout use.
In my case, I have two threads sharing one (kernel-mode) handle.
One thread actually makes use of it and terminates itself in case of an error, while the other one (DriverUnload) only closes it as some sort of notification.
I think this implementation is unsafe, but would like to have your opinions.
Thank you.
Allow me to clarify. I’m just talking about the part about calling a
function with an invalid handle.
mm
Martin O’Brien wrote:
What do you mean by ‘safe?’ If you handle any failures, then it should
be fine.
mm
xxxxx@hushmail.com wrote:
> Hello,
>
> I’d like to know if it’s safe to call functions with potentially
> invalid handles (which would then return STATUS_INVALID_HANDLE) or if
> I have to make sure that these handles remain valid throughout use.
>
> In my case, I have two threads sharing one (kernel-mode) handle.
> One thread actually makes use of it and terminates itself in case of
> an error, while the other one (DriverUnload) only closes it as some
> sort of notification.
>
> I think this implementation is unsafe, but would like to have your
> opinions.
>
>
> Thank you.
MM wrote:
What do you mean by ‘safe?’ If you handle any failures, then it should
be fine.
Even if said functions fail gracefully, a HANDLE is basically just an identifier.
Once the handle has been freed, the operating system could reuse the same identifier and I might end up accessing a foreign handle.
This is my main concern; I hope I was able to explain it clearly.
If I understand you correctly, I don’t see any choice but to assume that
this doesn’t happen, as I’ve never seen any evidence that it does. If
it does, this would unquestionably be an error in the kernel.
It seems to me that in your particular scenario, it could be problematic
to synchronize all of this on a SMP capable machine, as you could get in
to situations where it would be very difficult to not fall in to the
trap of assuming that there is something sort of atomic about checking
the handle for validity and acting on it, but that’s hard to say without
knowing more.
Good luck,
mm
xxxxx@hushmail.com wrote:
MM wrote:
> What do you mean by ‘safe?’ If you handle any failures, then it should
> be fine.
Even if said functions fail gracefully, a HANDLE is basically just an identifier.
Once the handle has been freed, the operating system could reuse the same identifier and I might end up accessing a foreign handle.
This is my main concern; I hope I was able to explain it clearly.
And is there some compelling reason why the thread that closes the
handle cannot also set the handle to INVALID_HANDLE_VALUE or NULL as
appropriate?
To answer your question, I would never base my design on an assumption
like ‘some random and stale handle value will always error out
correctly’. That just seems to be asking for trouble, and trouble
seems to always find its way in to where it is invited.
On Jan 18, 2008 7:49 AM, wrote:
> MM wrote:
> > What do you mean by ‘safe?’ If you handle any failures, then it should
> > be fine.
>
> Even if said functions fail gracefully, a HANDLE is basically just an identifier.
> Once the handle has been freed, the operating system could reuse the same identifier and I might end up accessing a foreign handle.
>
> This is my main concern; I hope I was able to explain it clearly.
>
>
> —
> 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
>
–
Mark Roddy
I’m still unclear on something hear: what are you particularly concerned
in this case. That is, sure, something kernel wide could potentially
have this sort of collision, but I don’t see any more evidence of that
occurring than it might if you just made up values for a handle.
mm
Martin O’Brien wrote:
If I understand you correctly, I don’t see any choice but to assume that
this doesn’t happen, as I’ve never seen any evidence that it does. If
it does, this would unquestionably be an error in the kernel.
It seems to me that in your particular scenario, it could be problematic
to synchronize all of this on a SMP capable machine, as you could get in
to situations where it would be very difficult to not fall in to the
trap of assuming that there is something sort of atomic about checking
the handle for validity and acting on it, but that’s hard to say without
knowing more.
Good luck,
mm
xxxxx@hushmail.com wrote:
> MM wrote:
>> What do you mean by ‘safe?’ If you handle any failures, then it
>> should be fine.
>
> Even if said functions fail gracefully, a HANDLE is basically just an
> identifier.
> Once the handle has been freed, the operating system could reuse the
> same identifier and I might end up accessing a foreign handle.
>
> This is my main concern; I hope I was able to explain it clearly.
Alyah,
Why do you think you need to share handles, in the first place??? You can either open separate handles to a given object, or open a single one and duplicate it for multiple callers.If you do it this way, it is a callee’s responsibility to synchronize all internal operation that accessing the target object implies…
Anton Bassov
It sounds unsafe to me.
Say you have handle value N. Your one thread closes it and knows not to use N anymore. However some other system component opening a handle to another object can now get N as their handle value because it’s been freed. So your other thread calling with handle N is now acting on a completely different object.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hushmail.com
Sent: Friday, January 18, 2008 4:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Is it safe to rely on STATUS_INVALID_HANDLE?
Hello,
I’d like to know if it’s safe to call functions with potentially invalid handles (which would then return STATUS_INVALID_HANDLE) or if I have to make sure that these handles remain valid throughout use.
In my case, I have two threads sharing one (kernel-mode) handle.
One thread actually makes use of it and terminates itself in case of an error, while the other one (DriverUnload) only closes it as some sort of notification.
I think this implementation is unsafe, but would like to have your opinions.
Thank you.
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