On Friday 18 July 2008 10:57:50 Bodo Moeller wrote: > On Thu, Jul 17, 2008 at 7:07 PM, Frederic Heem <[EMAIL PROTECTED]> wrote: > > Please find attached a patch which makes valgrind and friends happy. Some > > changes had been done in md_rand.c which broke the purpose of PURIFY. > > Needless to say that the define PURIFY is *not* for production system... > > Defining PURIFY should never make the PRNG weak. If Valgrind finds > data that is used uninitialized, then a "PURIFY" patch should only > ensure that those exact bytes of data are initialized with some data. > Never overwrite a byte that actually may have been initialized.
Agreed, though where possible it's preferable for PURIFY-handling to simply not use the uninitialised data at all, rather than initialising it before use. (NB, I know this yields the same quality result, but appearances in the code are often as important as the outcome of the executable - particularly where package maintainers are concerned...) IIRC, it's complicated to remove the (uninitialised) loads here without also removing the desired stores, in which case I totally agree that memset(,0,) is a more obvious PURIFY(/valgrind) workaround. But where it's possible to trim our use of an input buffer so that we don't take some uninitialised "trimmings", then the intent of the code would be much clearer. Moreover, it's more likely valgrind would then find bugs in the PRNG code (if ever we accidently debianise it ourselves) - whereas wholesale memset()s kind of limit the effectiveness of such debugging tools. Or put another way, -1 to the suggested patch. Also, -1 to the general statement that "PURIFY is *not* for production system". That is not our call to make! If the production system is experiencing problems and is being diagnosed - it may very well make sense to run it under PURIFY/valgrind to help track down problems that have only been observed in production. (Anyone who has ever tried to gaze into a crystal ball and invent a test-case to reproduce sporadic problems from a production system will know what I'm talking about). Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]