The best way is to send a patch (unified diff) to [email protected]. This allows for ease of patching, and ensuring that the actual intent of the patch is preserved at the source level.
The module owner will review the patch and apply it if appropriate, and your name (and the fact that IBM contributed a bit of resource to the code) will go into the changelog for credit. You do not need to become a regular contributor for this sequence of operations to occur. :) -Kyle H On Mon, Mar 9, 2009 at 1:17 PM, Allan K Pratt <[email protected]> wrote: > 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] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
