> Consider a system call like mmap. The fd > parameter is not accessed if MAP_ANONYMOUS > is set in flags, so it doesn't matter if it > contains junk. However valgrind complains > that > "Syscall param mmap2(fd) contains uninitialised byte(s)" It is true that Linux does not examine fd when flags has MAP_ANONYMOUS. However, *BSD insists that fd must be in the valid range of filedescriptors for the current process, or be equal to -1, regardless of flags. So memcheck has helped to make the programmer aware of this portability constraint. -- |
|
From: Duncan S. <bal...@fr...> - 2006-03-01 22:17:48
|
Hi John, > > "Syscall param mmap2(fd) contains uninitialised byte(s)" > > It is true that Linux does not examine fd when flags has MAP_ANONYMOUS. > However, *BSD insists that fd must be in the valid range of filedescriptors > for the current process, or be equal to -1, regardless of flags. thanks for the interesting information - now I know why everyone always uses -1! > So memcheck has helped to make the programmer aware of this > portability constraint. But is that the task of valgrind? Clearly valgrind is at least slightly concerned with portability, since it gives warnings for things that may be fine for the computer it is running on (eg: overlapping memcpy, with source higher up in memory than the destination; not a problem on my computer due to the memcpy implementation used, but valgrind still gives a warning), but not fine if the binary is copied to a different system. However I'd like to make the point that valgrind is presumably concerned with portability of the binary, and not of the source code (it doesn't have access to the source!). It does not make much sense for valgrind to point out a problem with a binary that could only hit on a system where the binary is incapable of running. If my binary compiled on a linux system can be copied over to a BSD system and run there, then your objection has a lot of force. Can it? (I don't know anything about BSD). Also, there are more complicated cases. For example, consider "clone" (which is the syscall I'm really interested in). There are two system calls, a two argument one and a five argument one. The five argument one has a parameter child_tidptr which is only accessed if CLONE_CHILD_SETTID or CLONE_CHILD_CLEARTID is set in flags. If you do a normal clone library call without those bits set in flags (note: there is no child_tidptr argument in the library call), then the system library calls the five parameter syscall, using junk in child_tidptr, at least on my system. The author of the program has no control over that - the program is not wrong. The library is not really wrong either. But does this call for a suppression, or for extra logic in valgrind so that it only checks child_tidptr if an appropriate bit is set in flags? All the best, Duncan. |
> However I'd like to make the point that valgrind is presumably concerned with > portability of the binary, and not of the source code (it doesn't have access > to the source!). It does not make much sense for valgrind to point out a > problem with a binary that could only hit on a system where the binary is > incapable of running. If my binary compiled on a linux system can be copied > over to a BSD system and run there, then your objection has a lot of force. > Can it? (I don't know anything about BSD). Yes it can. Many Linux x86 binary programs "just run" on *BSD x86 and on Sun Solaris x86. Both of these other systems require that the fd parameter to mmap be in range, or -1. -- |
|
From: Bryan O'S. <bo...@se...> - 2006-03-02 05:46:44
|
On Wed, 2006-03-01 at 15:12 -0800, John Reiser wrote: > Yes it can. Many Linux x86 binary programs "just run" on *BSD x86 > and on Sun Solaris x86. Both of these other systems require > that the fd parameter to mmap be in range, or -1. But do they enforce this requirement when running Linux binaries in their emulation environment? <b |
>>Yes it can. Many Linux x86 binary programs "just run" on *BSD x86 >>and on Sun Solaris x86. Both of these other systems require >>that the fd parameter to mmap be in range, or -1. > > > But do they enforce this requirement when running Linux binaries in > their emulation environment? Yes, they do. The emulatation environment is somewhat "thin"; a large portion is just table lookup to transliterate system call numbers, etc. It would be better if effort spent trying to squirm out of this situation were spent instead on avoiding it in the first place. The goal of using memcheck ought to be better software (more correct, more reliable, more robust in the face of environments that may have defects themselves), not "evading getting caught". -- |
|
From: Julian S. <js...@ac...> - 2006-03-01 23:18:57
|
> However I'd like to make the point that valgrind is presumably concerned
> with portability of the binary, and not of the source code (it doesn't have
> access to the source!). It does not make much sense for valgrind to point
> out a problem with a binary that could only hit on a system where the
> binary is incapable of running. If my binary compiled on a linux system
> can be copied over to a BSD system and run there, then your objection has a
> lot of force. Can it?
Possibly, since some of the BSDs have syscall emulation magic that allows
them to run unmodified binaries.
I guess you could make the PRE(sys_mmap2) fn in syswrap-x86-linux.c
a bit more clever, but I'm inclined to go with John's view, which
is to leave it alone, so as to force programmers to fix their mmap
calls.
clone is a bit different. I say you should fix up the logic in the
wrappers [there's one for each of four supported platforms] to take
notice of the CLONE_CHILD_{SET,CLEAR}TID. The difference is that
clone is linux-specific so there's no harm in making the wrapper
cleverer.
J
|
> Also, there are more complicated cases. For example, consider "clone" (which > is the syscall I'm really interested in). There are two system calls, a two > argument one and a five argument one. The five argument one has a parameter > child_tidptr which is only accessed if CLONE_CHILD_SETTID or CLONE_CHILD_CLEARTID > is set in flags. If you do a normal clone library call without those bits > set in flags (note: there is no child_tidptr argument in the library call), > then the system library calls the five parameter syscall, using junk in > child_tidptr, at least on my system. The author of the program has no control > over that - the program is not wrong. The library is not really wrong either. I say that the library glibc _is_ wrong. glibc "leaks garbage" into the kernel when it could avoid doing so. Because of this and other similar choices, plain glibc is not suitable for high-reliability, high-security software. I distribute patches that fix this and many other similar problems: http://BitWagon.com/glibc-audit/glibc-audit.html In particular, the modified glibc generates many fewer "read uninit" situations when run under memcheck. Memcheck has chosen to suppress many of these by default, but that takes runtime and development effort. In glibc-2.3.4 and later for linux 2.6.9 and later for x86, the lowest- level C-language call for clone() takesseven arguments. The __NR_clone system call itself takes five; the conversion pushes the function address and argument onto the stack before making the request to the kernel. -- |
|
From: Tom H. <to...@co...> - 2006-03-02 19:26:13
|
In message <200...@fr...>
Duncan Sands <bal...@fr...> wrote:
> Also, there are more complicated cases. For example, consider "clone"
> (which is the syscall I'm really interested in). There are two system
> calls, a two argument one and a five argument one. The five argument one
> has a parameter child_tidptr which is only accessed if CLONE_CHILD_SETTID
> or CLONE_CHILD_CLEARTID is set in flags. If you do a normal clone library
> call without those bits set in flags (note: there is no child_tidptr
> argument in the library call), then the system library calls the five
> parameter syscall, using junk in child_tidptr, at least on my system. The
> author of the program has no control over that - the program is not wrong.
> The library is not really wrong either. But does this call for a
> suppression, or for extra logic in valgrind so that it only checks
> child_tidptr if an appropriate bit is set in flags?
There is only one clone system call actually - it has just been given
more parameters over time and flag bits are used to determine which of
those additional parameters are valid.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|