|
From: Steve G <lin...@ya...> - 2003-12-27 13:53:10
|
Hi, The new fd leakage reporting in valgrind 2.1.0 is a good addition. I have a couple of ideas that I would like to pass on. It would be nice if valgrind reported any fd > 2 when: system(), popen(), or exec() was called. This is almost always a security problem. Then there's a certain case that should get special attention. If the parent process leaks a listening descriptor, Bad Things can happen. A listening descriptor can be identified by 2 things, it is a socket and it has its address set to INADDR_ANY or IN6_IS_ADDR_UNSPECIFIED. Would this be hard to add? Does anyone else see the value of the above? -Steve Grubb __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ |
> It would be nice if valgrind reported any fd > 2 when: system(),
> popen(), or exec() was called. This is almost always a security
> problem.
gdb 5.3 uses two fds when creating a process. The program below outputs
3 4 5 6 7 8 9 10 11 12
when run from a usual login shell, but it prints
5 6 7 8 9 10 11 12 13 14
when run from gdb. So "almost always a security problem"
might not apply in this case, and the documentation/FAQ
probably should mention it. Also, there is a coding paradigm which
uses fd 3 as "cmdin" ["command in", for interactive/supervisory
input when stdin already has a data-stream input].
cmdin is to stdin as stderr is to stdout, sort of.
===== fd_next.c
#include <unistd.h>
#include <stdio.h>
main()
{
int j;
int fd[10];
pipe(&fd[0]);
pipe(&fd[2]);
pipe(&fd[4]);
pipe(&fd[6]);
pipe(&fd[8]);
for (j=0; j<10; ++j) {
printf(" %d", fd[j]);
}
printf("\n");
return 0;
}
=====
|
|
From: Robert W. <rj...@du...> - 2004-01-02 03:38:20
|
> The new fd leakage reporting in valgrind 2.1.0 is a good > addition. I have a couple of ideas that I would like to pass on. > It would be nice if valgrind reported any fd > 2 when: system(), > popen(), or exec() was called. This is almost always a security > problem.=20 Just catching this on execve should be enough here, I think. That should catch all the other cases. > Then there's a certain case that should get special attention. If > the parent process leaks a listening descriptor, Bad Things can > happen. A listening descriptor can be identified by 2 things, it > is a socket and it has its address set to INADDR_ANY or > IN6_IS_ADDR_UNSPECIFIED. I can highlight this particularly loudly. > Would this be hard to add? Does anyone else see the value of the > above? I can add this in but I'll probably make it so you have to enable it on the command-line explicitly. As John Reiser mentioned, there's probably situations where this isn't a problem and I don't want it annoying people in this case. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Steve G <lin...@ya...> - 2004-01-02 14:18:01
|
Robert, Thanks for looking into this! >Just catching this on execve should be enough here, Yes, the execve syscall is used by system & popen, so that should catch all cases. >> Then there's a certain case that should get special attention. >> If the parent process leaks a listening descriptor, > >I can highlight this particularly loudly. Actually, I think the identification is: 1) the descriptor is a socket 2) the protocol is tcp 3) address family is AF_INET or AF_INET6 4) it has its address set to INADDR_ANY or IN6_IS_ADDR_UNSPECIFIED. You can test this out by trying stunnel 3.22 or apache 2.0.x. They both leak listening descriptors. >I can add this in but I'll probably make it so you have to >enable it on the command-line explicitly. If this were enabled by default, more programmers might cleanup their programs. I don't think anyone leaks descriptors on purpose. >As John Reiser mentioned, there's probably situations where >this isn't a problem and I don't want it annoying people in >this case. People can concoct strange ways to do anything, they could pass parameters through mmap'ed address space. But they are *rarely* used. If they were used commonly, there would be a defined constant for that descriptor and you would see it mentioned in C programming books. John brings up a good point, but its rarely used. I can't think of any Open Source program I've audited that does that. Come to think of it, I definitely would want to be warned about that so I can investigate its operation completely. I would worry about the common case where 99.9% of programs operate. Anyone bending the rules or doing something clever should also be clever enough to realize that the warning can be ignored. For example, doing any programming with openssl causes a cascade of warnings to be generated. You look over the warnings to make sure they come from ssl & generate a suppression. Its not really a big deal. Ssl's use of uninitialized memory is not the common case that 99.9% of programs follow. Passing parameters on a descriptor > 2 is not a common case either. I think the identification of security & resource problems outweigh accomodating rarely utilized techniques, however clever they may be. -Steve Grubb __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 |
Steve G wrote: [snip] >>As John Reiser mentioned, there's probably situations where >>this isn't a problem and I don't want it annoying people in >>this case. > > > People can concoct strange ways to do anything, they could pass > parameters through mmap'ed address space. But they are *rarely* > used. If they were used commonly, there would be a defined > constant for that descriptor and you would see it mentioned in C > programming books. John brings up a good point, but its rarely > used. I can't think of any Open Source program I've audited that > does that. Come to think of it, I definitely would want to be > warned about that so I can investigate its operation completely. > > I would worry about the common case where 99.9% of programs > operate. Anyone bending the rules or doing something clever > should also be clever enough to realize that the warning can be > ignored. For example, doing any programming with openssl causes a > cascade of warnings to be generated. You look over the warnings > to make sure they come from ssl & generate a suppression. Its not > really a big deal. > > Ssl's use of uninitialized memory is not the common case that > 99.9% of programs follow. Passing parameters on a descriptor > 2 > is not a common case either. I think the identification of > security & resource problems outweigh accomodating rarely > utilized techniques, however clever they may be. I'm not against checking for "FD leakage," but I do want it done so that legal but uncommon usage does not get a "false positive" error report. I also do not like "false negative" reports (undiagnosed actual errors.) I have been disappointed by Valgrind/memcheck several times in these regards: scalar args to syscalls are not checked for being defined, memcheck rounds the byte array args to select() _down_ to a multiple of 8 bits while the kernel rounds them _up_ to a multiple of 32 bits, the appearance of the immediate constant 0x01010101 suppresses all errors even if the basic block is not doing optimistic memory scanning [such as strlen(), etc.], and the continuing unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3). I believe that the proposal to complain if an exec() has any open fd above 2 is too restrictive because it will give "false positive" reports in at least two cases that I know: gdb and cmdin. So, I suggest that checking fd on exec() have some other mechanism and/or policy. For instance, have a parameter for maximum fd open on exec(), with a default value of 2. I believe it is better for the astute user to set parameter values than to write error suppression rules. Another possibility would be to have a bit mask of allowed open fd in the range 0 through 31, with default value 7 (bits 0, 1, 2 set; signifying that fd 0, 1, 2 are allowed). This might be better, because in many cases it is an error if fd 0 is open: the program never reads from stdin, and something like "my_app 0<&- ..." could be done when invoking from the shell. In fact, I'd like to know if any fd is open, but the process never does I/O using that fd. There could be an optional summary of which syscalls were used for each fd, as well as which syscalls ever failed (returned -1 and set errno) per fd [as a byproduct, this includes attempting I/O on a fd that is not open.] -- |
|
From: Tom H. <th...@cy...> - 2004-01-05 22:33:25
|
In message <3FF79568.2030804@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> so that legal but uncommon usage does not get a "false positive"
> error report. I also do not like "false negative" reports (undiagnosed
> actual errors.) I have been disappointed by Valgrind/memcheck
> several times in these regards:
Problems are more likely to fixed if you report them, and I don't
recall seeing any mention of most of the things you refer to. In fact
now we have a bug tracker the best was to ensure they are known about
is to raise a bug.
> scalar args to syscalls are not
> checked for being defined,
An interesting point, and one that had crossed my mind in the past. It
ought to be doable but requires a bit of effort to work out the number
of arguments for each call and deal with varargs syscalls.
> memcheck rounds the byte array args to
> select() _down_ to a multiple of 8 bits while the kernel rounds them
> _up_ to a multiple of 32 bits,
The kernel may round up and read whole words, but I bet it doesn't pay
attention to the extra bits in the last word as that would appear to be
wrong to me. The interface that valgrind uses to check syscall args can
currently only check to byte granularity, hence it rounds down to the
nearest byte and ignores any odd bits. That is indeed a bug, but one that
is slightly finicky to fix.
> the appearance of the immediate constant
> 0x01010101 suppresses all errors even if the basic block is not doing
> optimistic memory scanning [such as strlen(), etc.],
I do remember that one being mentioned but I'm not aware that anybody
has come up with a good alternative to the current behaviour.
> and the continuing
> unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3).
There is pretty good coverage of these now I think. We certainly don't
seem to be seeing many reports of this now and the ones we do get are
usually patched fairly quickly and short of a volunteer to go through
the architecture reference manual and implement any missing instructions
it isn't clear what more could be done.
As with all free software, you get out what you put in.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
Tom Hughes wrote:
> In message <3FF79568.2030804@BitWagon.com>
> John Reiser <jreiser@BitWagon.com> wrote:
>
>
>>so that legal but uncommon usage does not get a "false positive"
>>error report. I also do not like "false negative" reports (undiagnosed
>>actual errors.) I have been disappointed by Valgrind/memcheck
>>several times in these regards:
>
>
> Problems are more likely to fixed if you report them, and I don't
> recall seeing any mention of most of the things you refer to.
The archives of Valgrind-users show these messages from me:
-----
04/29/2003 [Valgrind-users] checking the arguments to system calls?
Mentions the scalar args to syscalls (such as 3rd argument to open()
or missing trailing arguments to mmap()), and the byte arrays to
select() being rounded differently.
11/20/2003 [Valgrind-users] memcheck 2.0.0 overlooks uninit bit [false negative error report]
Memcheck gives carte blanche to a basic block that uses 0x80808080.
11/20/2003 [Valgrind-users] memcheck 2.0.0 complains about init bit [false positive error report]
Unsigned remainder has properties that memcheck does not understand.
-----
and there have been numerous messages from other users about specific
unimplemented opcodes.
> In fact now we have a bug tracker the best was to ensure they are known about
> is to raise a bug.
>
>
>> scalar args to syscalls are not
>>checked for being defined,
>
>
> An interesting point, and one that had crossed my mind in the past. It
> ought to be doable but requires a bit of effort to work out the number
> of arguments for each call and deal with varargs syscalls.
>
>
>> memcheck rounds the byte array args to
>>select() _down_ to a multiple of 8 bits while the kernel rounds them
>>_up_ to a multiple of 32 bits,
>
>
> The kernel may round up and read whole words, but I bet it doesn't pay
> attention to the extra bits in the last word as that would appear to be
> wrong to me.
The kernel certainly does pay attention to those extra bits in the
last word. In fact, the kernel pays attention so closely that it returns
EFAULT if any of those extra bits do not exist, such as if they are in
a non-mapped page. For example, a user bug may position one of the arrays for
select() so that the byte that contains the bit for highest_fd is at the high
end of the highest page in a segment, but the byte that contains the bit for
(037 | highest_fd) is in the next higher page, and therefore is not present.
The kernel acts as the user's agent in touching memory, and the kernel takes
this responsibility very seriously. Memcheck ought to be just as careful.
The same principle applies to scalar arguments to system calls. The kernel
(acting as an agent of the user) makes decisions based on the values in
those registers, so memcheck should check the values for being [un]defined.
> The interface that valgrind uses to check syscall args can
> currently only check to byte granularity, hence it rounds down to the
> nearest byte and ignores any odd bits. That is indeed a bug, but one that
> is slightly finicky to fix.
>
>
>> the appearance of the immediate constant
>>0x01010101 suppresses all errors even if the basic block is not doing
>>optimistic memory scanning [such as strlen(), etc.],
>
>
> I do remember that one being mentioned but I'm not aware that anybody
> has come up with a good alternative to the current behaviour.
Why not look at the code and figure out what it is doing? It might
become confusing or the results might be inconclusive, but there is
a large difference between "cannot understand this particular case"
and "will not even try."
>
>
>> and the continuing
>>unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3).
>
>
> There is pretty good coverage of these now I think. We certainly don't
> seem to be seeing many reports of this now and the ones we do get are
> usually patched fairly quickly and short of a volunteer to go through
> the architecture reference manual and implement any missing instructions
> it isn't clear what more could be done.
The first thing that could be done is count the number of architected
opcodes (including prefixes) that remain unimplemented. Put that number
in the user-level documentation, put the specific list and classification
of the missing cases and a suggested order of implementation in the developer
documentation, and _then_ ask for volunteers. Advertising the specifics
is much more likely to create interest than a vague "there are some
unimplemented opcodes."
>
> As with all free software, you get out what you put in.
I put in test cases, I get out bugs -- enough to demonstrate that memcheck
has a ways to go before I should rely on it to check non-test code.
--
John Reiser, jreiser@BitWagon.com
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-06 06:21:42
|
On Mon, 5 Jan 2004, John Reiser wrote:
> > As with all free software, you get out what you put in.
>
> I put in test cases, I get out bugs -- enough to demonstrate that memcheck
> has a ways to go before I should rely on it to check non-test code.
Memcheck produces false positives and false negatives. This will always
be the case, because the method it uses isn't sound or complete, and the
implementation will always have imperfections. (And I agree that the bugs
you mention, particular the lack of checking on scalar syscall arguments,
should be looked at.)
However, I don't see why one shouldn't use Memcheck on non-test code:
- If it produces false positives, as long as the number is small enough
that they don't become a distraction -- and I think experience shows
that this is true for Memcheck -- one can check them, determine their
falsehood, and suppress them.
- As for producing false negatives, the only problem I can see with this
is if someone assumes that when their programs passes Memcheck without
errors, that it is totally bug-free with respect to memory errors. I
don't imagine this is common, and it is not the case with you John --
you are clearly aware of Memcheck's shortcomings.
I can understand why you might not trust a compiler that you knew had
certain bugs -- because you are relying on blemish-free output. But
Memcheck is a different sort of program, where the output doesn't have to
be blemish-free for it to still be useful. So I don't understand why
relying on it would be a bad thing. Perhaps you could elaborate further?
N
|
Nicholas Nethercote wrote:
> On Mon, 5 Jan 2004, John Reiser wrote:
>
>
>>>As with all free software, you get out what you put in.
>>
>>I put in test cases, I get out bugs -- enough to demonstrate that memcheck
>>has a ways to go before I should rely on it to check non-test code.
>
>
> Memcheck produces false positives and false negatives. This will always
> be the case, because the method it uses isn't sound or complete,
This is a major change in stance. Originally, and for a few years, valgrind
claimed that it would complain if and only if an uninitialized bit affected
control flow or I/O. Of course, the claim _never_ was correct:
ld-linux.so.2 before LD_PRELOAD takes effect
scalar args to syscalls
floating point arithmetic
MMX (even AND and OR !)
bitwise "convolution" operations (multiplication, division, remainder)
but at least there was the pretense, and therefore some hope, that
"complain as late as possible [just before disaster]" could be relied on
in most cases. Now even the pretense is gone.
> and the
> implementation will always have imperfections. (And I agree that the bugs
> you mention, particular the lack of checking on scalar syscall arguments,
> should be looked at.)
>
> However, I don't see why one shouldn't use Memcheck on non-test code:
>
> - If it produces false positives, as long as the number is small enough
> that they don't become a distraction -- and I think experience shows
> that this is true for Memcheck -- one can check them, determine their
> falsehood, and suppress them.
>
> - As for producing false negatives, the only problem I can see with this
> is if someone assumes that when their programs passes Memcheck without
> errors, that it is totally bug-free with respect to memory errors. I
> don't imagine this is common, and it is not the case with you John --
> you are clearly aware of Memcheck's shortcomings.
>
> I can understand why you might not trust a compiler that you knew had
> certain bugs -- because you are relying on blemish-free output. But
> Memcheck is a different sort of program, where the output doesn't have to
> be blemish-free for it to still be useful. So I don't understand why
> relying on it would be a bad thing. Perhaps you could elaborate further?
The test case fanout.c shows that memcheck does not understand reconvergent
fanout: "cancelling" of uninitialized-ness. The result of any boolean AND
(x & ~x) is guaranteed to be 0, regardless of which bits are initialized
or not, yet memcheck complains from within printf(). The example further
underscores the severity of not checking scalar args to syscalls: by memcheck's
logic the return value of main() is undefined, yet memcheck does not complain
there! Even if not checking the argument to sys_exit(), everyone knows that
there _is_ an implicit read of the return value from main(); memcheck
ought to pay attention.
-----fanout.c
int g(int a, int *p)
{
return *p & ~a;
}
int f(int *p)
{
return g(*p, p);
}
main()
{
int x; /* deliberately uninitialized */
printf("%d\n", !!f(&x));
return !!f(&x);
}
/* Curious quirk: memcheck (valgrind-2.1.0) complains 5 times
as written, but 7 times when both "!!" are removed.
The values produced by the code (and their "heritage") are the same!
*/
-----end fanout.c
So, memcheck now admits that its method is neither sound nor complete.
Memcheck complains "as late as possible" for uninit bits in "easy"
operations, "as soon as possible" [maybe: integer mul/div/rem are
murky] for uninit bits in "hard" operations, and "never" for
scalar args to syscalls. There is no option to get "eager" mode
all the time (complain "as soon as possible": on any fetch from memory),
which in many cases is the information needed for the easiest debugging
and fixing.
How, then, should the programmer interpret the output from memcheck?
Supposedly any complaint should indicate an actual bug. But if
reconvergent fanout or integer "convolution" is involved, then all bets
are off, and the noise level from memcheck is quite high. Unfortunately
such operations are quite common in pattern matching and recognition
algorithms, and pattern processing is widespread: cryptanalysis, remote
sensing, image analysis, radar, sonar, vision, robotics, ...; including
stroke recognition for mouse input to a GUI.
Even when a complaint accurately determines that a bug exists, it can
quite difficult to locate and correct if it is associated with a
chain of "easy" operations, and therefore the complaint is as late
as possible. "Eager mode" should be available for all operations,
not just floating point or other "hard" operations.
More troubling are the omitted complaints (false negatives).
These include scalar args to syscalls and the internal hacks that
suppress complaints automatically in an attempt to reduce noise
from strlen (etc.) without checking that the code is a reaonsable
impostor for strlen.
All in all, that's too much hassle for me. Memcheck goes to the bottom
of my toolbox. I can check and correct more code sooner, and have more
confidence the results, using Insure++, or Purify on SPARC/Solaris.
--
|
|
From: Aghiles K. <ag...@dn...> - 2004-01-07 19:24:08
|
Hi, > All in all, that's too much hassle for me. Memcheck goes to the bottom > of my toolbox. I can check and correct more code sooner, and have more > confidence the results, using Insure++, or Purify on SPARC/Solaris. > We have been using Purify for so many years.... We are so glad to have valgrind now! Valgrind integrates so smoothly in the development environment. I am working on a 3D renderer and I must say that valgrind is *superior* to Purify in this particular case. Also, valgrind is young, I am sure that in a couple of years (months ? :>) it will be unbeatble. Aghiles www.3delight.com |
|
From: Sebastian K. <Seb...@so...> - 2004-01-08 12:28:43
|
From: "John Reiser" <jreiser@BitWagon.com>
> Nicholas Nethercote wrote:
> > On Mon, 5 Jan 2004, John Reiser wrote:
> >
> >
> >>>As with all free software, you get out what you put in.
> >>
> >>I put in test cases, I get out bugs -- enough to demonstrate that
memcheck
> >>has a ways to go before I should rely on it to check non-test code.
> >
> >
> > Memcheck produces false positives and false negatives. This will always
> > be the case, because the method it uses isn't sound or complete,
>
> This is a major change in stance. Originally, and for a few years,
valgrind
> claimed
Valgrind is a tool, Valgrind claims nothing as it has not free will to be
able to do so.
> that it would complain if and only if an uninitialized bit affected
> control flow or I/O.
Where was such claim present?
> Of course, the claim _never_ was correct:
> ld-linux.so.2 before LD_PRELOAD takes effect
It is clearly stated in the manuals. If someone does not read the manual
then it's her fault not the fault of the tool she's using.
> scalar args to syscalls
That's the only real problem (with non-academi value) presented by you in
this post.
> floating point arithmetic
It's stated in the manual as well.
> MMX (even AND and OR !)
Same.
> bitwise "convolution" operations (multiplication, division,
remainder)
Same.
> but at least there was the pretense, and therefore some hope, that
> "complain as late as possible [just before disaster]" could be relied on
> in most cases.
And thats true. One should distinguish between most and all.
> Now even the pretense is gone.
Nope.
> > and the
> > implementation will always have imperfections. (And I agree that the
bugs
> > you mention, particular the lack of checking on scalar syscall
arguments,
> > should be looked at.)
> >
> > However, I don't see why one shouldn't use Memcheck on non-test code:
> >
> > - If it produces false positives, as long as the number is small
enough
> > that they don't become a distraction -- and I think experience shows
> > that this is true for Memcheck -- one can check them, determine
their
> > falsehood, and suppress them.
> >
> > - As for producing false negatives, the only problem I can see with
this
> > is if someone assumes that when their programs passes Memcheck
without
> > errors, that it is totally bug-free with respect to memory errors.
I
> > don't imagine this is common, and it is not the case with you
John --
> > you are clearly aware of Memcheck's shortcomings.
> >
> > I can understand why you might not trust a compiler that you knew had
> > certain bugs -- because you are relying on blemish-free output. But
> > Memcheck is a different sort of program, where the output doesn't have
to
> > be blemish-free for it to still be useful. So I don't understand why
> > relying on it would be a bad thing. Perhaps you could elaborate
further?
>
> The test case fanout.c shows that memcheck does not understand
reconvergent
> fanout: "cancelling" of uninitialized-ness. The result of any boolean AND
> (x & ~x) is guaranteed to be 0, regardless of which bits are initialized
> or not, yet memcheck complains from within printf().
How often do you use such stuff in real code?
The are other values than 0 and infinity in the real world. And here
infinity (i.e. catching everything) is practically and theioretically
impossible.
> The example further
> underscores the severity of not checking scalar args to syscalls: by
memcheck's
> logic the return value of main() is undefined, yet memcheck does not
complain
> there! Even if not checking the argument to sys_exit(), everyone knows
that
> there _is_ an implicit read of the return value from main(); memcheck
> ought to pay attention.
>
> -----fanout.c
> int g(int a, int *p)
> {
> return *p & ~a;
> }
>
> int f(int *p)
> {
> return g(*p, p);
> }
>
> main()
> {
> int x; /* deliberately uninitialized */
> printf("%d\n", !!f(&x));
> return !!f(&x);
> }
> /* Curious quirk: memcheck (valgrind-2.1.0) complains 5 times
> as written, but 7 times when both "!!" are removed.
> The values produced by the code (and their "heritage") are the same!
> */
So what? probably logical negation is translated into some branching code,
and at the point of branch error is raised by memcheck.
> -----end fanout.c
>
>
> So, memcheck now admits that its method is neither sound nor complete.
It never did otherwise. It's obvious. And there is *no tool* which could
admit that.
> Memcheck complains "as late as possible" for uninit bits in "easy"
> operations, "as soon as possible" [maybe: integer mul/div/rem are
> murky] for uninit bits in "hard" operations, and "never" for
> scalar args to syscalls. There is no option to get "eager" mode
> all the time (complain "as soon as possible": on any fetch from memory),
> which in many cases is the information needed for the easiest debugging
> and fixing.
It has been beaten to death. Going such way is useless in case of such
design as memcheck (i.e. instryumentation of machine code not source code
nor just system & library calls)
> How, then, should the programmer interpret the output from memcheck?
Should use his/her own brain. Simple as that. If someone uses such bad style
she ougth pto be aware of the places she used that. Valgrind is not a tool
for general user, ity's a tool for specialists (programmers), for
specialists it's output is helpfull and meaningfull. The same way console in
control room of atomic plant is useless for a layman, but it's really
usefull & important for trained operators.
> Supposedly any complaint should indicate an actual bug.
Nope. It's enough to use some unstandard mem allocation, etc. Oneshould be
perrfectly aware of such cases.
> But if
> reconvergent fanout or integer "convolution" is involved, then all bets
> are off, and the noise level from memcheck is quite high.
You're raising academic problems. Such stuff in real code, code which does
something useful, are quite rare (and in many cases are just examples of bad
coding style). I'm not thinking about stuff made for
most-obfuscated-hacked-together-code contest.
> Unfortunately
> such operations are quite common in pattern matching and recognition
> algorithms, and pattern processing is widespread: cryptanalysis, remote
> sensing, image analysis, radar, sonar, vision, robotics, ...;
And relying on uninitialised data? I don't buy it.
Especially using such doubdfull & error prone techniques in things like
radar/sonnar/remote sensing -- often used in life critical apps.
As I daily work in area of high reliablility apps (not lifie critical, but
1-2 steps lower) and I assure you, that such shady stuff is banned here.
Besides for such things one usually uses languages significantly better than
C or C++. In such languages things like uninitialised variables and data
structure overruns are simply impossible to begin with.
In my area such stuff like you're crying about is a banned technique (as
being really bad coding style). And it could & should be avoided in every
properly coded program (with the exception of aforementioned obfuscation
contests). Thus I'm perfectly fine with Valgrid complainng about those.
> including
> stroke recognition for mouse input to a GUI.
???
> Even when a complaint accurately determines that a bug exists, it can
> quite difficult to locate and correct if it is associated with a
> chain of "easy" operations, and therefore the complaint is as late
> as possible. "Eager mode" should be available for all operations,
> not just floating point or other "hard" operations.
Eager mode would cause enormous number of false positives (those you're so
complaining about). It was describe why so many times by the authors that
there is no sense repeating that again.
> More troubling are the omitted complaints (false negatives).
> These include scalar args to syscalls and the internal hacks that
> suppress complaints automatically in an attempt to reduce noise
> from strlen (etc.) without checking that the code is a reaonsable
> impostor for strlen.
>
> All in all, that's too much hassle for me. Memcheck goes to the bottom
> of my toolbox. I can check and correct more code sooner, and have more
> confidence the results, using Insure++, or Purify on SPARC/Solaris.
If you think that those tools use exact methods then you're dreaimng, as
such methods do not exists. But if you feel better with them then fine,
Valgrind is free software, andyone is free to use or not to use it.
Every tool has it's pros and cons. Will those other (and how) handle
nonstandard libraries writtten in other languages. How those handle
nonstandard GCC extensions, inline assembly snippets etc.? It's allways a
matter of compromise (and contrary to 0-infinity world, in real world
compromises do exist)
rgds
Sebastian Kaliszewski
--
"Never underestimate the power of human stupidity" - from Notebooks of L.L.
|
|
From: Robert W. <rj...@du...> - 2004-01-06 08:28:43
|
> Why not look at the code and figure out what it is doing? It might > become confusing or the results might be inconclusive, but there is > a large difference between "cannot understand this particular case" > and "will not even try." <snip> > The first thing that could be done is count the number of architected > opcodes (including prefixes) that remain unimplemented. Put that number > in the user-level documentation, put the specific list and classification > of the missing cases and a suggested order of implementation in the devel= oper > documentation, and _then_ ask for volunteers. Advertising the specifics > is much more likely to create interest than a vague "there are some > unimplemented opcodes." John, I invite you to knock yourself out and take on these tasks if you feel so strongly about them. Most of the Valgrind developers are working long hours on non-Valgrind jobs and simply don't have the time or energy to do this. As Tom suggested, you get out what you put in.=20 This wasn't a slight, simply a statement of fact: if you want something done then you have the option of doing it yourself or waiting probably a long time for someone else to find the time to do it. > I put in test cases, I get out bugs -- enough to demonstrate that memchec= k > has a ways to go before I should rely on it to check non-test code. I'd love to see these. Do you have a pointer to them? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Sebastian K. <Seb...@so...> - 2004-01-06 10:12:25
|
From: "John Reiser" <jreiser@BitWagon.com> [snip] > 11/20/2003 [Valgrind-users] memcheck 2.0.0 complains about init bit [false positive error report] > Unsigned remainder has properties that memcheck does not understand. This one has been dismissed as splitting hairs. There are infinite number of similar cases, and barrierr must be put somewhere. [snip] > The kernel certainly does pay attention to those extra bits in the > last word. In fact, the kernel pays attention so closely that it returns > EFAULT if any of those extra bits do not exist, such as if they are in > a non-mapped page. For example, a user bug may position one of the arrays for > select() so that the byte that contains the bit for highest_fd is at the high > end of the highest page in a segment, but the byte that contains the bit for > (037 | highest_fd) is in the next higher page, and therefore is not present. This is some utterly rare case, as it requires the FD array to be misaligned to begin with. And then if there is such bug kernel itself complains. Besides: why not post patch instead of complaining? > Why not look at the code and figure out what it is doing? Who/What should look at the code and figure that? Memcheck? > It might > become confusing or the results might be inconclusive, but there is > a large difference between "cannot understand this particular case" > and "will not even try." Memcheck is a piece of software, and runtime checks must be algorithmically simple to allow reasonable speed. It doesn't understand anything, obviously as it's not thinking to begin with. > The first thing that could be done is count the number of architected > opcodes (including prefixes) that remain unimplemented. Put that number > in the user-level documentation, put the specific list and classification > of the missing cases and a suggested order of implementation in the developer > documentation, and _then_ ask for volunteers. Advertising the specifics > is much more likely to create interest than a vague "there are some > unimplemented opcodes." As you seem to be interested, why don't you try it yourself. > > As with all free software, you get out what you put in. > > I put in test cases, I get out bugs -- enough to demonstrate that memcheck > has a ways to go before I should rely on it to check non-test code. So it will never be at the state *you* could rely on it. You seem to be 0,infinity guy -- i.e. the only values interesting to you are 0,and infinity and rest you disregard as uninteresting and reduce to 0 or infinity. Valgrnd can never be exact, as this is simply intractable problem (computationally impossible at all, as is determing if particular Turing Machine will stop). If you're waiting for universal bug killer then you can wait forever. Is hunting significant number of bugs is for you the same as hunting nothing? Reduction to 0? rgds Sebastina Kaliszewski |
|
From: Nicholas N. <nj...@ca...> - 2004-01-06 16:47:27
Attachments:
unimp-SIMD
|
On Mon, 5 Jan 2004, John Reiser wrote: > >> and the continuing > >>unimplemented SSE/SSE2/3DNow! opcodes (including prefixes 0x66, 0xF2, 0xF3). > > > > > > There is pretty good coverage of these now I think. We certainly don't > > seem to be seeing many reports of this now and the ones we do get are > > usually patched fairly quickly and short of a volunteer to go through > > the architecture reference manual and implement any missing instructions > > it isn't clear what more could be done. > > The first thing that could be done is count the number of architected > opcodes (including prefixes) that remain unimplemented. Put that number > in the user-level documentation, put the specific list and classification > of the missing cases and a suggested order of implementation in the developer > documentation, and _then_ ask for volunteers. Advertising the specifics > is much more likely to create interest than a vague "there are some > unimplemented opcodes." See attachment for a list of unimplemented MMX/SSE/SSE2 opcodes. About 78% are implemented. The list may contain mistakes; the names and opcodes of these instructions can be confusing, and I wasn't as thorough as I could have been. Still, it should give a good idea of what's left. As for a suggested order of implementation, I won't pretend to know, however the fact that users haven't reported them yet indicate the ones remaining aren't used very widely. N |
> ... a list of unimplemented MMX/SSE/SSE2 opcodes. About
> 78% are implemented. ...
The explicit list is a good start at completing opcode coverage.
Looking at the list and at the function disInstr() from the source
coregrind/vg_to_ucode.c -r1.120, I must ask:
Why does the code employ copy+paste+edit so extensively, instead of
taking much more advantage of obvious schemas based on the hardware?
To the code of valgrind there is almost no difference between
ORPS and any of {ANDPS, ANDNPS, XORPS}. Yet ORPS is unimplemented,
and each of the others has its own individual paragraph of code.
All four of them could share the same paragraph by indexing a small
array with the unique opcode byte. And why not decode that byte
using a 'switch' instead of a few dozen consecutive 'if'?
These are more than just optimization hacks. Recognizing and
exploiting underlying schemas to ease coding and improve
performance is one of the hallmarks of a good implementation.
Anyway, based on the annotations in the list, I see some groups:
1) ALU function-only differences: OR/AND/XOR; MIN/MAX; etc.
2) ...DQ
3) CVT...
4) miscellaneous: CLFLUSH, ...
Exploiting such groupings may ease and speed the completion of coverage.
Completing coverage will save implementor and user time in contrast to
the disappointment and aggravation of complaints dribbling in piecemeal.
--
|
|
From: Tom H. <th...@cy...> - 2004-01-13 16:08:21
|
In message <Pin...@re...>
Nicholas Nethercote <nj...@ca...> wrote:
> See attachment for a list of unimplemented MMX/SSE/SSE2 opcodes. About
> 78% are implemented. The list may contain mistakes; the names and
> opcodes of these instructions can be confusing, and I wasn't as thorough
> as I could have been. Still, it should give a good idea of what's left.
> As for a suggested order of implementation, I won't pretend to know,
> however the fact that users haven't reported them yet indicate the ones
> remaining aren't used very widely.
I've just sent a patch to the developers list to implement all bar
about three of the missing opcodes, and to try and test the ones which
were already implemented as a few of them were broken.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
Tom Hughes wrote: > I've just sent a patch to the developers list to implement all bar > about three of the missing opcodes, and to try and test the ones which > were already implemented as a few of them were broken. Thank you. -- |
|
From: Robert W. <rj...@du...> - 2004-01-06 08:34:15
|
> I'm not against checking for "FD leakage," but I do want it done > so that legal but uncommon usage does not get a "false positive" > error report. Jeremy and I have talked about this and think that the best way to solve it is to hook the suppression of FD leakage reports into the general suppression mechanism. The other option was to add yet another command-line option, but that has the disadvantage of a) being yet another command line option on top of an already crowded set of command-line options; b) somewhat less permanent that having a suppression file for a given application; and c) less flexible to do right. I'll be working on this during the week, assuming I get some spare time for it. I'll hopefully have a patch on my web site by the end of the week: http://www.durables.org/software/valgrind/ Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Steve G <lin...@ya...> - 2004-01-06 11:04:05
|
>Jeremy and I have talked about this and think that the best >way to solve it is to hook the suppression of FD leakage >reports into the general suppression mechanism. This sounds good to me. This should be easier for people in the long road since fd leaks will have the same control mechanisms as memory leaks. Thanks, Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
|
From: Avery P. <ape...@ni...> - 2004-01-02 21:21:17
|
On Thu, Jan 01, 2004 at 07:38:14PM -0800, Robert Walsh wrote: > > The new fd leakage reporting in valgrind 2.1.0 is a good > > addition. I have a couple of ideas that I would like to pass on. > > It would be nice if valgrind reported any fd > 2 when: system(), > > popen(), or exec() was called. This is almost always a security > > problem. > > Just catching this on execve should be enough here, I think. That > should catch all the other cases. Be sure to only catch non-close-on-exec file descriptors (see fcntl(2)) in that case. If fd 3 is open but will close on execve, it's not a bug. > > Would this be hard to add? Does anyone else see the value of the > > above? > > I can add this in but I'll probably make it so you have to enable it on > the command-line explicitly. As John Reiser mentioned, there's probably > situations where this isn't a problem and I don't want it annoying > people in this case. In my opinion, valgrind should have all of its warnings enabled by default, and then the user can disable specific ones using suppressions. Otherwise every user will have to check through the list of optional things they might want, decide which they want, and "unsuppress" them, then follow the normal suppression steps anyway. This could be done in one step if there were no "unsuppressions" to worry about. If *most* programs fail on a particular warning, implementing that warning is probably not useful anyway, because nobody will usefully want to turn it on. Have fun, Avery |