I think the ProcessId is bound to ULONG ‘today’ in kernel mode.
Two years ago during the port to x64, I realize that I would need to support
a 32 bit service receiving a process id from the driver, so I check whether
I would need to support a polimorfic value like the handle type in my ioctl,
or whether a easier ULONG type would be enough.
I realize that apart from Win32, Kernel mode maintains ULONG as the type for
ProcessId, and that has been not changed for x64 or ia64.
The last Ifskit help about IoGetRequestorProcessId has not been updated to
change ULONG to ULONG_PTR, but I consider this as a bug.
ULONG
IoGetRequestorProcessId(
IN PIRP Irp
);
Thanks,
mK
-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Tony Mason
Enviado el: miércoles, 20 de julio de 2005 2:00
Para: Windows File Systems Devs Interest List
Asunto: RE: [ntfsd] 64-bit issues/handles
Most likely nobody will notice this issue because the practical reality
is that you are unlikely to see a system with more than 269 million
processes and threads (roughly the number required on a 64-bit system to
need more than the low order 32 bits of the handle) - that’s a 4GB
handle table, with 16 bytes per handle (8 bytes for the object, 4 bytes
for the access mask, 4 bytes for the inevitable padding to get to the
next aligned entry).
However, imagine that someone figures out a way to exploit the layout of
handles as a “security hole” (I’m not saying it is, I’m merely trying to
establish a semi-plausible scenario in which the OS team might decide to
change the handle table management in Windows). To thwart such an
effort, they might choose to randomize the handle table so that it uses
an arbitrary offset for the table. Now suddenly the process and thread
IDs are scattered throughout the entire namespace.
A constant struggle in this business is to deal with “what works” versus
“what is supported/allowed”. The fact that something works today does
not mean that doing something in a fashion that does not match the OS
architecture is advisable.
And, of course, when someone points to Win32, I point out that the Win32
people also brought us “Explorer” - one of the most bizarre application
programs any of us in the file systems space are ever likely to see…
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Tuesday, July 19, 2005 7:34 PM
To: ntfsd redirect
Subject: Re: [ntfsd] 64-bit issues/handles
Tony Mason wrote:
My point: this is the OS function to open a process; Win32 is NOT the
OS, and if the Win32 developers decided to hard code their handle
sizes
to 32 bits, that’s their issue. Then again, I’d have to check the
Platform SDK to see if this is different for 64 bit clients.
From the platform SDK I have installed (fairly recent… possibly not
the latest, but compiles win64):
WINBASEAPI
HANDLE
WINAPI
OpenProcess(
IN DWORD dwDesiredAccess,
IN BOOL bInheritHandle,
IN DWORD dwProcessId
);
This suggestes that this function is no longer useful in Win64 (or
someone needs to LART the Platform SDK developers).
A better solution is probably to use OpenProcessToken instead.
Tony
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
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
Express yourself instantly with MSN Messenger! Download today it’s FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/