The problem was the setting for "linux64-sparcv9" within Configure.
Minimum change needed to fix problem:
SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
BF_PTR:::des_enc-sparc.o fcrypt_b.o
i.e. the addition of DES_INT is enough to fix the problem.
The following code should probably be added to the
crypto/des/destest.c around line 354 (at the start of main()) since
AFAIKS DES_LONG must always be exactly 4 bytes long no matter what
platform you are on;
No. DES_LONG can be 8 bytes too. Having it 4 bytes is preferable
because it provides better cache locality, but it's not absolute
requirement. You're likely suffering from compiler bug. Try to drop
optimization level or another compiler version. Even though adding
DES_INT makes sense it's inappropriate to add it to 0.9.8, because
doing so would break binary compatibility. DES_INT is therefore added
to HEAD development branch only.
I don't think it is a compiler bug, FYI it was GCC 4.1.2 which is pretty
recent 20061115.
Well, compiler being recent is no guarantee that it's bug-free:-)
From what I remember all DES_INT does is make the definition a DES_LONG
an "unsigned int" as opposed to an "unsigned long" (which is 64bit on
the linux64-sparcv9 platform).
From what I see if you make sizeof(DES_LONG) != 4, then "struct DES_ks"
size increases to 16 bytes which according its comment is plain wrong.
I'm not at all sure on your cache locality point,
If sizeof(DES_LONG) is 8, then key schedule and SPtrans are 1KB and 4KB
and 1/2 of it would be wasted, because 1/2 will remain unreferenced.
More data than necessary will be brought into cache and therefore more
data than necessary will be evicted as result of DES call.
The main difference between 0.9.7 and 0.9.8 is the use of a SPARC
assembler file to build des_enc-sparc.S.
Aaah! This explains it. All right, it's not compiler bug, as
des_enc-sparc.S is coded for sizeof(DES_LONG) of 4, i.e. it expects key
schedule to occupy 512 bytes and SPtrans - 2K, yes even in its 64-bit
incarnation. To verify try to config with no-asm.
DES_LONG *can* be 8 bytes, it's just that it can't be 8 if you want to
deploy des_enc-sparc.S module. As mentioned adding DES_INT in stable
branch is inappropriate as it may break installations which are opted
for 64-bit ABI, but started compiling the toolkit with no-asm. So that
we have to disengage assembler module... Unless evidence is presented
that SPARC Linux vendors already patch it anyway. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
