Oops. Should have replied to r...@openssl.org. Sorry about duplicate. A.
-------- Original Message --------
Subject: Re: [openssl.org #1998] [PATCH] SHA512 ROTR macro fix for
PowerPC using LP32 model
Date: Sat, 12 Sep 2009 18:57:58 +0200
From: Andy Polyakov <ap...@fy.chalmers.se>
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
References: <rt-ticket-1...@openssl.org>
<b71dcb610d2a2f41b8d20b868c6ecead05313...@superfly.netflix.com>
<rt-3.4.5-14104-1249285995-1620.1998-2...@openssl.org>
> I just ran into a bug where SHA384/512 were not being calculated
> correctly on the Cell processor. I tracked it down to the definition of
> the ROTR macro, which is assuming a 64 bit long, but in this case the
> compiler is using the LP32 model so long is 32 bits and the values were
> being truncated. Here is the patch I did that fixes the problem:
>
> --- sha512.c 2009-07-27 15:04:52.546574000 -0700
> +++ sha512.c 2009-07-27 15:08:07.373452100 -0700
> @@ -344,7 +344,7 @@
> ((SHA_LONG64)hi)<<32|lo; })
> # endif
> # elif (defined(_ARCH_PPC) && defined(__64BIT__)) ||
> defined(_ARCH_PPC64)
> -# define ROTR(a,n) ({ unsigned long ret; \
> +# define ROTR(a,n) ({ SHA_LONG64 ret; \
> asm ("rotrdi %0,%1,%2" \
> : "=r"(ret) \
> : "r"(a),"K"(n)); ret; })
Trouble with using rotrdi in ILP32 PPC application context is that there
are PPC OSes that wipe upper halves of registers upon signal delivery.
All PPC OSes do preserve full registers upon context switch, so that the
code works fine in e.g. openssl test suite, but it will eventually fail
in real-life application, one utilizing asynchronous signaling in some
way. The problem would appear sporadic and rare, because signal would
have to be delivered in very specific moments. The only way to safely
use 64-bit instructions in ILP32 process (on these PPC OSes) is to block
signals upon entry to such subroutine and unblock upon return. As for
"these PPC OSes." Both Linux and AIX are ill-behaved, but not MacOS X
(starting with one supporting 64-bit applications).
In other words correct solution for the problem is to make sure the
macro is *not* defined in ILP32 context. Meaning that we have to
reiterate #elif expression instead of fixing the macro. What's your
compiler version? Submit 'gcc -dumpspecs' output (I assume it's gcc). A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
