Re: User-land Callback From Driver
- From: L. Spiro <LSpiro@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 1 Jan 2008 19:43:01 -0800
I looked at the code and I could not find anything that has to do with
calling a user-mode function. I know it is there, but I could not find it.
Since this is just an OnProcessOpen/OnProcessClose callback it is acceptible
to use a method that is not the fastest.
Could I at least create the following system?
- My user-mode thread tells the driver where to put some data when a process
is opened/closed.
- My thread loops waiting for data to be put there.
- The driver puts data there when a process is opened or closed and then
waits for the data to be removed by the user-mode thread before leaving the
driver callback.
- The user-mode thread sees data (a flag set to 1), does whatever, and sets
the flag to 0 which tells the driver to continue.
Will this at least work, even if not super-responsive?
A little delay is okay but I want to handle my event entirely within the
scope of the driver callback’s start and end, so the driver needs to wait for
the user-mode to finish.
I know there is a risk that no new processes may ever be opened/closed if my
user-mode thread ever fails to pick up the event, but I have fail-safe
mechanisms planned to prevent that (the driver may consider only waiting up
to 1 second before considering the event lost and moving on).
And of course I will drop to passive-level to let my user-mode threads run.
That aside, are there any other precautions I would need to take to get it
working?
L. Spiro
"Don Burn" wrote:
Sorry, you are mucking with things that require a lot of context that you do.
not have in your driver. It will be easier in the end to use the inverred
call. There is sample code with the article I referenced, that can get you
started. There are times to take shortcuts or muck with undocumented code,
but your goals are not one of them.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"L. Spiro" <LSpiro@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C998B8F6-27A9-4D97-ADB3-B91680BDD835@xxxxxxxxxxxxxxxx
That is so huge for the little thing I wanted to do, and I can hardly find
any of the relevant code.
This is very frustrating; I was very excited about the feature I had hoped
to implement and now I will not have it even after the time I put into
making
the crappy version I made.
Sigh.
L. Spiro
"Don Burn" wrote:
Why should someone document for you an undocumented routine you have no
good
reason for calling? Sorry, the approach is bad, and the work can be done
without using undocumented functions and hacks.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"L. Spiro" <LSpiro@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E3F3B284-8EC4-4F2B-AAD0-FABF5454ADA0@xxxxxxxxxxxxxxxx
If I am violating the rules of ExAcquireRundownProtection do feel free
to
tell me how and what to correct.
As for using undocumented structure members I am not concerned because
I
have version control so that unrecognized versions of Windows will
either
dump the feature or provide the user with a way to get it running.
I guess I wasn't thinking about my spin-lock going into dispatch level.
That is the help I needed. Thank you.
L. Spiro
"Don Burn" wrote:
You should not directly call a user mode function from a driver.
Second,
you are not running at PASSIVE_LEVEL you are running at DISPATCH_LEVEL
(since you grabbed a spinlock). You are also using a couple of
undocumented routines
ExAcquireRundownProtection/ExReleaseRundownProtection
without knowing the rules about them. Finally you are using a member
of
EPROCESS a structure that changes fairly often, so relying on the
position
of any field in it is not going to work.
Sorry, but the code you have here should all be dumped. Use the
inverted
call IOCTL stuff, and forget this garbage of trying to call directly.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"L. Spiro" <LSpiro@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CA96DD4E-68DA-454B-80C4-E550E00C4296@xxxxxxxxxxxxxxxx
I have a driver function callback registered with
PsSetCreateProcessNotifyRoutine().
It works.
But I want to pass the event on to a user-mode function my
application
registers with the driver.
My application gives my driver its process ID (which the driver uses
to
get
its EPROCESS), the address of the function to call, and a user
parameter
to
pass to it.
When my driver tries to call this routine I get a blue death of
screen.
The driver is running at PASSIVE_LEVEL, and I was under the
impression
that
the driver is able to call user-land functions. Am I wrong about
this?
I use the EPROCESS of my application inside the driver callback to
go
into
the context of my application before calling its callback. Here is
my
code:
VOID ZZZ_CreateProcCallback( IN HANDLE hParentId, IN HANDLE
hProcessId,
IN
BOOLEAN bCreate ) {
KSPIN_LOCK_PARM kplpSkin;
PEPROCESS CurrentProcess, OpeningProcess;
#ifndef __USE_OLD__
KAPC_STATE pState = { 0 };
#endif
KeAcquireSpinLockByOs( &g_kslProcListSpinLock, &kplpSkin );
DbgPrint( "Process Created.\n" );
if ( g_pcCatcher.peProcess ) {
// If the process being closed is the process that has requested to
be
notified when processes open
// and close, just handle it and leave.
if ( !bCreate && g_pcCatcher.dwId == (DWORD)hProcessId ) {
DbgPrint( "The process that wants to be notified is closing.\n" );
ZZZ_UnsetProcListUserData();
}
else {
// Otherwise the notify process is still open.
// We know for sure it is safe to go there. We just hope it gave us
a
truly valid
// callback pointer or else a blue screen will result (but I always
give
a valid
// pointer so who cares)?
// Try to go there.
// Only if there is something to call.
if ( g_pcCatcher.pfCallback ) {
// Get the EPROCESS of the process being created because we need to
pass
it to the
// callback function.
// This is actually optional so do not fail if it fails.
if ( !NT_SUCCESS( PsLookupProcessByProcessId( hProcessId,
&OpeningProcess ) ) ) {
DbgPrint( "Failed to look up the EPROCESS of the target.\n" );
OpeningProcess = NULL;
}
// Prevent the notified process from closing.
if ( ExAcquireRundownProtection(
&g_pcCatcher.peProcess->RundownProtect
) ) {
DbgPrint( "Call it.\n" );
// Go into its address space (only if needed).
CurrentProcess = PsGetCurrentProcess();
if ( g_pcCatcher.peProcess != CurrentProcess ) {
EnterProcess( g_pcCatcher.peProcess );
DbgPrint( "Changed.\n" );
}
// While here, call the function it wanted us to call.
_SEH_TRY {
g_pcCatcher.pfCallback( OpeningProcess, (DWORD)hParentId,
(DWORD)hProcessId, bCreate, g_pcCatcher.dwUserParm );
}
_SEH_HANDLE {}
_SEH_END;
// GET OUT OF HERE!!
if ( g_pcCatcher.peProcess != CurrentProcess ) {
LeaveProcess();
}
// Give it back the ability to close.
ExReleaseRundownProtection(
&g_pcCatcher.peProcess->RundownProtect );
}
// If dereference the opening process if we referenced it.
if ( OpeningProcess ) { ObDereferenceObject( OpeningProcess ); }
}
}
}
KeReleaseSpinLockByOs( &g_kslProcListSpinLock, &kplpSkin );
}
It works until g_pcCatcher.pfCallback is called.
My user-mode function is just a stub for now which calls
MessageBox()
to
let
me know it worked. Hopefully this is not the actual problem.
Are there any other restrictions I should be minding in my user-mode
code,
or is it just impossible to call any user-mode code from here?
L. Spiro
- Follow-Ups:
- Re: User-land Callback From Driver
- From: Uv
- Re: User-land Callback From Driver
- From: Maxim S. Shatskih
- Re: User-land Callback From Driver
- References:
- User-land Callback From Driver
- From: L. Spiro
- Re: User-land Callback From Driver
- From: Don Burn
- Re: User-land Callback From Driver
- From: L. Spiro
- Re: User-land Callback From Driver
- From: Don Burn
- Re: User-land Callback From Driver
- From: L. Spiro
- Re: User-land Callback From Driver
- From: Don Burn
- User-land Callback From Driver
- Prev by Date: Re: turning a device into a mouse
- Next by Date: Re: Mirror Driver Installation
- Previous by thread: Re: User-land Callback From Driver
- Next by thread: Re: User-land Callback From Driver
- Index(es):
Relevant Pages
|
