Hi folks,
first of all im new at OSR so sorry if im missleading myself posting on wrong sections and im actually learning on the kernel space an english isnt my main language.
Here is my problem;
Im creating an event on the user land with my app and sending the handle to my driver with IOCTL and in there im using ObReferenceObjectByHandle.
PKEVENT pEV = NULL;
ObReferenceObjectByHandle(hEvent->hEvent, EVENT_MODIFY_STATE, *ExEventObjectType, hEvent->Type, &pEV, NULL);
Since im creating the handle on user the hEvent->Type is equal to Usermode
sometimes it returns STATUS_INVALID_HANDLE randomly.
Also im using ObDereferenceObject to the pkevent and ObCloseHandle to close the handle.
Any help will be appreciated.
Thanks in advance.
Are you using kmdf? My guess is that when it works you are processing the io request in the context of the calling process while when it doesn’t you are in a different context
On Sun, Jul 31, 2016 at 12:04 AM -0700, “xxxxx@gmail.com” > wrote:
Hi folks, first of all im new at OSR so sorry if im missleading myself posting on wrong sections and im actually learning on the kernel space an english isnt my main language. Here is my problem; Im creating an event on the user land with my app and sending the handle to my driver with IOCTL and in there im using ObReferenceObjectByHandle. PKEVENT pEV = NULL; ObReferenceObjectByHandle(hEvent->hEvent, EVENT_MODIFY_STATE, *ExEventObjectType, hEvent->Type, &pEV, NULL); Since im creating the handle on user the hEvent->Type is equal to Usermode
sometimes it returns STATUS_INVALID_HANDLE randomly. Also im using ObDereferenceObject to the pkevent and ObCloseHandle to close the handle. Any help will be appreciated. Thanks in advance.
Starting with Windows 7, if AccessMode is KernelMode and handle is received from user address space, Driver Verifier issues bugcheck C4, subcode F6.
Now, a handle is valid only in the “context” of the process it belongs to (for ObReferenceObjectByHandle) because the target process is not specified. So you should ensure that the call is being done in the correct context.
The context depends on how the IRP is processed (queued or not), if your driver is a top level driver or not, etc…
Maybe isnt the best approach but i just went through the process of creating a named event and still just sending the handle to the driver but instead ive created a event notification.
It works like a charm, anyways ill try to understand why im on a different context sometimes it the otherway
I was not making any judgment on this approach. It is actually an interesting method to notify a user application that something happened. Just do it well because your driver may not pass the Driver Verifier’s tests otherwise. That’s what the documentation states.
Why don’t you use the UserMode or KernelMode constant for the KPROCESSOR_MODE typed variable ?
I did set to UserMode constant as ive stated in the first post however thanks for ur hint ill double check my ioctl logic anyways.
Some times the size of my structure isnt the same on my Kernel driver as my user app so i should start in there.
Does the Driver Verifier’s warning mean that Microsoft’s engineers are not happy with this technic (passing user-mode handles to kernel) ?
Thank to the OP for this post. It shows that passing user-mode handles to kernel is difficult. Drivers have no guarantee that they run in the context of the issuing user-mode application. Even a highest level driver can be filtered and the filter could use it’s own managed queue. If the queue is processed in a work-item or system worker thread, the now (filtered) intermediate driver would run in the context of the system process.
The OS offers a nice solution to the OP’s problem called “Asynchronous I/O”. Using an OVERLAPPED structure, the user can have an event being fired by the OS when an I/O operation has completed. This way, the driver does not need to deal with handles and contexts, it just completes the request when needed and the OS fires the event so the application can be notified. This way, the event’s handle is only visible to the user.
In the extented versions of ReadFile and WriteFile, the user can have a user routine be invoked by the OS when the I/O operation has completed. This is called an APC.
So I suggest the OP should have a look to the Inverted Call Model to learn how to deal with " manual queues" in KMDF. Working with pending I/O requests sometimes implies cancelling some of these requests too.
The Verifier check makes sure that you don’t ObReferenceObjectByHandle a
user mode handle with a requestor mode of KernelMode. Doing so bypasses the
security check on the translation from user handle to object, which is not
what you want.
Does the Driver Verifier’s warning mean that Microsoft’s engineers are not
happy with this technic (passing user-mode handles to kernel) ?
Thank to the OP for this post. It shows that passing user-mode handles to
kernel is difficult. Drivers have no guarantee that they run in the context
of the issuing user-mode application. Even a highest level driver can be
filtered and the filter could use it’s own managed queue. If the queue is
processed in a work-item or system worker thread, the now (filtered)
intermediate driver would run in the context of the system process.
The OS offers a nice solution to the OP’s problem called “Asynchronous
I/O”. Using an OVERLAPPED structure, the user can have an event being fired
by the OS when an I/O operation has completed. This way, the driver does not
need to deal with handles and contexts, it just completes the request when
needed and the OS fires the event so the application can be notified. This
way, the event’s handle is only visible to the user.
In the extented versions of ReadFile and WriteFile, the user can have a user
routine be invoked by the OS when the I/O operation has completed. This is
called an APC.
So I suggest the OP should have a look to the Inverted Call Model to learn
how to deal with " manual queues" in KMDF. Working with pending I/O requests
sometimes implies cancelling some of these requests too.