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 [email protected]
Automated List Manager [email protected]
