You need to take this discussion offline. Ken
--- On Mon, 3/16/09, Allan K Pratt <apr...@us.ibm.com> wrote: > From: Allan K Pratt <apr...@us.ibm.com> > Subject: Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify > To: openssl-dev@openssl.org > Date: Monday, March 16, 2009, 3:49 PM > > And the only difference would be to relax pattern > recognition so that > delay slot is examined for %o7-based arithmetic for all > call instructions, > not only call .+8 in particular. Is this correctly > understood? > > Yes, you correctly understand this. But it's not as > easy as that. I don't > need to get into Purify implementation details, but > remember, if the > target gets pushed more than 13 bits away we need to turn > the call/add > into sethi/or/call/add or something like that. The fact > that this is in a > delay slot and also that the %o7 value from the call is a > source register > complicates things even more. It would not be impossible to > handle this > but there is the ROI to consider. > > You asked when, specifically, Purify stretches code. The > short answer is: > anywhere we need to. Definitely at the top of a function, > and at every > memory load or store instruction, and after function calls. > Beyond that, > we might do insertion on any instruction at all, subject to > our needs. > > <sales_pitch> > The basic Purify insertion is on load and store > instructions; everything > else is in support of that. Purify's whole value > proposition is to > pinpoint memory errors like reading uninitialized memory, > or touching > beyond the end of a block or the end of the current stack, > or touching > memory you've already freed. In contrast, malloc-debug > libraries only > report bad writes, and only after the fact. They spray > patterns into freed > memory in the hopes that bad reads will cause visible > misbehavior in the > program's future. Unlike those, Purify sees both reads > and writes when > they happen, pinpointing the faulting instruction instead > of telling you > "a bad thing happened sometime in the past." > </sales_pitch> > > Best case (on SPARC) is that we insert two instructions > before each load > or store. Worst case, we "unravel" instructions > out of delay slots, add > more instructions to "shadow" certain types of > register usage, and deal > with offsets that have grown too large by inserting > additional math. > > You asked how you can know that Purify will *not* do > insertion or stretch > your code. That's a little tricky. If you have two > non-global symbols that > identify data blocks, and there are no global symbols or > code > (instructions) between them, there won't be any > stretching from today's > Purify. But any instructions at all are subject to > insertion, and in some > cases we insert dead space (a "red zone") before > a global data symbol. > > Now, back to libcrypto: while you and I have been talking, > our resident > genius instrumentation engine guy has actually coded some > modifications to > support the .PIC.me.up pattern as it appears in 0.9.8j. > This supports our > current customers who use past, released versions of > libcrypto on SPARC. I > expect this change to appear in an upcoming release of > PurifyPlus, but I > can't commit to it or give a date because I'm not > authorized to commit to > future product features or support in a public forum. > > The new pattern recognizer is pretty specific, intending to > support > existing customers with libcrypto binaries. It's not a > general-purpose > recognizer for optimized interprocedural PIC sequences. It > recognizes > patterns that stay very close to this: > > call target > mov offset,%o0 > ... > > target: > add %o0,%o7,%o0 > > The new code recognizes this when "offset" is the > distance from the call > instruction to "target," and the "add" > really is the very first > instruction at the call target. We'll even patch the > offset if the > distance from the caller to the target grows past 13 bits. > > The developer also coded changes to recognize and patch the > self-relative > offset in data from .PIC.DES_SPtrans to DES_SPtrans. I > don't know the > details and restrictions on this one. Like I said, it's > really meant for > customers with current libcrypto binaries. > > Regardless of any new recognizers which might appear in the > future, there > are two Purify-safe ways to do PIC stuff on SPARC: > > Short form: > L1: call8 > add %o7,(target-L1),regZ > > Long form: > sethi %hi(target-L2),regX > or regX,%lo(target-L2),regY > L2: call8 > add regY,%o7,regZ > > The short form will work even if Purify stretches the > distance farther > than 13 bits will reach. Purify is flexible: regX, regY, > and regZ can be > different or they can overlap, and the call8 can happen any > time before > the add, and you can move the o7 result of the call8 to > another register > if you want and then use that: it doesn't have to stay > in o7. You can use > the same call8-derived base register for multiple PIC > computations, but > you can't use one computed address (like regZ) as the > base for another. > These two patterns work for both 32-bit and 64-bit > programs. > > Regarding the patch you referred to > (http://cvs.openssl.org/chngview?cn=17898): I'm sorry > to say Purify is not > as flexible as you might want. In the short form we > recognize "add" using > %o7 after call8, but not "sub." So the patched > aes_sparcv9 module is *not* > Purify-friendly yet. To fix this, change "sub" to > "add" and reverse the > subtraction that computes the offset: > > BAD: > 1: call .+8 > sub %o7,1b-AES_Te,%o4 > > GOOD: > 1: call .+8 > add %o7,AES_Te-1b,%o4 > > Thanks for working with us on this. Let me know if you have > more thoughts > or questions. > > -- Allan Pratt, apr...@us.ibm.com > Rational software division of IBM > > ______________________________________________________________________ > 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
