FS drivers and AMD64

NTFSD
1

All:

I’m looking for some documentation on AMD64 bit issues in file system
filter drivers. In porting our NT kernel drivers to AMD64 the MSDN link
was helpful, but doesn’t seem to address the file system driver world.
BTW, I’m pretty new to file system drivers so ignore any ignorant
statements!

Do any of you know where I can find material (or have the material at
hand)?

Specifically, I’m concerned with doing stuff like manipulating user
buffers which come in as a 32bit pointer in a 64bit environment.

Thanks,

Daniel

2

There’s a “thunking” layer in 64-bit Windows called “WOW64” (“Windows on
Windows 64”) which handles i/o requests from 32-bit apps and converts all
pointers in them to 64 bit values (and vice versa, on return). Thus kernel
mode drivers will see only 64-bit pointers.

  • Dale.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]
Sent: Wednesday, September 15, 2004 10:36 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FS drivers and AMD64

All:

I’m looking for some documentation on AMD64 bit issues in file system filter
drivers. In porting our NT kernel drivers to AMD64 the MSDN link was
helpful, but doesn’t seem to address the file system driver world. BTW, I’m
pretty new to file system drivers so ignore any ignorant statements!

Do any of you know where I can find material (or have the material at hand)?

Specifically, I’m concerned with doing stuff like manipulating user buffers
which come in as a 32bit pointer in a 64bit environment.

Thanks,

Daniel

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Nemiroff, Daniel wrote:

Specifically, I’m concerned with doing stuff like manipulating user
buffers which come in as a 32bit pointer in a 64bit environment.

Hmmmmm… The 32-bit pointers that are in I/O system data structures
(like IRPs) or that are passed in to you (like via Fast I/O entry
points) are thunked for you, so that’s just not an issue.

The only thing you have to worry about are data structures that have
embedded 32-bit pointers in the buffer. In that case, you can determine
if the call is coming from a 32-bit caller with IoIs32bitProcess(…).

Or, perhaps there’s some subtlety that I’m missing???

Peter
OSR

4

Peter,

Your understanding is correct. There are some operations (ioctls for
example) where the data structures are different between 32bit and 64bit
applications. Your filter would need to use the IoIs32bitProcess API to
determine which form of the structure to use.

A good example of this is the FSCTL_MARK_HANDLE operation. If you look
in ntifs.h you will see two structure definitions for this:
MARK_HANDLE_INFO and MARK_HANDLE_INFO32. The problem occurred because
this FSCTL contained a HANDLE which is 64bits in 64bit environments.

To eliminate this issue in the future it is best to not define
operations which contain imbedded handles or pointer.

Below is a sample of how NTFS handles this situation for
FSCTL_MARK_HANDLE. IoIs32bityProcess only exists on 64bit OS’s which is
why you need the below conditional compilation.

#if defined(_WIN64)

//
// Win32/64 thunking code
//

if (IoIs32bitProcess( Irp )) {

PMARK_HANDLE_INFO32 MarkHandle32;

if (IrpSp->Parameters.FileSystemControl.InputBufferLength <
sizeof( MARK_HANDLE_INFO32 )) {
…
return STATUS_BUFFER_TOO_SMALL;
}

MarkHandle32 = (PMARK_HANDLE_INFO32)
Irp->AssociatedIrp.SystemBuffer;
LocalMarkHandleInfo.HandleInfo = MarkHandle32->HandleInfo;
LocalMarkHandleInfo.UsnSourceInfo = MarkHandle32->UsnSourceInfo;
LocalMarkHandleInfo.VolumeHandle = (HANDLE)(ULONG_PTR)(LONG)
MarkHandle32->VolumeHandle;

HandleInfo = &LocalMarkHandleInfo;

} else {

#endif

//
// Get the input buffer pointer and check its length.
//

if (IrpSp->Parameters.FileSystemControl.InputBufferLength <
sizeof( MARK_HANDLE_INFO )) {

…
return STATUS_BUFFER_TOO_SMALL;
}

HandleInfo = (PMARK_HANDLE_INFO)
Irp->AssociatedIrp.SystemBuffer;

#if defined(_WIN64)
}
#endif

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PeterGV
Sent: Wednesday, September 15, 2004 3:53 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FS drivers and AMD64

Nemiroff, Daniel wrote:

Specifically, I’m concerned with doing stuff like manipulating user
buffers which come in as a 32bit pointer in a 64bit environment.

Hmmmmm… The 32-bit pointers that are in I/O system data structures
(like IRPs) or that are passed in to you (like via Fast I/O entry
points) are thunked for you, so that’s just not an issue.

The only thing you have to worry about are data structures that have
embedded 32-bit pointers in the buffer. In that case, you can determine

if the call is coming from a 32-bit caller with IoIs32bitProcess(…).

Or, perhaps there’s some subtlety that I’m missing???

Peter
OSR

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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