IRP_MJ_WRITE dispatch and Irp->UserBuffer

Neil_Weicher · November 9, 2009, 5:03pm

I’m 99% sure I know the answer to this but I’d just like confirmation (or
disabusement):

In a legacy FSFD, the Dispatch Routine for IRP_MJ_WRITE is always executed
in the context of the calling process, correct?

I.e., I don’t need to Probe-n-Lock Irp->UserBuffer if I am only going to
access it in the Dispatch routine?

Thanks.

Ayush_Gupta-2 · November 9, 2009, 5:43pm

You can’t assume that. It depends on whether it is a paging i/o or not and
whether some intermediate filter driver has pended it or not.
You should first look for the MDL and if not found then only use the
Irp->UserBuffer and that too ONLY if you are not going to pend it for later
use, otherwise, you need to probe and lock and then pend for later use.

Regards,
Ayush Gupta
AI Consulting

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Tuesday, November 10, 2009 3:33 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] IRP_MJ_WRITE dispatch and Irp->UserBuffer

I’m 99% sure I know the answer to this but I’d just like confirmation (or
disabusement):

In a legacy FSFD, the Dispatch Routine for IRP_MJ_WRITE is always executed
in the context of the calling process, correct?

I.e., I don’t need to Probe-n-Lock Irp->UserBuffer if I am only going to
access it in the Dispatch routine?

Thanks.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Neil_Weicher · November 9, 2009, 5:49pm

Right - sorry - I meant if there is no MDL and I am not going to pend it for
later use and it is not paging I/O.

However, it is true that I would not know if another intermediate filter
driver has pended it. But even if that were the case, wouldn’t the
Irp->UserBuffer still be good during my (unpended) Dispatch routine?

Thanks.

“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
> You can’t assume that. It depends on whether it is a paging i/o or not and
> whether some intermediate filter driver has pended it or not.
> You should first look for the MDL and if not found then only use the
> Irp->UserBuffer and that too ONLY if you are not going to pend it for
> later
> use, otherwise, you need to probe and lock and then pend for later use.
>
> Regards,
> Ayush Gupta
> AI Consulting
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
> Sent: Tuesday, November 10, 2009 3:33 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] IRP_MJ_WRITE dispatch and Irp->UserBuffer
>
> I’m 99% sure I know the answer to this but I’d just like confirmation (or
> disabusement):
>
> In a legacy FSFD, the Dispatch Routine for IRP_MJ_WRITE is always executed
> in the context of the calling process, correct?
>
> I.e., I don’t need to Probe-n-Lock Irp->UserBuffer if I am only going to
> access it in the Dispatch routine?
>
> Thanks.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

OSR_Community_User · November 9, 2009, 7:27pm

Hi Neil,

I’m not sure I understand the question. If a filter pends an operation, it is very likely that the process context in which the operation resumes is not the original context, which means any user pointers are invalid.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

Bronislav_Gabrhelik · November 10, 2009, 7:21am

The creation of MDL for IRP is controlled by flags in device. The legacy FSF which attaches to the device should delegate these flags, so IO manager behaves consistently - as it was requested by (lower) FS device. If FSF wants to pend IRP it should create and lock MDL for user buffer to allow lower devices to access buffer. It must be done in process context of requestor. FSF has to avoid MDL leaks. It can either set flag in the IRP so I/O manager unlocks and frees MDL automatically during IRP completion (small hack), or register completion routine and unlock and free MDL there.

Irp->UserBuffer still be good during my (unpended) Dispatch routine
I don’t understand. Pend means that you don’t delegate call to the dispatch routine of lower device in current thread context, but you delegate action into worker thread and return STATUS_PENDING. So how can lower filter access USER MODE virtual address from different process context? It simply cannot access virtual addres. It cannot allocate MDL.

Bronislav Gabrhelik

Scott_Noone_OSR · November 10, 2009, 10:39am

> However, it is true that I would not know if another intermediate filter

driver has pended it. But even if that were the case, wouldn’t the
Irp->UserBuffer still be good during my (unpended) Dispatch routine?

If another filter above you pends the request then they had better make sure
they get back into the correct process context before hucking the IRP down
to the lower levels.

