Hi, and thanks for report! > I got a strange bug report claiming that "openssl md5" was dumping core on > old parisc hardware. Sure enough, it was generating the correct result > but then crashing: > > $ openssl md5 /dev/null > MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e > Segmentation fault (core dumped)
It's perplexing that it went unnoticed for this long. Is it possible that problem was compensated for in specific linker patch-level or something? I mean linker can generate trampoline code that does the right thing or simply replace the instruction under specific circumstances... > The debugger wasn't much help, but through trial and error I narrowed it > down to the single call to OPENSSL_cleanse() in apps/dgst.c. I then spent > a few frustrating hours learning the minutia of how parisc assembly works. > > It turns out the problem is rather subtle. The implementation of > crypto/pariscid.pl returns to its caller with this instruction: > > bv ($rp) > > That would work if it were a function statically linked into bin/openssl. > However, when returning to a function in a different segment you must use > the "bve" instruction ("Branch Vectored _External_") or it will crash as > as the branch completes. By the way, "bve($rp)" is known simply as "ret" > when disassembling. Replacing all bv's with bve's would break 32-bit builds, because bve is 2.0 instruction. Could you verify http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=02450ec69dda7815ba1e7bd74eb30f0ae1eb3042 that replaces bv only when build targets 64-bit mode? Once it's verified, it goes down to 1.0.x. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org