Dear OpenSSL developers: I'm not a regular subscriber to openssl-dev, so please forgive me for laying this all out at once.
My name is Allan Pratt, and I am a developer for IBM Rational PurifyPlus. We recently had a Purify customer write to say that Purify does not instrument libcrypto.so properly on SPARC. The customer was right. There is some clever hand-written SPARC assembly code in the DES code which Purify does not handle. This will affect any OpenSSL user on Solaris/SPARC who wants to use PurifyPlus (Purify, Quantify, or PureCoverage) as part of their software quality process, if they end up using the DES parts of libcrypto. I'd like to suggest a change to the SPARC assembly source code in OpenSSL so SPARC users can use Purify successfully. In the file "crypto/des/asm/des_enc.m4" there is a function called ".PIC.me.up" which uses a trick to get its own address. Then it uses that address as the base for getting other addresses in a position-independent way. The trouble is, the trick is too tricky for Purify (and possibly other analysis tools that operate by decoding the instruction stream). The trick being used is that the caller puts a constant in a register before making the call. The constant is the distance from the call instruction to the start of the .PIC.me.up function. The first instruction of .PIC.me.up is an ADD of this value to the caller's return PC. The result is the .PIC.me.up function's own address. This is not a usual way for a function to get its own address on SPARC, and Purify does not handle this kind of inter-procedural address computation. We could add custom analysis logic in Purify to make this work, but it would be very specific and fragile: a future change in des_enc.m4 could make it break again. The trick being used saves a few cycles but I don't think it's in an especially performance-sensitive place: it's in the encrypt/decrypt setup code, not in a loop. A more common (though less hyper-efficient) way for the function to get its own address on SPARC is to use the "call .+8" instruction. History: Looking back, I first see the des_enc.m4 file and its .PIC.me.up trick in version 0.9.8 (with no letter) from 2005. It does not appear to be in any 0.9.7 sources including the most recent, 0.9.7m from 2008. The source file comments indicate that Andy Polyakov ([email protected]) did the "PIC-ification," which suggests he is responsible for the trick in .PIC.me.up. The same comment implies he did it in either 2000 or 2003. This recent customer engagement was the first time anybody had called this problem with OpenSSL and Purify on SPARC to our attention. The following two changes to the custom SPARC assembly code in des_enc.m4 will make Purify work. 1. Delete the first instruction of .PIC.me.up and replace it with this sequence: mov %o7,global1 call .+8 sub %o7,4,out0 mov global1,%o7 2. Change the delay-slot instructions of the calls to .PIC.me.up to NOP instructions. Or just leave them alone: the current instructions there become useless but harmless. The proposed sequence at the start of .PIC.me.up is longer and slower but it has the same effect as the original - that is, the same as the combined effect of the MOV in the caller's delay slot plus the original ADD instruction. It gets the address of the .PIC.me.up label into %o0 ("out0") without changing other registers. (The global1 register is used as a temporary to save and restore %o7. This is safe because global1 will be set later in the function anyway.) The new sequence works both with and without Purify. I'd like to know what the openssl-dev community thinks of this idea, and how I can direct my energies to get this change into the project. I don't want to become a contributor myself; I think it's better if an "owner" of the code in des_enc.m4 reviews this and implements it if it meets with approval. Thanks for your attention. -- Allan Pratt, [email protected] Rational software division of IBM ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
