Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify

[Michael Sierchio]

Ger Hobbelt wrote:
> On Mon, Mar 16, 2009 at 10:23 PM, Kenneth Robinette
>  wrote:
>> You need to take this discussion offline.
> 
>  Finally something interesting to read and it's mentioned it
> should go. sigh. Here's two who know their craft, it's even about
> OpenSSL and it has given me joy these days, just by reading this. This
> wins over FAQable question posts any day.

Gerrit -

I agree with you completely.  Some actual nitty-gritty is good to read.

- Michael
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify

[Ger Hobbelt]

On Mon, Mar 16, 2009 at 10:23 PM, Kenneth Robinette
 wrote:
> You need to take this discussion offline.

 Finally something interesting to read and it's mentioned it
should go. sigh. Here's two who know their craft, it's even about
OpenSSL and it has given me joy these days, just by reading this. This
wins over FAQable question posts any day.

-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify

[Kenneth Robinette]

You need to take this discussion offline.

Ken



--- On Mon, 3/16/09, Allan K Pratt  wrote:

> From: Allan K Pratt 
> 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.
> 
> 
> 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."
> 
> 
> 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 u

Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify

[Allan K Pratt]

> 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.


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."


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 
s

[openssl.org #1870] str2fmt() in apps/apps.c parses "pkcs12" and "p12" as FORMAT_PEM

[kilroy via RT]

Quoting from openssl-SNAP-20090316/apps/apps.c:

258 if  ((*s == 'D') || (*s == 'd'))
259 return(FORMAT_ASN1);
260 else if ((*s == 'T') || (*s == 't'))
261 return(FORMAT_TEXT);
262 else if ((*s == 'P') || (*s == 'p'))
263 {
264 if (s[1] == 'V' || s[1] == 'v')
265 return FORMAT_PVK;
266 else
267 return(FORMAT_PEM);
268 }
269 else if ((*s == 'N') || (*s == 'n'))
270 return(FORMAT_NETSCAPE);
271 else if ((*s == 'S') || (*s == 's'))
272 return(FORMAT_SMIME);
273 else if ((*s == 'M') || (*s == 'm'))
274 return(FORMAT_MSBLOB);
275 else if ((*s == '1')
276 || (strcmp(s,"PKCS12") == 0) || (strcmp(s,"pkcs12") == 0)
277 || (strcmp(s,"P12") == 0) || (strcmp(s,"p12") == 0))
278 return(FORMAT_PKCS12);

The tests on lines 276 and 277 are never reached because the tested strings
also match a previous, more general test on line 262. Curiously, a similar
collision between FORMAT_PEM and FORMAT_PVK is handled on line 264.

STEPS TO REPRODUCE
Specify a "-keyform pkcs12" argument to openssl and it will behave as if
you specified "-keyform pem". The only way to really use PKCS12 is to
specify "-keyform 1" (see line 275).

I'm currently unable to provide a patch but it should be relatively
trivial.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify

[Andy Polyakov]

> I see what you mean about the caller/callee relationship in the example 
> you gave. If the caller uses call/add to do the call and also compute a 
> pointer to data, and the callee only receives this as an ordinary pointer 
> (not as the basis for further PIC computations), there's nothing 
> interprocedural going on for Purify to have to recognize.
> 
> Sadly, today's Purify does not handle this call/add pair for passing a 
> pointer to nearby data. It's not impossible for us to add a recognizer for 
> this pattern, but we don't have one now.

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?

> Oh, by the way: when Purify stretches code, we don't try to preserve 
> alignment above what's needed for correct operation, so tables that start 
> with directives like ".align 64" might not stay aligned. If that's just 
> for cache-line efficiency, there's no problem, it'll just run slower. (And 
> if you're using Purify, the performance ship has already sailed.) But if 
> your algorithm relies on the low six bits of the address being zero, 
> you'll lose. The same goes for all the align directives I see. I hope 
> that's not a problem.

Not at the moment, no.

> Further thoughts?

When does Purify stretch code more specifically? Always (because it
might have to inject some prologue/epilogue to every function)? Or only
when is has to compensate for "mishaps" when single add %o7,const,%??
has to be replaced with several instructions (because const is limited
to 13 bits)? Question basically is what are the chances for something
like earlier mentioned

1:  call_sparcv9_AES_encrypt
sub %o7,1b-AES_Te,%o4

to be *unaffected* by Purify? I mean if Purify does *not* stretch
anything between AES_Te and 1:, then it would work just fine, wouldn't
it? I'm not saying that I refuse to make aes-sparcv9 module
Purify-friendly (it is patched already as per
http://cvs.openssl.org/chngview?cn=17898), I still want to fully
understand "rules of engagement":-) A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify

[Andy Polyakov]

>>> Further digging in des_enc.m4 revealed another problem. Besides the actual 
>>> instructions in .PIC.me.up there is something else Purify doesn't notice 
>>> that it should patch. The data item at .PIC.DES_SPtrans is the 32-bit 
>>> offset from its own location (in .text) to DES_SPtrans (in .rodata). 
>>> Because of code movement, Purify needs to patch this data item, but 
>>> doesn't notice that it should. (Once again, this is a nonstandard way for 
>>> a program to get the address of a data item in a position-independent 
>>> way.)
>> ??? Latest version of des_enc.m4 does not have any offset data.
> 
> This is incorrect statement. Latest version of des_enc.m4 does not have
> offset data at *mentioned locataion*[!].

Well, this was not whole truth either: 0.9.8 tree had this offset data
at mentioned location (as well as #ifdef OPENSSL_PIC), which I failed to
remember. Sorry about confusion:-( See
http://cvs.openssl.org/chngview?cn=17899 for 0.9.8 patch, which
harmonizes modules in HEAD and 0.9.8 branches. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Error showed up in openssl-SNAP-20090315

[Ger Hobbelt]

Checked against this morning's CVS HEAD 0.9.9 and no problem at all.

I also compared the changes to the distribution to the patch which I
filed regarding assert vs OPENSSL_assert in v3_addr (PR: 1863) and it
was applied correctly and completely. There is no need for 
in v3_addr.c. (Though I do see that the patch was applied in two
rounds in CVS so it may be that the snapshot was made in between those
two.)

it should at least be gone in tonight's snapshot as that is derived
from the current state of affairs in CVS head.


On Sun, Mar 15, 2009 at 2:16 PM, The Doctor  wrote:
> This showed up on today's compile as an assert error.
>
> /path/to/openssl-SNAP-20090315/crypto/x509v3/v3_addr.c
>
> As an error
>
> Please add
>
> then line
>
> #insert 
>
> to solve in  /path/to/openssl-SNAP-/crypto/x509v3/v3_addr.c
>
> assert error .
>
>
> --
> Member - Liberal International  This is doc...@nl2k.ab.ca
> Ici doc...@nl2k.ab.ca God, Queen and country! Beware Anti-Christ rising!
> Never Satan President Republic!
> Point to http://tv.cityonahillproductions.com/
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>
>



-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1869] make fails

[Dennis Clarke via RT]

On Solaris 8 x86 :

$ cd openssl-0.9.8j
$ ./Configure solaris-x86-cc --prefix=/opt/csw threads zlib-dynamic shared
386 n
o-sse2
Configuring for solaris-x86-cc
no-camellia [default]  OPENSSL_NO_CAMELLIA (skip dir)
no--capieng  [default]  OPENSSL_NO_CAPIENG (skip dir)
no-cms  [default]  OPENSSL_NO_CMS (skip dir)
no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-mdc2 [default]  OPENSSL_NO_MDC2 (skip dir)
no-montasm  [default]
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
no-seed [default]  OPENSSL_NO_SEED (skip dir)
no-sse2 [forced]
IsMK1MF=0
CC=cc
CFLAG =-KPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
-D_REE
NTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa
EX_LIBS   =-lsocket -lnsl -ldl
CPUID_OBJ =
BN_ASM=bn_asm.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ASM_OBJ   =aes_core.o aes_cbc.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o rc4_skey.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =
RMD160_OBJ_ASM=
PROCESSOR =386
RANLIB=/usr/ccs/bin/ranlib
ARFLAGS   =
PERL  =/opt/csw/bin/perl
THIRTY_TWO_BIT mode
DES_PTR used
DES_UNROLL used
BN_LLONG mode
RC4 uses uchar
RC4_CHUNK is unsigned long
BF_PTR used
e_os2.h => include/openssl/e_os2.h
making links in crypto...
crypto.h => ../include/openssl/crypto.h
tmdiff.h => ../include/openssl/tmdiff.h
opensslv.h => ../include/openssl/opensslv.h
opensslconf.h => ../include/openssl/opensslconf.h
ebcdic.h => ../include/openssl/ebcdic.h
symhacks.h => ../include/openssl/symhacks.h
ossl_typ.h => ../include/openssl/ossl_typ.h
making links in crypto/objects...
objects.h => ../../include/openssl/objects.h
obj_mac.h => ../../include/openssl/obj_mac.h
making links in crypto/md2...
md2.h => ../../include/openssl/md2.h
md2test.c => ../../test/md2test.c
making links in crypto/md4...
md4.h => ../../include/openssl/md4.h
md4test.c => ../../test/md4test.c
md4.c => ../../apps/md4.c
making links in crypto/md5...
md5.h => ../../include/openssl/md5.h
md5test.c => ../../test/md5test.c
making links in crypto/sha...
sha.h => ../../include/openssl/sha.h
shatest.c => ../../test/shatest.c
sha1test.c => ../../test/sha1test.c
sha256t.c => ../../test/sha256t.c
sha512t.c => ../../test/sha512t.c
making links in crypto/hmac...
hmac.h => ../../include/openssl/hmac.h
hmactest.c => ../../test/hmactest.c
making links in crypto/ripemd...
ripemd.h => ../../include/openssl/ripemd.h
rmdtest.c => ../../test/rmdtest.c
making links in crypto/des...
des.h => ../../include/openssl/des.h
des_old.h => ../../include/openssl/des_old.h
destest.c => ../../test/destest.c
making links in crypto/aes...
aes.h => ../../include/openssl/aes.h
making links in crypto/rc2...
rc2.h => ../../include/openssl/rc2.h
rc2test.c => ../../test/rc2test.c
making links in crypto/rc4...
rc4.h => ../../include/openssl/rc4.h
rc4test.c => ../../test/rc4test.c
making links in crypto/idea...
idea.h => ../../include/openssl/idea.h
ideatest.c => ../../test/ideatest.c
making links in crypto/bf...
blowfish.h => ../../include/openssl/blowfish.h
bftest.c => ../../test/bftest.c
making links in crypto/cast...
cast.h => ../../include/openssl/cast.h
casttest.c => ../../test/casttest.c
making links in crypto/bn...
bn.h => ../../include/openssl/bn.h
bntest.c => ../../test/bntest.c
exptest.c => ../../test/exptest.c
making links in crypto/ec...
ec.h => ../../include/openssl/ec.h
ectest.c => ../../test/ectest.c
making links in crypto/rsa...
rsa.h => ../../include/openssl/rsa.h
rsa_test.c => ../../test/rsa_test.c
making links in crypto/dsa...
dsa.h => ../../include/openssl/dsa.h
dsatest.c => ../../test/dsatest.c
making links in crypto/ecdsa...
ecdsa.h => ../../include/openssl/ecdsa.h
ecdsatest.c => ../../test/ecdsatest.c
making links in crypto/dh...
dh.h => ../../include/openssl/dh.h
dhtest.c => ../../test/dhtest.c
making links in crypto/ecdh...
ecdh.h => ../../include/openssl/ecdh.h
ecdhtest.c => ../../test/ecdhtest.c
making links in crypto/dso...
dso.h => ../../include/openssl/dso.h
making links in crypto/engine...
engine.h => ../../include/openssl/engine.h
enginetest.c => ../../test/enginetest.c
making links in crypto/buffer...
buffer.h => ../../include/openssl/buffer.h
making links in crypto/bio...
bio.h => ../../include/openssl/bio.h
making links in crypto/stack...
stack.h => ../../include/openssl/stack.h
safestack.h => ../../include/openssl/safestack.h
making links in crypto/lhash...
lhash.h => ../../include/openssl/lhash.h
making links in crypto/rand...
rand.h => ../../include/openssl/rand.h
randtest.c => ../../test/randtest.c
making links in crypto/err...
err.h => ../../include/openssl/err.h
making links in crypto/evp...
evp.h => ../../include/openssl/evp.h
evp_test.c => ../../test/e

[openssl.org #1868] Bug Report: crash in RSA_free() under Windows 64bit

[Paolo Ganci via RT]

Hello,

I executed the following command on an X86 64bit Windows2003 Server (see full 
specifications at the bottom):

$ ./openssl.exe  rsa -in ../test/openssl/crypto/url/test_data/certchainfull.der 
-text -noout -inform DER

and got an application error in rsa_lib.c, function RSA_free():

if (r->meth->finish)
r->meth->finish(r);


Analyzing the code I find out that r->meth was set to zero. This should never 
be the
case so I tried to find out where the memory of &r->meth has been overwritten.

The problem lies in the fact, that the type 'long' has a size of 4 bytes on 
x84/64bit, but
a pointer 8 bytes (as expected). In the file rsa.h you have the following 
struct:

struct rsa_st
{
/* The first parameter is used to pickup errors where
 * this is passed instead of aEVP_PKEY, it is set to 0 */
int pad;
long version;
const RSA_METHOD *meth;
/* functional reference if 'meth' is ENGINE-provided */
ENGINE *engine;
.
.
.
}


When reading the inputfile the function asn1_template_ex_d2i() (file 
tasn_dec.c) is called:
static int asn1_template_ex_d2i(ASN1_VALUE **val,
const unsigned char **in, long inlen,
const ASN1_TEMPLATE *tt, char opt,
ASN1_TLC *ctx);

In our case *val is the address if the field 'version' in the 'struct rsa_st' 
above.
If an error occurs, at the end of the function '*val' is set to NULL:
*val = NULL;

but this will write 8 bytes into the pointer so that the field 'meth' (which 
just
follows 'version'), will be set to 0x as well.

You may temporally solve the problem by putting a dummy-long between the field 
'version'
and the field 'meth', but you still may have problem on other structs.


I personally thing, the setting of
*val = NULL;
is not necessary, because this should have be done in the 
ASN1_template_free()-function.


Please let me know if and how you will fix the bug.

With kind regards
Paolo

OpenSSL version: output of 'openssl version -a'
OpenSSL 0.9.8i 15 Sep 2008
built on: Thu Mar 12 11:31:33 2009
platform: VC-WIN64A
options:  bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) 
idea(int) blowfish(idx)
compiler: cl -DDEBUG  /MD /Ox /W3 /Gs0 /GF /Gy /nologo 
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DOPENSSL_SYSNAME_WIN32 
-DOPENSSL_SYSNAME_WINNT -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. /Fdout32dll 
-DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 
-DOPENSSL_NO_TLSEXT -DOPENSSL_NO_CMS -DOPENSSL_NO_CAPIENG -DOPENSSL_NO_KRB5 
-DOPENSSL_NO_DYNAMIC_ENGINE
OPENSSLDIR: "/usr/local/ssl"

OS Name, Version, Hardware platform:
Microsoft Windows Server 2003
Enterprise X64 Edition
Service Pack 2

Compiler Details (name, version):
Visual C++ 6.0 with SDK X64 Debug Build Environment


--
 AdNovum Informatik AG
 Paolo Ganci, Senior Software Engineer
 Dipl. El.-Ing. ETH

 Roentgenstrasse 22, CH-8005 Zurich
 mailto:paolo.ga...@adnovum.ch
 phone: +41 44 272 6111, fax: +41 44 272 6312
 http://www.adnovum.ch

 AdNovum Locations: Bern, Budapest, San Mateo, Zurich (HQ)



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Error showed up in openssl-SNAP-20090315

[Rob Austein]

Looks like an incomplete conversion from assert() to OPENSSL_assert().
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

IA64 build Makefile error

[Rothrock, Thomas SMDC SimCtr/Madison Research Corp]

Hello.  I am building OpenSSL 0.9.8j from the source available at
http://www.openssl.org/source/openssl-0.9.8j.tar.gz on an IA64 linux
system.  During the build I encountered an error in crypto/sha/Makefile.
For the linux-ia64 build, the output of the perl scripts goes to stdout
instead of being redirected to the .s files.  I made the following
modification and afterwards it was able to build and test successfully:


# diff -Naur obj/crypto/sha/Makefile src/crypto/sha/Makefile
--- obj/crypto/sha/Makefile 2009-03-13 09:31:16.419968132 -0500
+++ src/crypto/sha/Makefile 2008-10-06 05:35:29.0 -0500
@@ -59,11 +59,11 @@
(cd asm; $(PERL) sha512-sse2.pl a.out $(CFLAGS) $(PROCESSOR) >
../$@)
 
 sha1-ia64.s:   asm/sha1-ia64.pl
-   (cd asm; $(PERL) sha1-ia64.pl ../$@ $(CFLAGS) > ../$@)
+   (cd asm; $(PERL) sha1-ia64.pl ../$@ $(CFLAGS))
 sha256-ia64.s: asm/sha512-ia64.pl
-   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS) > ../$@)
+   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS))
 sha512-ia64.s: asm/sha512-ia64.pl
-   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS) > ../$@)
+   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS))
 
 # Solaris make has to be explicitly told
 sha1-x86_64.s: asm/sha1-x86_64.pl; $(PERL) asm/sha1-x86_64.pl $@



  ---
   Tom Rothrock   
   US Army Space & Missile Defense Command Simulation Center
   256-955-3382 (DSN 645)   FAX 256-955-1231
    Main SimCtr Phone:  256-955-3750
  ---
  This email capability is supported by Department of Defense
  systems and is subject to monitoring.  Please refrain from
  using this address for non-Government purposes.
  ---
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org