>>> I see a very strange bug in crypto/sparcv9cap.c. OpenSSL 1.0.0d checks
>>> sparc capabilities with SIGILL signal. On sparc64 (both Linux and
>>> solaris, with UltraSPARC III+ and T1 CPU's), SIGILL handler is called
>>> and program terminates with SIGILL in _sparcv9_fmadd_probe:
>>>
>>> 00000001002a32d0<_sparcv9_fmadd_probe>:
>>> 1002a32d0: 81 b0 0d 80 impdep1 108, %f0, %f0, %f0
>>> 1002a32d4: 85 b0 8d 82 impdep1 108, %f2, %f2, %f2
>>> 1002a32d8: 81 c3 e0 08 retl
>>> 1002a32dc: 81 b8 04 40 impdep2 34, %f0, %f0, %f0<= here
>>>
>>> If I add printf() in signal handler, I see that it is called, and that
>>> siglongjmp() works. With my printf(), my program doesn't abort with
>>> SIGILL anymore but with SIGBUS (?!).
>> Could you 'truss -v sigaction,sigprocmask apps/openssl version' and
>> submit output?
>
> I cannot. My server doesn't run Solaris but Linux/sparc. I just have
> seen the same bug a long time ago on Solaris but I don't have any
> solaris server anymore.
Then run 'strace -v apps/openssl version'.
>>> Modifications :
>>> static void common_handler(int sig)
>>> { printf("Signal handler\n"); siglongjmp(common_jmp,sig); }
>>>
>>> I don't understand why, with this trivial modification, my program run
>>> fine (and of course prints "Signal handler" on stdout).
>> I don't understand. First use say that it fails with SIBUS (instead of
>> expected SIGILL) and then you say that program runs fine. Could you be
>> kind to clarify?
>
> OpenSSL uses SIGILL signal handler to check processor capabilities. Out
> of the box, OpenSSL library aborts during initialization with SIGILL.
> And if you check inside sources, you'll see that this SIGILL has to be
> catch by a signal handler.
>
> To debug, I have added a simple printf() in this signal handler and I
> have seen that it is called when SIGILL is raised. But I obtain a new
> SIGBUS signal (!).
And SIGBUS should be caught too. In other words it does not work, i.e.
program does *not* "run fine", right?
>>> I have seen this bug some months ago (dec 2010) on a sparc T1 running
>>> Solaris, but I'm not able to remember how I have fixed this trouble...
>> But do you have binary left? In worst case one (I) can disassemble it
>> and identify the change... Not that I really understand what's going on,
>> as I can't reproduce the problem on UltraSPARC-IIe and III...
>
> I don't have, sorry. But I'm pretty sure that this bug is in sparc
> assembly.
The code was verified to work on US-IIe and III on Solaris. At some
point I had opportunity to test the signal catching even on US-T1
running Linux, but I'm not sure if check for fmadd was added later or
not. But either way it sounds more like signal mask getting screwed up
[than bug in machine code], if you set up SIGILL handler and mask it,
the program will be terminated as if handler was not set.
As for generalization to Solaris. Is it possible that by the time you
had problem on Solaris it was another problem? There was
Solaris-specific problem with sparcv9cap.c fixed last year. It was found
that libdevinfo.so was buggy and the code was abandoned in favour of
generic SIGILL-based detection.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
