Ben Laurie schrieb:
Lutz Jaenicke wrote:
Lutz Jaenicke wrote:
Peter Waltenberg wrote:
Yes, it's desirable that that data is unknown however there is a
compromise possible:
Complement the area. It'll mean valgrind will only complain at the correct
place, or possibly not
Oi. Don't do that.
Why not?
Because it's a pure pessimization whose sole purpose is to suppress a
bogus
warnings that very, very few people even see, when there's already a way to
suppress those warnings that doesn't impose costs on people who don't care
about them because they'll
problems.
Peter
David Schwartz [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
05/03/2007 09:21 AM
Please respond to
openssl-dev
To
openssl-dev@openssl.org
cc
Subject
RE: [patch] Valgrind complaining about unitialized data
Oi. Don't do that.
Why not?
Because it's a pure
Valgrind runs on unmodified binaries - and it's not always
possible to get someone else to recompile their code so that
you can find problems. OpenSSL is used in commercial products
where source isn't always available.
Valgrind *can* run on unmodified binaries, but when you do that, you get
Peter Waltenberg wrote:
Valgrind runs on unmodified binaries - and it's not always possible to
get someone else to recompile their code so that you can find problems.
OpenSSL is used in commercial products where source isn't always
available.
This does not mean the valgrind ready version
If you want to debug with OpenSSL you must compile a debugging version,
if you want to profile with OpenSSL you must compile a profiling
version, if you want to use valgrind with OpenSSL you must compile a
valgrind version, yadda, yadda.
Which is fine - IF you have access to the sources of
On Fri, Mar 02, 2007 at 10:19:31AM -0500, Richard Salz wrote:
Maybe valgrind should have a rule put in place which resets the
uninitialized data bit in the memory bitmap over the block of data
returned by the low level RAND_() functions provided by OpenSSL.
Yes, exactly my point.
Yes, it's desirable that that data is unknown however there is a
compromise possible:
Complement the area. It'll mean valgrind will only complain at the correct
place, or possibly not at all, and it's still random. The performance hit
from doing that will be so small it won't matter.
This annoyed
Peter Waltenberg wrote:
Yes, it's desirable that that data is unknown however there is a
compromise possible:
Complement the area. It'll mean valgrind will only complain at the correct
place, or possibly not at all, and it's still random. The performance hit
from doing that will be so small
Can't someone just create a valgrind suppression entry for this?
Valgrind can read a file that tells it things to ignore, like lint's old
NOTREACHED comment.
/r$
--
STSM
Senior Security Architect
DataPower SOA Appliances
Darryl Miles [EMAIL PROTECTED] writes:
[...]
So the -DPURIFY kills the only known source of uninitialized data
warnings in the OpenSSL project that has been reported todate.
There's another little one in RAND_load_file. If the function is
given a non-NULL file that doesn't exist, it still
Richard Salz wrote:
Can't someone just create a valgrind suppression entry for this?
Valgrind can read a file that tells it things to ignore, like lint's old
NOTREACHED comment.
Valgrind reports at the point of use where it considers the usage
potentially harmful.
This means you can copy
Maybe valgrind should have a rule put in place which resets the
uninitialized data bit in the memory bitmap over the block of data
returned by the low level RAND_() functions provided by OpenSSL.
Yes, exactly my point.Until someone enhances valgrind, however,
something like this
On Fri, Mar 02, 2007 at 02:06:09PM +1100, Erik de Castro Lopo wrote:
Hi all,
I'm working with version 0.9.8c distributed as part of Ubuntu but
I have also veryfied that the same problem exists with the latest
release 0.9.8e.
Please see:
Lutz Jaenicke wrote:
Lutz Jaenicke wrote:
Peter Waltenberg wrote:
Yes, it's desirable that that data is unknown however there is a
compromise possible:
Complement the area. It'll mean valgrind will only complain at the correct
place, or possibly not at all, and it's still random. The
Hi all,
I'm working with version 0.9.8c distributed as part of Ubuntu but
I have also veryfied that the same problem exists with the latest
release 0.9.8e.
The problem is that when I run my code under valgrind
http://valgrind.org/
looking for errors in my code, I get completely
Erik de Castro Lopo wrote:
So, my question is, is there any reason why Daniel Brahneborg's patch
from 2003 wasn't applied? For reference, the patch (against 0.9.8c) is
below.
Sorry, the patch was the wrong direction. The correct patch below.
Erik
diff -r -u
So, my question is, is there any reason why Daniel Brahneborg's patch
from 2003 wasn't applied? For reference, the patch (against 0.9.8c) is
below.
I assume you didn't forget to compile OpenSSL with
-DPURIFY before testing it with Valgrind, right? That
typically resolves most issues with
Brad House wrote:
I assume you didn't forget to compile OpenSSL with
-DPURIFY before testing it with Valgrind, right? That
typically resolves most issues with Valgrind and false
positives. (Purify is a commercial valgrind competitor).
I am aware of the -DPURIFY compile flag, but I do not
Erik de Castro Lopo wrote:
Brad House wrote:
I assume you didn't forget to compile OpenSSL with
-DPURIFY before testing it with Valgrind, right? That
typically resolves most issues with Valgrind and false
positives. (Purify is a commercial valgrind competitor).
I am aware of the -DPURIFY
20 matches
Mail list logo
