Allan K Pratt wrote: > EASY FIX: wherever RAND_add is defined (macro? function?), give it a > different body for -DPURIFY builds. When PURIFY is defined, don't use > the > memory being passed in at all. This sounds extreme, but it should work. > Sure, the entropy factors will change and the resulting numbers might > not > be very random, but who cares? Builds with -DPURIFY are about testing > the > memory usage of the app or library, not about the quality of its random > numbers, right? This solution has the virtue of working for both Purify > and Valgrind, and you don't have to hunt down and tweak every caller of > RAND_add. (It would probably be good to ensure there is *some* entropy > when PURIFY is defined, so the numbers you get aren't the same every > time.)
That sounds like an incredibly horrible idea to me. Builds that silently fail to provide the desired security properties seem like very bad things to have around. In any event, that conflicts with the way other people use -DPURIFY, at least in my experience. For example, I deploy -DPURIFY builds because -DPURIFY disables 'optimizations' that distort memory usage patterns. For example, Purify catches access after free, so -DPURIFY disables optimizations that hide access after free (for example, keeping a list of recently-freed objects for reuse). These builds are useful for more accurately measuring memory usage and growth. IMO, -DPURIFY should make all callers of RAND_add (that aren't known to never pass uninitialized data) zero their buffers before they put data in them. Fixes specific to valgrind or purify are great for those tools. But the logic of -DPURIFY (at least, in my world) is that it's supposed to purify the code so that it can be analyzed (in its 'pure' form) with *any* tool. Optimizations that hide memory allocation patterns, use uninitialized data, intentionally over-allocate memory (in case it's needed later, but thus hiding bounds errors) should be disabled. I realize that I may be arguing that everyone should do things the way I do them. But they do seem the most sensible to me, for what that's worth. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
