|
From: KJK::Hyperion <no...@li...> - 2004-03-01 23:39:28
|
At 20.37 01/03/2004, Chris January wrote:
>>My name is Rajesh and I am a student of Computer Sci in India. I want to
>>write a valgrind like utility for Windows. I know I sound silly but How
>>do I start? I am sorry if I am bothering u guys
>Ithink your main work will be in re-writing vg_mylibc.c and vg_syscalls.c.
>vg_mylibc.c is ok to re-write but for vg_syscalls.c you need to know all
>the Windows syscalls, what parameters they take, etc.
I've been thinking about Valgrind on Windows for a long time, and here's
the major stumbling blocks I've found:
- absolutely, completely forget full virtualization, i.e. loading the
target program in the same process as Valgrind. kernel32.dll, user32.dll
and gdi32.dll can only be loaded *once per process* and *at their default
base address*, and it's very impractical to write Valgrind tools without
using Win32 functions. In detail:
- kernel32.dll:
- once per process because once loaded it connects through LRPC to
the Win32 subsystem (winsrv.dll, running in the context of CSRSS). The
connection needs to be done because the subsystem won't accept calls from
unknown clients, and subsystem calls include the whole console API -
definitely something we want to support. And the connection can only be
done once per process because the process and thread ids are sent to the
subsystem at each call, and the subsystem not only keeps track of them
internally, but requires them to be valid process and thread ids, since it
will open them to perform operations. All of this is microkernel-era crap
that today is otherwise completely irrelevant, but we're stuck with it
- at the default base address to make CreateRemoteThread work.
CreateRemoteThread is used, among others, to signal processes attached to a
console that a control event (for example a Control-C) has been received
- user32.dll, gdi32.dll:
- once per process for reasons similar to kernel32.dll
- at the default base address for reasons you really don't want to
know. It has to do with the fact that the windowing system was ported from
Windows 95, where not only user32.dll and gdi32.dll were actually loaded at
the same address in all processes, but they were also loaded in *shared memory*
- liberal use of shared memory. It isn't uncommon for several processes
to share memory even with kernel mode code
- inter-process modifications. Nicholas told me this is going to be one
of the worst issues, as Valgrind currently assumes that near to no
interaction between unrelated processes is possible. On the other hand,
this kind of interactions is almost commonplace in Windows. Most can be
checked, as they happen at well-defined times (like passing buffers outside
the port section in LRPC calls), while others (like handle duplication) are
asyncronous and unpredictable. Some (like thread context changes) could
outright break Valgrind, altough they're hopefully rarely used
- I/O control operations. These are intrinsically problematic, and the
fact that many common IOCTLs (like the AFD IOCTLs, the default
implementation of TCP/IP for Winsock) aren't documented doesn't help a bit
>I have no idea what system calls are contained in the second table but i
>have seen some calls documented somewhere.
a crude listing of NtUserXxx and NtGdiXxx system calls can be obtained from
the debugging symbols of win32k.sys. Note that some NtUserXxx functions are
multiplexers, actually implementing several different calls each, and that
some others have unusual effects on the calling process (like mapping
several shared memory views) that can confuse Valgrind. Finally, an awful
lot of user32 functions aren't system calls, but they read into memory
shared with the kernel-mode windowing system (window and menu handles
aren't really handles, but decorated offsets into a table stored in said
shared memory). A strange example of such calls is GetWindowRect, which,
reading 64 bits at once, should be prone to race conditions on 32 bit
machines - and it indeed *is* vulnerable! One wonders how can such a f***ed
up windowing system work so well in practice
>I am willing to help you if you want.
count me in too, even if I think that nothing short of a full fork of
Valgrind will do
|