Greetings,
Please read through the entire contents of this message. I included the
entire discussion because I thought it would help clarify things.
Basically the problem is with dsa_lib.c. What happens is that on Solaris
if you try to use any version of the 0.9.6x openssl libraries with
Solaris 2.6/8 (at least at the July 11th patch cluster....and Solaris 8
based on the January 20001 Release) with openssh you end up with an
ssh_keygen that bus errors when trying to create dsa public/private
keys. I'm not done finding the exact source of the problem in Solaris,
but I was told to pass this information along to you. I am willing to
help in any way I can. I have access to all types of Solaris machines
and I use both gcc and and the very latest Sun Forte compilers. Please
contact me if you need more information. I will be providing information
on the patch levels of the machines I am building openssh and openssl
on...as well as building a clean environment on the April 2001 Solaris 8
release. I am trying to prevent people from having the same problems in
the future ( I wouldn't suspect everyone would be as patient with things
as I was). Anything I can do for you let me know. (Be aware that I am
able to get things working...you will learn what was done to make things
work below.) I am still in the process of testing the applications and
compiling for different architectures.
Thanks,
Scott
Hello,
I have tried to install openssh 2.9p2 on Solaris 2.6 and Solaris 2.8
after compiling the openssl (both 0.9.6a and 0.9.6b) and openssh
software with both gcc 2.95.3, Sun's Forte compiler, Sun's linker, etc.
I have tried the zlib from Sun freeware and version 11.8.0
REV=2000.01.08.18.12 contained in the SUNWzlib package. Both openssh and
openssl appear to make properly and all the tests for openssl pass. When
I do a make install for openssh it fails to generate public/private dsa
keys..in fact ssh_keygen has a bus error when trying to do DSA
operations. I know other people have had this problem, because I've seen
similar messages in the mailing list. Unfortunately it appears that
noone has a solution...at least I can't find an answer. What I am
wondering is if anyone can get openssh to work on Solaris with the
0.9.6x openssl libraries. Maybe I'm missing someone, but everything
seems to work fine with the 0.9.5x openssl libraries. It appears to me
that something broke after the 0.9.5x libraries. I'm not sure if openssl
is the problem. If this problem has been resolved then please enlighten
me, otherwise I can provide more details to help resolve this issue.
Thanks,
Scott
Hello,
>From the response to my original post regarding openssh, obviously the
only way to resolve the problem of getting openssh to work properly
under Solaris 8 with openssl 0.9.6b was to compile with debugging an
analyze to core file. Let me state that I am not a developer, but maybe
the following will help. I have compiled both openssh2.96p2 and openssl
0.9.6b with debugging using the Sun Forte Compiler update 2. I compiled
each piece of software without any additional options, the only thing I
did was change the --prefix. Below is some output from dbx: (The core I
am examining here comes from the make install...when it trys to create
the private/public dsa keys.)
(If there is anything else I can do to help let me know. The system is
5.8 Generic_108528-08 with the recommended patch cluster from July 11th.
This is an Ultra10 workstation) I also have the same problem using gcc
2.95.3 on Solaris 8 and Solaris 2.6.
Reading ssh-keygen
core file header read successfully
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libgen.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libmp.so.2
Reading libc_psr.so.1
program terminated by signal BUS (invalid address alignment)
Current function is DSA_new_method (optimized)
127 ret->flags=ret->meth->flags;
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx)
where
=>[1] DSA_new_method(meth = ???) (optimized), at 0x4b6b8 (line ~127) in
"dsa_lib.c"
[2] DSA_new() (optimized), at 0x4b580 (line ~86) in "dsa_lib.c"
[3] DSA_generate_parameters(bits = ???, seed_in = ???, seed_len = ???,
counter_ret = ???, h_ret = ???, callback = ???, cb_arg = ???)
(optimized), at 0x4ace4 (line ~115) in "dsa_gen.c"
[4] dsa_generate_private_key(bits = 1024U), line 560 in "key.c"
[5] key_generate(type = 2, bits = 1024U), line 576 in "key.c"
[6] main(ac = 7, av = 0xffbefc74), line 781 in "ssh-keygen.c"
Lutz,
Responding to some of your statements:
1) Both openssl 0.9.6b and openssh 2.9p2 were compiled by myself on
Solaris 8 as 32 bit binaries, I did not compile them for 64 bit.
(The exact same compiler and compiler flags were used...the only extra
flag I used was -g -xarch=v8 so I could use dbx).
2) If I use 0.9.5a of openssl I do not have any of these problems with
the exact same compiler and options. (This is why I think some code
change is causing this problem.
3) I can't get this work on any of our machines, however we do use
custom jumpstart for all of our systems....and maybe something in our
jumpstart image is causing this problem. I may have to build a new
jumpstart image from scratch from the April 2001 Solaris 8 release and
see if that makes a difference. This also happens on our 2.6 machines
(which are also built from jumpstart).
Lukas Ruf reported similar problems. He has a better situation than me,
however....he says compiles work fine on every system except one...in my
case I can't get the DSA stuff to work on any of the machines I am
working with unless I use openssl 0.9.5a. Unless anyone else has any
other ideas..I will try a new jumpstart image and see if that makes a
difference. I would ultimately like to figure out what in Solaris is
causing this not too work....it's starting to seem like some patch on
our systems is causing the problem, but I'm at a loss as to what it
might be...the system I am building on has all the recommended patches
from July 11th and is based on the January 2001 Solaris 8 release.
-Scott
Andy Polyakov wrote:
>
> > > 2) If I use 0.9.5a of openssl I do not have any of these problems with
> > > the exact same compiler and options. (This is why I think some code
> > > change is causing this problem.
> >
> > I do not see any significant code changes in the dsa-code between
> > 0.9.5a and 0.9.6b...
> > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from
> > static DSA_METHOD *default_DSA_method;
> > to
> > static DSA_METHOD *default_DSA_method = NULL;
>
> Oh come on... 'static's are zeroed at startup. But Lutz is right about
> default_DSA_method being the prime suspect for being unaligned. I would
> suggest to setup watchpoint on default_DSA_method and see who's
> modifying it. If you can't do it yourself make executable available for
> download.
>
> Andy.
I have some good news to report:
1) Doing the following worked:
Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from
> > static DSA_METHOD *default_DSA_method;
> > to
> > static DSA_METHOD *default_DSA_method = NULL;
I compiled with -g -xarch=v8 for both openssl 0.9.6b and openssh 2.9p2
with Sun Forte Developer Update 2 and everything worked (with the above
change)! I will be testing -xarch=v9 and 64 bit compilation to see if
that works as well. In any case thanks for the suggestions. I still have
to test the applications, but I will report back on that soon. Just to
be sure I used a clean source tree and tried to compile with the above
options and DSA was broken. If you need anything else from me at this
point let me know. I have already started to build a clean jumpstart
image to test with...what I would like to ultimately determine is why
some people have been able to compile things without going through all
this trouble...I'd hate to see everyone else go through all this
testing, hopefully I can help prevent that.
Thanks again,
Scott
Subject:
Re: Debugging ssh-keygen dsa on Solaris8
Date:
Thu, 26 Jul 2001 12:32:13 +0200
From:
Andy Polyakov <[EMAIL PROTECTED]>
To:
[EMAIL PROTECTED]
References:
1 , 2 , 3 , 4 , 5
> > I have some good news to report:
> >
> > 1) Doing the following worked:
> >
> > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from
> > > > static DSA_METHOD *default_DSA_method;
> > > > to
> > > > static DSA_METHOD *default_DSA_method = NULL;
>
> Ok. I have checked in this change to the OpenSSL repository, so that it
> will be fixed in the next release. Up to then it is a point for the
> FAQ or KNOWN_BUGS section...
There is one thing that is definitely different between 0.9.5 and 0.9.6.
0.9.6 is unconditionally compiled with -[Kf]PIC flag, i.e. regardless
whether or not you intend to produce shared libraries(*). In general it
shouldn't be a problem, it is perfectly possible to statically link PIC
objects (it's even possible to link none-PIC objects into .so
libraries(**)). The fact that we see contradicting report ("nothing
works", "everything works", "works everywhere but one workstation") must
be an indication of a bug in the way PICs are handled which was
eventually fixed (at least there is linker patch #109147-09, updated a
month ago, covering ld.so). One of course may wonder why does explicit
initialization make the the problem go away? Well, it should be noted
that explicit initialization effectively moves the variable from .bss to
.data* segment. Now if buggy ld.so does better job on .data segment(s)
than on .bss segment (at least those parts "belonging" to statically
linked PICs), then...
I wonder if Lukas (<[EMAIL PROTECTED]> who had that only machine
failing to generate DSA key-pair) could run 'showrev -p | grep 109147'
on that machine and others and compare output? What output does Scott
get?
(*) given the output from dbx posted earlier, Scott didn't produce .so
libraries (Scott! Don't!:-)
(**) yes, it is possible to put none-PICs into .so. Run-time linker
shall fix-up all the unresolved references at the cost of making all the
pages containing none-PIC private (kind of obsoletes the idea of .so)
and potentially longer start-up time (because of page privatization and
because there might be way more unresolved references in none-PIC object
than in PIC).
Andy.
Subject:
Re: Debugging ssh-keygen dsa on Solaris8
Date:
Thu, 26 Jul 2001 13:19:08 +0200
From:
Lutz Jaenicke <[EMAIL PROTECTED]>
Organization:
BTU Cottbus, Allgemeine Elektrotechnik
To:
[EMAIL PROTECTED]
References:
1 , 2 , 3 , 4 , 5
On Thu, Jul 26, 2001 at 11:12:42AM +0200, Lutz Jaenicke wrote:
> On Wed, Jul 25, 2001 at 05:09:14PM -0500, Scott Burch wrote:
> Ok. I have checked in this change to the OpenSSL repository, so that it
> will be fixed in the next release. Up to then it is a point for the
> FAQ or KNOWN_BUGS section...
> As it seems to me, there is no workaround OpenSSH could perform.
As Andy Polyakov <[EMAIL PROTECTED]> just pointed out to me in
private
email: There is a workaround: call DSA_set_default_method(NULL) before
calling DSA_new() for the first time.
Best regards,
Lutz
--
Lutz Jaenicke
[EMAIL PROTECTED]
BTU Cottbus
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355
69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355
69-4153
Subject:
Re: Debugging ssh-keygen dsa on Solaris8
Date:
Thu, 26 Jul 2001 19:53:48 +0200
From:
Lutz Jaenicke <[EMAIL PROTECTED]>
Organization:
BTU Cottbus, Allgemeine Elektrotechnik
To:
Scott Burch <[EMAIL PROTECTED]>
References:
1 , 2 , 3 , 4 , 5 , 6
On Thu, Jul 26, 2001 at 12:07:15PM -0500, Scott Burch wrote:
> I will report everything that I find. Where is the best place to report
> everything...is there a procedure I should follow.
Bug reports for OpenSSL may be send to [EMAIL PROTECTED]
Actually, all mails sent there are just forwarded to
[EMAIL PROTECTED],
so you can send it to this address as well.
A lot of people (the openssl-developers team as well :-) reads this
list and bug reports are handled as they are coming in. (Well, most of
the time. Since we don't have a fixed scheme on who will handle which
things, it sometimes happens that nobody takes care of it. In this case
you should just send it again :-) In your case probably I would jump up
because we already worked on these things together...
Best regards,
Lutz
--
Lutz Jaenicke
[EMAIL PROTECTED]
BTU Cottbus
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355
69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355
69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
