Hi,
When 32bit application (Wow64) calling to 64bit driver, is there a mapping method for the driver to access the memory pointer passed by the application?
Jeff
Why are you passing raw pointers to the driver? All ioctl buffer encoding types except method neither map for you.
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@gmail.com
Sent: October 11, 2010 6:31 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Memory pointer in Wow64 application
Hi,
When 32bit application (Wow64) calling to 64bit driver, is there a mapping method for the driver to access the memory pointer passed by the application?
Jeff
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars 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
Jeff,
They work as long as you are running in the context of the process that
created the pointer. Make sure that the data referenced is aligned along 8
byte boundaries. If you lock the data down with an MDL you will get a
64-bit system address.
Regards,
George.
Actually they work if you are in the context of the process and you can
trust the process including being sure that somehow someone did not mess
with the process. Doron is correct this is a really stupid idea, and a
great security hole to try to pass in pointers. They can be made to
work, but the kernel code is significant, and many people do not get it
right.
Unless, the driver was dumb enough to directly export the interface
(i.e. have a lot of client programs that know they can pass in pointers
in buffers), the best thing to do is change the interface to not pass
the pointers in buffers, but instead use one of the IOCTL METHOD’s that
handle the pointer for you.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“George M. Garner Jr.” wrote in message
news:xxxxx@ntdev:
> Jeff,
>
> They work as long as you are running in the context of the process that
> created the pointer. Make sure that the data referenced is aligned along 8
> byte boundaries. If you lock the data down with an MDL you will get a
> 64-bit system address.
>
> Regards,
>
> George.
On Monday 11 October 2010 16:03:55 Don Burn wrote:
Unless, the driver was dumb enough to directly export the interface
(i.e. have a lot of client programs that know they can pass in pointers
in buffers), the best thing to do is change the interface to not pass
the pointers in buffers, but instead use one of the IOCTL METHOD’s that
handle the pointer for you.
Would it be valid to use a structure with embedded pointers when doing
scatter-gather IO? Or would it generally be better for the DLL which
interfaces to the driver deal with sending each buffer into the driver
sequentially?
–
Bruce Cran
Don,
Anything that is passed in from user mode is untrustworthy. Wow64 pointers
are neither more nor less untrustworthy than pointers passed from native
applications. And, in any event, Wow64 pointers *are* 64-bit pointers by
the time that you see them in the kernel. If you know how to handle a user
mode buffer safely (and understand potential alignment issues) you can
handle a Wow64 application buffer safely. There are indeed a lot of unsafe
drivers out there. Thanks to KMCS there are a lot of unsafe signed drivers
out there. But I don’t think that you can attribute this fact to Wow64.
Regards,
George.
“Bruce Cran” wrote in message news:xxxxx@ntdev:
> On Monday 11 October 2010 16:03:55 Don Burn wrote:
>
> > Unless, the driver was dumb enough to directly export the interface
> > (i.e. have a lot of client programs that know they can pass in pointers
> > in buffers), the best thing to do is change the interface to not pass
> > the pointers in buffers, but instead use one of the IOCTL METHOD’s that
> > handle the pointer for you.
>
> Would it be valid to use a structure with embedded pointers when doing
> scatter-gather IO? Or would it generally be better for the DLL which
> interfaces to the driver deal with sending each buffer into the driver
> sequentially?
>
The answer to the above is it depends. How fast is the device, how big
are the buffers, etc? If may turn out that you may want the DLL to be
smart and consolidate some requests and pass others as individual, or
even bite the bullet and pass the pointers in a structure and accept the
cost of getting it right in the kernel.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
No I am not attributing it to WOW64, I attribute the problem to the fact
that way too many people pass pointers in buffers to drivers (or use
METHOD_NEITHER), when there was no need to if they had designed the
interface properly. WOW64 is just another complication (i.e. handling
two size structures, and potentially having to determine on the fly
whether the caller is 32 or 64 bit).
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“George M. Garner Jr.” wrote in message
news:xxxxx@ntdev:
> Don,
>
> Anything that is passed in from user mode is untrustworthy. Wow64 pointers
> are neither more nor less untrustworthy than pointers passed from native
> applications. And, in any event, Wow64 pointers are 64-bit pointers by
> the time that you see them in the kernel. If you know how to handle a user
> mode buffer safely (and understand potential alignment issues) you can
> handle a Wow64 application buffer safely. There are indeed a lot of unsafe
> drivers out there. Thanks to KMCS there are a lot of unsafe signed drivers
> out there. But I don’t think that you can attribute this fact to Wow64.
>
> Regards,
>
> George.
Bruce Cran wrote:
Would it be valid to use a structure with embedded pointers when doing
scatter-gather IO? Or would it generally be better for the DLL which
interfaces to the driver deal with sending each buffer into the driver
sequentially?
The fact that it is scatter/gather is really irrelevant.
Each of those buffers will have to be page-locked into memory so you can
get a physical address. The question is really “who should be doing the
page locking.” If you pass a set of pointers, then your driver is
responsible for mapping and locking the pointers, and doing all of the
error checking that is required (since the user-mode buffer might change
at any time). But if you pass a series of METHOD_IN_DIRECT ioctls, then
the I/O subsystem will do that for you.
Both ways will work, but I always prefer to use code that someone else
has tested and debugged rather than starting over.
OK, that’s not true. I’d prefer to write it myself, but in a case like
this, I’ll use the API.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> When 32bit application (Wow64) calling to 64bit driver, is there a mapping method for the driver to
access the memory pointer passed by the application?
Just expand the pointer with 32 upper bits of zeroes.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Not to me. To ME, the question is “who should we trust to do the pointer validations” – Let’s see… we could trust the Windows code that’s been tested for eons, or we could trust the driver code written by some guy. Hmmm… let me think…
I’m not sure anybody in this thread has come close to answering the OPs question. Of course, I’m not sure what the OP is asking, so I can’t answer him either. OP: WHAT pointer are you talking about?
Peter
OSR
You trust the OS?
Regards,
George.
George M. Garner Jr. wrote:
You trust the OS?
The I/O manager code has handled quadrillions of IRPs since its
introduction in 3.1. I trust it one hell of a lot more than the code I
threw together four weeks ago that has run a few thousand IRPs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes… I’ve had the chance to examine the code for most executive- and kernel-level functions in detail over a period of years, and I know the people who wrote most it.
So, yes, absolutely: I definitely trust the OS more than I trust, say, code written by some anonymous random dude I’ve never met or even heard of on a mailing list.
You DON’T trust the OS? How strange…
Peter
OSR
>Just expand the pointer with 32 upper bits of zeroes.
Shouldn’t the API take care of this (DeviceIoControl in this case), Like how it happens in general cases (createfile etc)?
An application running with 32 bit stacks calls an API which will pass its params to system service. When Ntdll will come, it saves 32 bit stack context, restore 64 bit stack and pass the call with 64 bit params copy.
Does DeviceIoControl is an exception?
Thanks
Aditya
>You DON’T trust the OS? How strange…
Actually, I don’t know what is so “strange” here - after all, the whole AV/PF/FW/etc industry is based upon this lack of trust in built-in Windows security and upon the (obviously naive) assumption that some third-party software is able to perform more reliable checks…
Anton Bassov
No, DeviceIoControl is not an exception. IF the user uses a method other than METHOD_NEITHER for their IOCTLs, and IF the pointer is passed as the pointer to the InBuffer or OutBuffer then the problem is taken care of for you by the OS.
Other than that, there are issues.
This thread, like so many on this list, has wandered into weird uncharted territory and the original point of the thread – which was unclear at least to me – has been lost.
Peter
OSR
The pointer that is passed in to DeviceIoControl will be expanded to
32-bits. But any embedded pointers will not be expanded. A good practice,
assuming that you need to pass an embedded pointer, is to exand the pointer
to 64-bits (e.g. cast to a ULONGLONG) when you define your structure that
will be passed in to the driver. That way the structure will align the same
way on both x86 and x64 systems. MS has a best practices document somewhere
that discusses 64-bit/Wow64 migration issues, or at least they did 11 or 12
years ago when I looked at all this. Hopefully someone knows what the link
to it is now-a-days.
Regards,
George.
>>>Just expand the pointer with 32 upper bits of zeroes.
Shouldn’t the API take care of this (DeviceIoControl in this case), Like how it happens in general
cases (createfile etc)?
For the pointer inside the IOCTL input buffer structure? how the API can handle this?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> Actually, I don’t know what is so “strange” here - after all, the whole AV/PF/FW/etc industry is based
upon this lack of trust in built-in Windows security and upon the (obviously naive) assumption
Mainly this protects about the user’s stupidity on answering Yes to security dialogs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com