MmProbeAndLockPages for user buffer pointer

I have some doubts on mapping user pointers in the kernel -

Lets say I have to have a user pointer passed within a struct as
input to deviceiocontrol. I need to read stuff from this user pointer
location.


So within the driver dispatch handler I do the foll:


mdl = IoAllocateMdl(userBuf, userBufLen, FALSE, TRUE, NULL);


// Probe and lock within a try except loop


MmProbeAndLockPages(mdl, UserMode, IoReadAccess);


ASSUMING I never send the userBuf down to any other lower driver,
dpc or completion routines - can I read from userBuf pointer
directly within the dispatch handler ? .. Or do I still have
to call MmGetSystemAddressForMdlSafe and only access the
returned virtual address ?


I guess I am not entirely certain if the userBuf virtual address
is guaranteed to be valid with just doing a ProbeAndLock. Is there
any way this virtual address could become invalid ?


Also - can the contents of this userBuf be modified (say by another
"bad" thread in the calling process) while this userBuf is locked for
read in such a manner ?


TIA
--ks

Mark
Fri Dec 07 16:05:06 PST 2007

raraks@gmail.com wrote:
> I have some doubts on mapping user pointers in the kernel -
>
> Lets say I have to have a user pointer passed within a struct as
> input to deviceiocontrol. I need to read stuff from this user pointer
> location.
>
>
> So within the driver dispatch handler I do the foll:
>
>
> mdl = IoAllocateMdl(userBuf, userBufLen, FALSE, TRUE, NULL);
>
>
> // Probe and lock within a try except loop
>
>
> MmProbeAndLockPages(mdl, UserMode, IoReadAccess);
>
>
> ASSUMING I never send the userBuf down to any other lower driver,
> dpc or completion routines - can I read from userBuf pointer
> directly within the dispatch handler ? .. Or do I still have
> to call MmGetSystemAddressForMdlSafe and only access the
> returned virtual address ?
>

Assuming that you are a top level driver invoked in the calling process
context, yes you can read directly. In fact in this case you do not need
to build an MDL. See ProbeForRead in the WDK docs and samples. All
accesses should be wrapped in try/except handlers. If you are going to
use the buffer out of process context, or at raised IRQL, you need an
MDL and a system virtual address.

>
> I guess I am not entirely certain if the userBuf virtual address
> is guaranteed to be valid with just doing a ProbeAndLock. Is there
> any way this virtual address could become invalid ?
>

Not once you have successfully built an MDL for it, but see below. Also
if you do not build an MDL and just to a ProbeForRead(Write) then
certainly the process could de-allocate and invalidate that buffer.
>
> Also - can the contents of this userBuf be modified (say by another
> "bad" thread in the calling process) while this userBuf is locked for
> read in such a manner ?
>

Absolutely. Your calling process can be busily scribbling over the
contents of the buffer while you are reading or writing it. The lock
simply locks the virtual to physical mapping of the buffer, it does not
prevent access to the buffer. There is nothing you can do about that.


>
> TIA
> --ks
>
>


--

=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

raraks
Sun Dec 09 18:53:39 PST 2007

On Dec 7, 4:05 pm, Mark Roddy <ma...@hollistech.com> wrote:
> rar...@gmail.com wrote:
> > I have some doubts on mapping user pointers in the kernel -
>
> > Lets say I have to have a user pointer passed within a struct as
> > input to deviceiocontrol. I need to read stuff from this user pointer
> > location.
>
> > So within the driver dispatch handler I do the foll:
>
> > mdl = IoAllocateMdl(userBuf, userBufLen, FALSE, TRUE, NULL);
>
> > // Probe and lock within a try except loop
>
> > MmProbeAndLockPages(mdl, UserMode, IoReadAccess);
>
> > ASSUMING I never send the userBuf down to any other lower driver,
> > dpc or completion routines - can I read from userBuf pointer
> > directly within the dispatch handler ? .. Or do I still have
> > to call MmGetSystemAddressForMdlSafe and only access the
> > returned virtual address ?
>
> Assuming that you are a top level driver invoked in the calling process
> context, yes you can read directly. In fact in this case you do not need
> to build an MDL. See ProbeForRead in the WDK docs and samples. All
> accesses should be wrapped in try/except handlers. If you are going to
> use the buffer out of process context, or at raised IRQL, you need an
> MDL and a system virtual address.
>
>
>
> > I guess I am not entirely certain if the userBuf virtual address
> > is guaranteed to be valid with just doing a ProbeAndLock. Is there
> > any way this virtual address could become invalid ?
>
> Not once you have successfully built an MDL for it, but see below. Also
> if you do not build an MDL and just to a ProbeForRead(Write) then
> certainly the process could de-allocate and invalidate that buffer.
>
>
>
> > Also - can the contents of this userBuf be modified (say by another
> > "bad" thread in the calling process) while this userBuf is locked for
> > read in such a manner ?
>
> Absolutely. Your calling process can be busily scribbling over the
> contents of the buffer while you are reading or writing it. The lock
> simply locks the virtual to physical mapping of the buffer, it does not
> prevent access to the buffer. There is nothing you can do about that.
>
>
>
> > TIA
> > --ks
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows Vista/2003/XP Consulting
> Hollis Technology Solutions 603-321-1032www.hollistech.com- Hide quoted text -
>
> - Show quoted text -


Thank you for responding.
--ks