C2220 & 32bit app on 64 bit driver
in [Device Drivers]
|
From: Maxim S. Shatskih on 9 Mar 2010 10:22 Another name of ULONG_PTR, as I mentioned. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com "Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message news:edC0fk5vKHA.5340(a)TK2MSFTNGP04.phx.gbl... > size_t is 64 bit in x64 build. > > "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message > news:e3O4CO5vKHA.5008(a)TK2MSFTNGP05.phx.gbl... >> another warning. Second, you state that you pass things in the form of >> ULONG_PTR which for a 32-bit process is 32 bits, but for a 64 bit driver >> is 64 bits. So I suspect that is your problem. > > Correct. > > I would never use ULONG_PTR (or size_t which is another name of it) in IOCTL > buffer. > > If the numeric value is needed - ULONG or ULONGLONG are much better, and > pointers should be used as pointers (as PVOID in the worst case). > > But, in general C/C++ code, I would use size_t whenever possible for all > sizes and pointer offsets and differences. If necessary, size_t is > downcasted to ULONG exactly near the DeviceIoControl call, and near most > Win32 or NT kernel calls (historically they do not use size_t). > > -- > Maxim S. Shatskih > Windows DDK MVP > maxim(a)storagecraft.com > http://www.storagecraft.com > >
From: Kota on 10 Mar 2010 06:44 Hi, Thanks for your inputs. I have used the "PtrToUlong" function for coverting the void * pointer to my datatype ULONG_PTR, it avoided the C2220 error and working fine. I am using the below typedef to replace void pointer in my IOCTL structures and replaced the ULONG to ULONG32 in my structures. All os my IOCTL structures variables are void * or ULONG32 size variables. So that, I am making sure that, this same structure works fine for a 64 bit driver for both 32 & 64 bit process, I also ensured that, size of structure is matching fine in both 32 & 64 bit process at driver level before handling the IOCTL in driver. #ifndef ULONG_PTR typedef ULONG32 MY_ADDR; #else typedef ULONG_PTR MY_ADDR; #endif Here ULONG_PTR is 4 bytes to hold a pointer address in 32 bit app & it is 8 bytes to hold pointer address in 64 bit app. With this, I have not used the WdfRequestIoIS32bitProcess to diffrentiate and all are working fine. Please let me know, if you see any issues in this logic. Thanks, Kota
From: Don Burn on 10 Mar 2010 08:20 ULONG_PTR is always defined for a driver so I don't see what your logic is doing. Also, PtrToUlong should only be used to convert a pointer to an integer, using it to take create a pointer is a bug. Finally, your whole interface is broken. You should avoid at all costs having a pointer in an IOCTL structure. Not only can you not make this work well because of the 32 versus 64 bit issues, the pointer opens a security hole that is hard to cover. You need a lot of checking logic to ensure the pointer is safe. Why can't you use METHOD_IN_DIRECT for this call, and pass the non-pointer part of the IOCTL in the "input buffer" and the area referred to by the pointer in the "output buffer" this is the way Windows is intended to work. Your current approach will cause crashes and security problems, Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr > -----Original Message----- > From: Kota [mailto:Kota(a)discussions.microsoft.com] > Posted At: Wednesday, March 10, 2010 6:44 AM > Posted To: microsoft.public.development.device.drivers > Conversation: C2220 & 32bit app on 64 bit driver > Subject: Re: C2220 & 32bit app on 64 bit driver > > Hi, > > Thanks for your inputs. > I have used the "PtrToUlong" function for coverting the void * pointer > to my datatype ULONG_PTR, it avoided the C2220 error and working fine. > > I am using the below typedef to replace void pointer in my IOCTL > structures and replaced the ULONG to ULONG32 in my structures. > All os my IOCTL structures variables are void * or ULONG32 size > variables. > > So that, I am making sure that, this same structure works fine for a 64 > bit driver for both 32 & 64 bit process, I also ensured that, size of > structure is matching fine in both 32 & 64 bit process at driver level > before handling the IOCTL in driver. > > #ifndef ULONG_PTR > typedef ULONG32 MY_ADDR; > #else > typedef ULONG_PTR MY_ADDR; > #endif > Here ULONG_PTR is 4 bytes to hold a pointer address in 32 bit app & it > is 8 bytes to hold pointer address in 64 bit app. > > With this, I have not used the WdfRequestIoIS32bitProcess to > diffrentiate and all are working fine. > > Please let me know, if you see any issues in this logic. > > Thanks, > Kota > > > __________ Information from ESET Smart Security, version of virus > signature database 4931 (20100310) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com >
From: Maxim S. Shatskih on 10 Mar 2010 10:44 > Here ULONG_PTR is 4 bytes to hold a pointer address in 32 bit app & it is 8 > bytes to hold pointer address in 64 bit app. This conradicts what you said above about the structure size "matching fine". It does not. If you want to simplify the driver - then replace all pointers in the structures with ULONGLONGs (8byte on all platforms), and, in 32bit apps, cast (ULONGLONG)(ULONG)Ptr. In the 32bit version of the driver, you will need to cast down. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
First
|
Prev
|
Pages: 1 2 Prev: DTM: USB-IF test certification ID check Next: Hub and Tracker the problem- use a USBtracer |