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]

Reply via email to