Locking UM buffers in IOCTL

NTFSD
1

Hi all!

I know, that for neither I/O IOCTL it is driver’s responsibility to MDL and
lock UM buffers so it will not bugcheck if Win32 process suddenly goes down
and its virtual address space is gone. The Q in my mind is in semantics of
the term “process goes down”. Since I’m issuing (synchronous) DevIoCtl in
the context of this process and driver started to handle it, there is at
least one process’s thread that is running in KM thus (as far as I
understand) the thread can’t be terminated so the process can’t be
terminated neither and its virtual address space is still “alive”. Am I
wrong? If not, why really bother (in this model) with locking neither I/O
user buffers? I guess I’m just missing something :slight_smile:

TIA,

Vladimir

P.S. Somehow this Q didn’t get any respond in NTDEV. May be it’s too obvious
:slight_smile:

2

>wrong? If not, why really bother (in this model) with locking neither I/O

user buffers? I guess I’m just missing something :slight_smile:

No, you don’t have to lock user buffer if you access buffer only in the
context of the process who owns buffer.

Alexei.

3

If he’s not going to MmProbeAndLock the memory he still needs to touch
it within an exception handler to verify that it’s legal memory. (This
is assuming the IOCTL is METHOD_NEITHER.)

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Thursday, February 20, 2003 7:19 AM
To: File Systems Developers
Subject: [ntfsd] Re: Locking UM buffers in IOCTL

>wrong? If not, why really bother (in this model) with
locking neither
>I/O user buffers? I guess I’m just missing something :slight_smile:

No, you don’t have to lock user buffer if you access buffer
only in the context of the process who owns buffer.

Alexei.

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

That is not nearly paranoid enough - if that is all you can do, I’ll give
you an application that uses two threads:

  • one that calls your driver, pointing to a region in user memory
  • another that maps and unmaps that same region of memory.

Set this up in two separate loops and eventually the call is going to get
the right window - the TEST for validity works, but the ACCESS does not.
The only truly safe way to check for valid user buffers is to use
__try/__except around access to the user buffer. If you use
MmProbeAndLockPages (or variants) you protect that and after that point it
is safe to use (since you are no longer referencing the user buffer.)

Oh, one other point - make sure you use ProbeForRead or ProbeForWrite,
because they will also ensure the address passed in to your driver is in
user mode (THAT can’t change while you are using it in your driver). While
you may think you know where user/kernel memory is located, I assure you
that your assumptions about the world do not work in IA-64, AMD-64 or even
the x86 with 4GT world.

To summarize:

__try {
ProbeForRead(…); // or ProbeForWrite
MmProbeAndLockPages(…); // or direct access to user buffer
} __except (ExceptionFilter(GetExceptionInfo())) {
// exception handler
}

You can never be too careful when it comes to dealing with anything provided
from user mode - handles, buffers, parameters, etc. Assume they are ALL
wrong and they are ALL volatile and that some hacker somewhere out there is
actively probing YOUR driver and YOUR product to figure out how to build the
next SQL slammer…

Just because you are paranoid, does not mean they are not out to get you.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Thursday, February 20, 2003 1:40 PM
To: File Systems Developers
Subject: [ntfsd] Re: Locking UM buffers in IOCTL

If he’s not going to MmProbeAndLock the memory he still needs to touch
it within an exception handler to verify that it’s legal memory. (This
is assuming the IOCTL is METHOD_NEITHER.)

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Thursday, February 20, 2003 7:19 AM
To: File Systems Developers
Subject: [ntfsd] Re: Locking UM buffers in IOCTL

>wrong? If not, why really bother (in this model) with
locking neither
>I/O user buffers? I guess I’m just missing something :slight_smile:

No, you don’t have to lock user buffer if you access buffer
only in the context of the process who owns buffer.

Alexei.

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com