Re: Re: [patch] Valgrind complaining about unitialized data
How to compile a debugging version openssl? -邮件原件- 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 代表 Peter Waltenberg 发送时间: 2007年3月3日 11:29 收件人: openssl-dev@openssl.org 主题: [金山毒霸识别此邮件为垃圾邮件]Re: [patch] Valgrind complaining about unitialized data >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 the code that uses OpenSSL. Im my case we supply libraries that customers integrate with other code - often other 3rd party code. If this decreased security, or had any real performance impact, I'd understand the objections - but that doesn't appear to be the case. >Would I be correct in saying that OpenSSL uses the implied randomness of >the data on the stack to add randomness to the result. By virute of >using uninitialized data as a source of randomness it is this that is >causing the problem (then it gets used by the app and one or more bytes >find their way into what valgrind believes is dangerous usage and >therefore a warning gets emitted) ? Yes, but it isn't very random anyway. Just uninitialized. i.e. it may have the same value every time the program starts. In reality it isn't a major problem for me, since I solved this years ago, but I can still remember how annoying it was at the time. And since IBM isn't the only comemercial user of OpenSSL you may want to consider not drowning one of the better debug tools available in spam every time OpenSSL is in the process. Peter Darryl Miles To Sent by: openssl-dev@openssl.org owner-openssl-dev cc @openssl.org Subject Re: [patch] Valgrind complaining 05/03/07 03:51 PM about unitialized data Please respond to openssl-dev 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 of a library is the same version as a general purpose optimized that you might use in a production environment. If you need to use valgrind then you must accept that you need to be in the position to audit ALL of the code that makes up your application to play nice with valgrind. It is not the OpenSSL project's place to make your commercial product development work best for you in your environment. 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. I think you take the valgrind marketing feature "Valgrind runs on unmodified binaries" far too literally. You have to also account for the flaws in how valgrind is implemented, some people could argue that valgrind should have a rule to cater for this exact problem just like it already does for many quirks of popular libc implemtations and system calls. But it doesn't at this time and I accept that and I accept that -DPURFY is fine for me. I would not be against any fix which has no performance impact and given its this one little line I'd also like to hear the case for why things should be left as they are. Would I be correct in saying that OpenSSL uses the implied randomness of the data on the stack to add randomness to the result. By virute of using uninitialized data as a source of randomness it is this that is causing the problem (then it gets used by the app and one or more bytes find their way into what valgrind believes is dangerous usage and therefore a warning gets emitted) ? Darryl __ OpenSSL Project http://www.ope
Re: [patch] Valgrind complaining about unitialized data
>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 the code that uses OpenSSL. Im my case we supply libraries that customers integrate with other code - often other 3rd party code. If this decreased security, or had any real performance impact, I'd understand the objections - but that doesn't appear to be the case. >Would I be correct in saying that OpenSSL uses the implied randomness of >the data on the stack to add randomness to the result. By virute of >using uninitialized data as a source of randomness it is this that is >causing the problem (then it gets used by the app and one or more bytes >find their way into what valgrind believes is dangerous usage and >therefore a warning gets emitted) ? Yes, but it isn't very random anyway. Just uninitialized. i.e. it may have the same value every time the program starts. In reality it isn't a major problem for me, since I solved this years ago, but I can still remember how annoying it was at the time. And since IBM isn't the only comemercial user of OpenSSL you may want to consider not drowning one of the better debug tools available in spam every time OpenSSL is in the process. Peter Darryl Miles To Sent by: openssl-dev@openssl.org owner-openssl-dev cc @openssl.org Subject Re: [patch] Valgrind complaining 05/03/07 03:51 PM about unitialized data Please respond to openssl-dev 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 of a library is the same version as a general purpose optimized that you might use in a production environment. If you need to use valgrind then you must accept that you need to be in the position to audit ALL of the code that makes up your application to play nice with valgrind. It is not the OpenSSL project's place to make your commercial product development work best for you in your environment. 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. I think you take the valgrind marketing feature "Valgrind runs on unmodified binaries" far too literally. You have to also account for the flaws in how valgrind is implemented, some people could argue that valgrind should have a rule to cater for this exact problem just like it already does for many quirks of popular libc implemtations and system calls. But it doesn't at this time and I accept that and I accept that -DPURFY is fine for me. I would not be against any fix which has no performance impact and given its this one little line I'd also like to hear the case for why things should be left as they are. Would I be correct in saying that OpenSSL uses the implied randomness of the data on the stack to add randomness to the result. By virute of using uninitialized data as a source of randomness it is this that is causing the problem (then it gets used by the app and one or more bytes find their way into what valgrind believes is dangerous usage and therefore a warning gets emitted) ? Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automate
Re: [patch] Valgrind complaining about unitialized data
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 of a library is the same version as a general purpose optimized that you might use in a production environment. If you need to use valgrind then you must accept that you need to be in the position to audit ALL of the code that makes up your application to play nice with valgrind. It is not the OpenSSL project's place to make your commercial product development work best for you in your environment. 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. I think you take the valgrind marketing feature "Valgrind runs on unmodified binaries" far too literally. You have to also account for the flaws in how valgrind is implemented, some people could argue that valgrind should have a rule to cater for this exact problem just like it already does for many quirks of popular libc implemtations and system calls. But it doesn't at this time and I accept that and I accept that -DPURFY is fine for me. I would not be against any fix which has no performance impact and given its this one little line I'd also like to hear the case for why things should be left as they are. Would I be correct in saying that OpenSSL uses the implied randomness of the data on the stack to add randomness to the result. By virute of using uninitialized data as a source of randomness it is this that is causing the problem (then it gets used by the app and one or more bytes find their way into what valgrind believes is dangerous usage and therefore a warning gets emitted) ? Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [patch] Valgrind complaining about unitialized data
> 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 lots of false positives and false negatives. In most realistic scenarios, OpenSSL is far from the least of your problems trying to do this, and it's unlikely you'd be able to make any sense of the output if you didn't have the source code. > Since there's no performance impact from fixing this, and > the concensus is that there's no security gain from leaving > the code as is I simply don't see the point of not changing this. There is a performance impact for this change. That's why the general philosophy is to make optimizations that confuse memory tracking programs in release builds and to disable them in debug builds or builds specifically for memory tracking. > "very few people see it" is true of most bugs :), but it's still > not a good reason to avoid fixing problems. This is neither a problem nor a bug. It's an optimization that valgrind can't cope with. To remove the optimization just for people using valgrind is a bad tradeoff. There are a long list of things you can't do in valgrind builds and avoiding all of them just in case someone is going to run valgrind on a build for which they have no source code and likely can do nothing with the results is a bad tradeoff. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [patch] Valgrind complaining about unitialized data
Yes but: If you use Purify you have to recompile anyway to instrument the code. 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. Since there's no performance impact from fixing this, and the concensus is that there's no security gain from leaving the code as is I simply don't see the point of not changing this. "very few people see it" is true of most bugs :), but it's still not a good reason to avoid fixing problems. Peter "David Schwartz" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 05/03/2007 09:21 AM Please respond to openssl-dev To cc Subject RE: [patch] Valgrind complaining about unitialized data > > 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 never even see them. A lot of applications require you to compile with '-DPURIFY' in order to get reliable results from Purify-like programs. Intentional use of initialized data is just one reason. Other common ones include code to delay freeing data in case it will be be re-allocated shortly or customized memory allocators which need to be disabled in order to accurate detect access to freed memory areas. Compiling with '-DPURIFY' is the ideal tradeoff. Always disabling these improvements just to make Purify-like tools is just wrong. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [patch] Valgrind complaining about unitialized data
> > 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 never even see them. A lot of applications require you to compile with '-DPURIFY' in order to get reliable results from Purify-like programs. Intentional use of initialized data is just one reason. Other common ones include code to delay freeing data in case it will be be re-allocated shortly or customized memory allocators which need to be disabled in order to accurate detect access to freed memory areas. Compiling with '-DPURIFY' is the ideal tradeoff. Always disabling these improvements just to make Purify-like tools is just wrong. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. >>> Not being a valgrind user... I do not see that leaving this area >>> uninitialized will >>> give us some cryptographically useful amount of entropy so that we could >>> as well memset it to 0... >>> >>> >> Ok, I have just applied the patch to 0.9.8-stable and 0.9.9-dev. >> > > Oi. Don't do that. > > Why not? Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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.Until someone enhances valgrind, however,
> something like this might work well:
> {
> RAND_bytes1
> Memcheck: Value1
> /* notused */
> RAND_bytes
> }
> and repeat that four times with 2, 4, 8, 16 replacing the two 1's.
Valgrind can add some "magic" to the library to do "client requests"
so that it can for instance tell it to ignores that something
is unintialised. I believe the proper macro for this
is VALGRIND_MAKE_MEM_DEFINED which is in .
You could use those macro's just before the MD_Update() calls.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 performance hit >>> from doing that will be so small it won't matter. >>> >>> This annoyed me as well - the big advantage of valgrind is that it doesn't >>> require recompilation to work and it's really good if you don't have to >>> wade through all the flase alarms before you can find the real problems. >>> >>> >> Not being a valgrind user... I do not see that leaving this area >> uninitialized will >> give us some cryptographically useful amount of entropy so that we could >> as well memset it to 0... >> > > Ok, I have just applied the patch to 0.9.8-stable and 0.9.9-dev. Oi. Don't do that. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Richard Salz wrote:
Yes, exactly my point.Until someone enhances valgrind, however,
something like this might work well:
{
RAND_bytes1
Memcheck: Value1
/* notused */
RAND_bytes
}
and repeat that four times with 2, 4, 8, 16 replacing the two 1's.
I betcha that catches almost all problems; at least within OpenSSL.
A "suppression rule" is not the same as the rule I'm referring to.
Suppressions work on the symptom what would otherwise be reported, to
suppress that report. So this means you have to supress EVERY stack
trace of the EVERY user of the data returned by RAND_(). As you can
imagine this just is not possible and like duck hunt at the fair ground.
So I agree with your general concept of valgrind needing a rule to learn
this particular case is correct, but it is not a "supression rule" and
I've never had any success with the approach you suggest as new cases
just keep on appearing and I keep adding rules and rules and rules. YYMV
Darryl
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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: http://www.mail-archive.com/openssl-dev@openssl.org/msg21156.html In Debian, since version 0.9.8b-1 those 2 calls are being commented out. I don't know what Ubuntu did to the openssl package, but I assume they still base it on Debian's version. So I can only wonder why Ubuntu's 0.9.8c doesn't have this. Anyway, the memset() you add does remove the warning in some cases. The first place the unintialised values get used is in those MD_Update() calls. There are other places in the code that also call it with an unintialised buffer. I've ran all the regression test thru valgrind, using the memset() solves most of those. As far as I know, commenting out those 2 calls solved all the warnings valgrind reported. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 performance hit >> from doing that will be so small it won't matter. >> >> This annoyed me as well - the big advantage of valgrind is that it doesn't >> require recompilation to work and it's really good if you don't have to >> wade through all the flase alarms before you can find the real problems. >> >> > Not being a valgrind user... I do not see that leaving this area > uninitialized will > give us some cryptographically useful amount of entropy so that we could > as well memset it to 0... > Ok, I have just applied the patch to 0.9.8-stable and 0.9.9-dev. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
> 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 might work well:
{
RAND_bytes1
Memcheck: Value1
/* notused */
RAND_bytes
}
and repeat that four times with 2, 4, 8, 16 replacing the two 1's.
I betcha that catches almost all problems; at least within OpenSSL.
/r$
--
STSM
Senior Security Architect
DataPower SOA Appliances
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 around uninitalized data within your program all day long, but it is only at the point you pass that data to a libc function or system call that a warning is emitted. It is that call which is emitted in the valgrind output (not the original source of the initialized data, the OpenSSL #ifdef PURIFY code). Most of the time the source is close to the usage so this method of reporting works well for most error. But Random data has its own voodoo, like in being copied somewhere ready for use at startup then at a seemingly random point in time the program decides to pick it up and make use of it. So the valgrind warning you see is the symptom not the problem and this disconnection of events is what can cause confusion. 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. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 does /* If the state fails, put some crap in anyway */ RAND_add(&sb,sizeof(sb),0.0); for the (uninitialised) struct stat sb. So I suggest an #ifndef PURIFY around that. (Or, I guess, if PURIFY is defined, initialise sb.) [...] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 it won't matter. > > This annoyed me as well - the big advantage of valgrind is that it doesn't > require recompilation to work and it's really good if you don't have to > wade through all the flase alarms before you can find the real problems. > Not being a valgrind user... I do not see that leaving this area uninitialized will give us some cryptographically useful amount of entropy so that we could as well memset it to 0... Regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. Peter "Stefan Neis" <[EMAIL PROTECTED] line.de> To Sent by: openssl-dev@openssl.org owner-openssl-dev cc @openssl.org Subject Re: [patch] Valgrind complaining 02/03/07 07:53 PM about unitialized data Please respond to openssl-dev Hi, > I'd also like to speak up on behalf of the **vast** majority. > > They don't want unnecessary zeroing of memory in frequently executed > code paths (for which the only reason is to satisfy an infrequently > executed testing environment that valgrind provides). Those wanting > to run valgrind WITH OpenSSL -DPURIFY is provided. Maybe more importantly (at least from my POV), if you're looking for "random bytes", using uninitialized memory (assuming the OS or C runtime doesn't initialize it anyway) instead of something always initialized to the same fixed sequence of bytes actually might be a good idea - or did I misunderstand something? Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Hi, > I'd also like to speak up on behalf of the **vast** majority. > > They don't want unnecessary zeroing of memory in frequently executed > code paths (for which the only reason is to satisfy an infrequently > executed testing environment that valgrind provides). Those wanting > to run valgrind WITH OpenSSL -DPURIFY is provided. Maybe more importantly (at least from my POV), if you're looking for "random bytes", using uninitialized memory (assuming the OS or C runtime doesn't initialize it anyway) instead of something always initialized to the same fixed sequence of bytes actually might be a good idea - or did I misunderstand something? Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 compile flag, but I do not consider that a useful solution to this problem. I think he was asking, you did compile OpenSSL with -DPURIFY and reverify your findings ? You may have a valid new case, but most of the time the real source of the uninitialized data is that one line #ifdef'ed in the OpenSSL source. valgrind will track down to byte level granularity data which is uninitialized, it even tracks when that uninitialized is copied to another location and marks that new location as also containing uninitialized data. So the most common report from valgrind is a bogus error of the first user of that uninitialized data it does not track the source of the uninitialized data (which is really where you should be fixing the problem). So the -DPURIFY kills the only known source of uninitialized data warnings in the OpenSSL project that has been reported todate. The problem is that the vast, **vast** majority of people who might want to valgrind code that links to openssl do not want to compile and install openssl from source. They just want to use the precompiled binary and development packages released by their distribution. I'd also like to speak up on behalf of the **vast** majority. They don't want unnecessary zeroing of memory in frequently executed code paths (for which the only reason is to satisfy an infrequently executed testing environment that valgrind provides). Those wanting to run valgrind WITH OpenSSL -DPURIFY is provided. In addition, I'm not convinced of the quality of the -DPURIFY solution. In the source code package for openssl-0.9.8c from Ubuntu I can only find one usage of the PURFIFY define, this one: > > ...SNIPPED... So, firstly in the source code I was hacking the code the -DPURIFY was supposed to affect is already being disabled. Secondly, if that code is really as un-necessary as it seems to be, why is it still in there? If the Ubuntu is different from the official OpenSSL tree then you really need to take this particular issue up with them. FYI this is how things currently look today with us: http://cvs.openssl.org/getfile/openssl/crypto/rand/md_rand.c Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 consider that a useful solution to this problem. The problem is that the vast, **vast** majority of people who might want to valgrind code that links to openssl do not want to compile and install openssl from source. They just want to use the precompiled binary and development packages released by their distribution. In addition, I'm not convinced of the quality of the -DPURIFY solution. In the source code package for openssl-0.9.8c from Ubuntu I can only find one usage of the PURFIFY define, this one: #ifndef PURIFY #if 0 /* Don't add uninitialised data. */ MD_Update(&m,buf,j); /* purify complains */ #endif #endif Even in the official openssl.org 0.9.8e release, all I can find is your version of the above: #ifndef PURIFY MD_Update(&m,buf,j); /* purify complains */ #endif So, firstly in the source code I was hacking the code the -DPURIFY was supposed to affect is already being disabled. Secondly, if that code is really as un-necessary as it seems to be, why is it still in there? Erik -- +---+ Erik de Castro Lopo +---+ "No Silicon Heaven? Preposterous! Where would all the calculators go?" -- Kryten, Red Dwarf __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 Valgrind and false positives. (Purify is a commercial valgrind competitor). -Brad __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
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 openssl-0.9.8c/crypto/rand/rand_lib.c
openssl-0.9.8c-hacked/crypto/rand/rand_lib.c
--- openssl-0.9.8c/crypto/rand/rand_lib.c 2003-01-31 04:39:23.0
+1100
+++ openssl-0.9.8c-hacked/crypto/rand/rand_lib.c2007-03-02
12:07:32.0 +1100
@@ -154,6 +154,7 @@
int RAND_bytes(unsigned char *buf, int num)
{
const RAND_METHOD *meth = RAND_get_rand_method();
+ memset (buf, 0, num);
if (meth && meth->bytes)
return meth->bytes(buf,num);
return(-1);
--
+---+
Erik de Castro Lopo
+---+
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led them
into it in the first place. - Douglas Adams in Guardian, 25-Aug-95
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
