“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> Argh!
>
…
> >
> > Dave Taylor wrote:
> >
> > > I actually don’t know exactly what my customer is doing. I do know
> > that he is
> > > somehow invoking my IOCTL from his driver. What my driver sees is a
> > IOCTL
> > > request to DMA a frame of video from my board to a virtual address,
> > which
> > > happens to be on his board. I don’t know if his driver runs under
> > Verifier
> > > (mine does), but whatever he is doing is working for him in the
>
Mark is, as usual, 100% totally correct.
Your driver might normally run correctly under verifier, but it will NOT run
properly under verifier, OR the checked build, when passed a buffer that’s
not located in main memory if the buffer is described with an MDL built by
calling MmProbeAndLockPages. And it’s not the fault of your driver! That’s
the way NT works.
Let me re-emphasize what Mark said: We’re not talking about some esoteric
architectural, “you really shouldn’t do this, but it will work”, sort of
issue here. We’re telling you that the buffer your customer is passing to
your driver WILL eventually cause YOUR DRIVER to crash the system. It might
take a while, but it will happen.
This is one of the problems that people like your customer get into when
they try to “get clever” and map device memory back into user space. This
is almost always a mistake. As soon as they start thiking of
device-resident memory as “just a data buffer” they think they can read data
into it by calling ReadFile(…) or DeviceIoControlFile(…).
But they CAN’T. It’s outside the limits of the architecture for a whole
host of reasons (one of them being the problem that your customer was
originally facing: You have no control over the modulus with which data is
written to or read from that buffer). I don’t even want to THINK about how
many ways this would workn’t on an IA64…
Tell him to install the checked kernel and hal, enable verifier, and have a
nice day. He’ll find out that what he’s doing is hosted almost instantly.
I have potificated enough,
Peter
OSR