Also, even though you didn’t specifically ask, if you’re going to mess with
Irp->UserBuffer make sure that you take all of the necessary security
precautions necessary for METHOD_NEITHER processing (try/except,
ProbeForRead, etc).

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Neil Weicher” wrote in message news:xxxxx@ntfsd…
> Right - sorry - I meant if there is no MDL and I am not going to pend it
> for later use and it is not paging I/O.
>
> However, it is true that I would not know if another intermediate filter
> driver has pended it. But even if that were the case, wouldn’t the
> Irp->UserBuffer still be good during my (unpended) Dispatch routine?
>
> Thanks.
>
> “Ayush Gupta” wrote in message news:xxxxx@ntfsd…
>> You can’t assume that. It depends on whether it is a paging i/o or not
>> and
>> whether some intermediate filter driver has pended it or not.
>> You should first look for the MDL and if not found then only use the
>> Irp->UserBuffer and that too ONLY if you are not going to pend it for
>> later
>> use, otherwise, you need to probe and lock and then pend for later use.
>>
>> Regards,
>> Ayush Gupta
>> AI Consulting
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
>> Sent: Tuesday, November 10, 2009 3:33 AM
>> To: Windows File Systems Devs Interest List
>> Subject: [ntfsd] IRP_MJ_WRITE dispatch and Irp->UserBuffer
>>
>> I’m 99% sure I know the answer to this but I’d just like confirmation (or
>> disabusement):
>>
>> In a legacy FSFD, the Dispatch Routine for IRP_MJ_WRITE is always
>> executed
>> in the context of the calling process, correct?
>>
>> I.e., I don’t need to Probe-n-Lock Irp->UserBuffer if I am only going to
>> access it in the Dispatch routine?
>>
>> Thanks.
>>
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>
>
>

Neil_Weicher · November 10, 2009, 11:26am

This is what I have been doing during the IRP_MJ_WRITE in my legacy
encryption FSFD (IF Irp->MdlAddress is NULL):

Allocate an MDL for Irp->UserBuffer
Probe-n-lock it, get system address, etc etc all within try/except
Grab a TargetBuffer encryption buffer from NonPagedPool
Allocate an MDL for the TargetBuffer
Farm off to a Kernel Thread which encrypts locked UserBuffer into
TargetBuffer
Wait for completion
Set Irp->UserBuffer to TargetBuffer
Set Irp->MdlAddress to TargetBufferMdl
Complete Write
In Completion routine put back original Irp->UserBuffer
Free TargetBuffer MDL and buffer

I know it is very old-school. However, if I do everything within the
Dispatch Routine (without farming off to a Kernel Thread) do I need to
allocate MDL and Probe-n-lock Irp->UserBuffer, or can I just reference
Irp->UserBuffer directly throughout the whole Dispatch routine?

Thanks.

“Scott Noone” wrote in message news:xxxxx@ntfsd…
>> However, it is true that I would not know if another intermediate filter
>> driver has pended it. But even if that were the case, wouldn’t the
>> Irp->UserBuffer still be good during my (unpended) Dispatch routine?
>
> If another filter above you pends the request then they had better make
> sure they get back into the correct process context before hucking the IRP
> down to the lower levels.
>
> Also, even though you didn’t specifically ask, if you’re going to mess
> with Irp->UserBuffer make sure that you take all of the necessary security
> precautions necessary for METHOD_NEITHER processing (try/except,
> ProbeForRead, etc).
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Neil Weicher” wrote in message news:xxxxx@ntfsd…
>> Right - sorry - I meant if there is no MDL and I am not going to pend it
>> for later use and it is not paging I/O.
>>
>> However, it is true that I would not know if another intermediate filter
>> driver has pended it. But even if that were the case, wouldn’t the
>> Irp->UserBuffer still be good during my (unpended) Dispatch routine?
>>
>> Thanks.
>>
>> “Ayush Gupta” wrote in message news:xxxxx@ntfsd…
>>> You can’t assume that. It depends on whether it is a paging i/o or not
>>> and
>>> whether some intermediate filter driver has pended it or not.
>>> You should first look for the MDL and if not found then only use the
>>> Irp->UserBuffer and that too ONLY if you are not going to pend it for
>>> later
>>> use, otherwise, you need to probe and lock and then pend for later use.
>>>
>>> Regards,
>>> Ayush Gupta
>>> AI Consulting
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
>>> Sent: Tuesday, November 10, 2009 3:33 AM
>>> To: Windows File Systems Devs Interest List
>>> Subject: [ntfsd] IRP_MJ_WRITE dispatch and Irp->UserBuffer
>>>
>>> I’m 99% sure I know the answer to this but I’d just like confirmation
>>> (or
>>> disabusement):
>>>
>>> In a legacy FSFD, the Dispatch Routine for IRP_MJ_WRITE is always
>>> executed
>>> in the context of the calling process, correct?
>>>
>>> I.e., I don’t need to Probe-n-Lock Irp->UserBuffer if I am only going to
>>> access it in the Dispatch routine?
>>>
>>> Thanks.
>>>
>>>
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> For our schedule of debugging and file system seminars
>>> (including our new fs mini-filter seminar) visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>>
>>
>>
>>
>
>
>

Bronislav_Gabrhelik · November 10, 2009, 4:39pm

> - Wait for completion
Do you really degrade potentially asynchronous write to synchronous? If you set up completion routine there is no reason to wait for completion in Dispatch routine.

do I need to
allocate MDL and Probe-n-lock Irp->UserBuffer, or can I just reference
Irp->UserBuffer directly throughout the whole Dispatch routine?
It seems to me that you don’t have to. In case of write, you don’t need to dereference UserBuffer in completion routine, so that’s special case. If some filter above you call your filter in system context without MDL it is not your fault. Probing of user buffer is missing and it might contain an invalid address, so it must be handled properly while encrypting.

Bronislav Gabrhelik