Simple IRP question

[Guest]

Archived from groups: microsoft.public.windowsxp.device_driver.dev (More info?)

Hey, folks.
I'm working on a research project on transparent device driver isolation at
the University of Washington, and I have a question about IRP handling
that's probably pretty simple. I've been wondering, under any circumstances
is it permissible to send an IRP off again with IoCallDriver after having
reclaimed it in a completion routine, when you yourself did not create the
IRP but rather received it through a dispatch routine from someone else? In
other words, can you do ping pong without ponging all the way back to the
top?
I'm pretty much indifferent to the answer itself, but I need to know for my
IRP state machine if it should be a permitted operation or whether a driver
screwing around enough to make it work is asking for a system crash... It's
an interesting fine line to dance, trying to figure out what sorts of dubous
behavior can be smoothed over and let pass, and what sorts of behavior are
too dangerous to allow. I haven't really figured much out in that realm yet.


Thanks a lot.
--Micah Brodsky

 

[Guest]

Archived from groups: microsoft.public.windowsxp.device_driver.dev (More info?)

First, you haven't reclaimed it. The IRP has been passed to you so you have
a chance to do something before the IRP really is completed. An IRP received
in a completion routine is on it's way to IRP heaven. All you can do is
delay that. Sending it anywhere using IoCallDriver is begging for a system
failure since as soon as you return, it could very well be completed.

Why would you want to do that?

--
Gary G. Little
Seagate Technology LLC

"Micah Brodsky yahoo com>" <eightyfiv <atdot> wrote in message
news:ejDBqzFfEHA.704@TK2MSFTNGP09.phx.gbl...
> Hey, folks.
> I'm working on a research project on transparent device driver isolation
at
> the University of Washington, and I have a question about IRP handling
> that's probably pretty simple. I've been wondering, under any
circumstances
> is it permissible to send an IRP off again with IoCallDriver after having
> reclaimed it in a completion routine, when you yourself did not create the
> IRP but rather received it through a dispatch routine from someone else?
In
> other words, can you do ping pong without ponging all the way back to the
> top?
> I'm pretty much indifferent to the answer itself, but I need to know for
my
> IRP state machine if it should be a permitted operation or whether a
driver
> screwing around enough to make it work is asking for a system crash...
It's
> an interesting fine line to dance, trying to figure out what sorts of
dubous
> behavior can be smoothed over and let pass, and what sorts of behavior are
> too dangerous to allow. I haven't really figured much out in that realm
yet.
>
>
> Thanks a lot.
> --Micah Brodsky
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.device_driver.dev (More info?)

I personally wouldn't want to, but I'd like to know if there's any
imaginable reason why someone might do so. What I'm doing is interposing on
all the calls in and out of an arbitrary driver, doing validations and
tracking allocations and such, somewhat like the Driver Verifier but with
different goals.
What I meant by reclaim was returning STATUS_MORE_PROCESSING_REQUIRED from
the completion routine. (And I should also hope that the driver was kind
enough to make sure that its dispatch routine returned or will return
STATUS_PENDING.)

Of course, no matter what I choose here, the question of specification vs.
implementation still looms large. Any driver that achieves some important
bit of functionality by mutilating the spec but not breaking the way
Microsoft coded it up will be very difficult for me to handle. For example,
I could imagine a driver, having "reclaimed" an IRP as above, zeroing out
all the stack locations past the current location, setting up new
parameters, and doing an IoCallDriver. Unless I'm prepared to handle that
sort of mischief, I'll end up preventing the driver from doing what it was
coded to do.
What I would like to discover is that most drivers are reasonably
well-behaved with regard to the spec, they just occasionally have mistakes
because of a developer's oversight or lack of knoweldge, mistakes which
could be bulletproofed against. My fear is that far too many drivers will
have overt violations of the spec, whether intentional or committed through
ignorance, that work but are weird in unanticipated (and unanticipatable)
ways.

Thanks a lot.
--Micah Brodsky

"Gary G. Little" <gary.g.little.nospam@seagate.com> wrote in message
news:vkKRc.3688$0x5.410@newssvr24.news.prodigy.com...
> First, you haven't reclaimed it. The IRP has been passed to you so you
have
> a chance to do something before the IRP really is completed. An IRP
received
> in a completion routine is on it's way to IRP heaven. All you can do is
> delay that. Sending it anywhere using IoCallDriver is begging for a system
> failure since as soon as you return, it could very well be completed.
>
> Why would you want to do that?
>
> --
> Gary G. Little
> Seagate Technology LLC
>
> "Micah Brodsky yahoo com>" <eightyfiv <atdot> wrote in message
> news:ejDBqzFfEHA.704@TK2MSFTNGP09.phx.gbl...
> > Hey, folks.
> > I'm working on a research project on transparent device driver isolation
> at
> > the University of Washington, and I have a question about IRP handling
> > that's probably pretty simple. I've been wondering, under any
> circumstances
> > is it permissible to send an IRP off again with IoCallDriver after
having
> > reclaimed it in a completion routine, when you yourself did not create
the
> > IRP but rather received it through a dispatch routine from someone else?
> In
> > other words, can you do ping pong without ponging all the way back to
the
> > top?
> > I'm pretty much indifferent to the answer itself, but I need to know for
> my
> > IRP state machine if it should be a permitted operation or whether a
> driver
> > screwing around enough to make it work is asking for a system crash...
> It's
> > an interesting fine line to dance, trying to figure out what sorts of
> dubous
> > behavior can be smoothed over and let pass, and what sorts of behavior
are
> > too dangerous to allow. I haven't really figured much out in that realm
> yet.
> >
> >
> > Thanks a lot.
> > --Micah Brodsky
> >
> >
>
>