Hi there, On July 18, 2003 08:29 am, Andrew Marlow wrote: > I have found that the ssltest program raises several purify errors > which I am looking at. They are UMRs, uninitialised memory reads, > i.e memory is read and acted on even though it was never > given a value. Here is the first one (based on v0.9.7b):
Actually the "problem" is in crypto/rand/md_rand.c, search for "PURIFY". Our randomess routines are hashing in various sources of entropy, and before manipulating a buffer on the stack it simply adds in the data already in that buffer. This is obviously a source of "uninitialised" data but that can only help us right? No assumptions are made about the level of entropy in that buffer (indeed it may well be all zeroes in most environments), but we're certainly not worried about getting unpredictable behaviour because of it - we *are* trying to generate randomness after all. If you compile with "-DPURIFY", it will deliberately avoid this behavour so as not to throw up false positives from purify, valgrind, or anything similar. > routine SHA1_Update, line 460 of md32_common.h > It examines the first byte of a block allocated > at line 304 of mem.c (CRYPTO_malloc). This is where the uninitialised data is first touched, if you look a level or two up the call stack, you'll see that you're in md_rand.c at the point I mentioned. > A little further down there is a statement that > does initialise this byte but only if the block size > is greater than 2048. A block size of 64 was allocated. This is for another reason entirely, unrelated issue. It's actually a way of foiling compiler optimisations that would otherwise get rid of memset(,0,) statements when it knows the memory is about to be freed - we want those memsets to happen precisely *because* memory is about to be freed and contains stuff we want sanitised first. To get the dependencies foolproof against "smart" (I use the word reluctantly) compilers therefore, there's a bit of tomfoolery involved and you stumbled on to part of it. This has nothing to do with the "purify" issue. > The comment says (and I quote) "NB: We only do this > for >2Kb so the overhead doesn't bother us". > The UMR says that the initialise should always be done, > IMHO. ?? As I say, define PURIFY and openssl will build in a way that doesn't (or shouldn't) do anything purify doesn't like. Search for "purify" and/or "valgrind" in the mail lists and you'll see this has been discussed before. Likewise, the memory sanitisation discussions are probably easy to pick up if you hit the archives. > I also notice that SHA1_Update is called from > ssleay_rand_bytes (md_rand.c, line 468) where > an ifdef for PURIFY has been added, indicating > that this area has received purify attention before. > > Any thoughts? I hope that clarifies the situation. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
