Andy Polyakov via RT a écrit :
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'.
I'll do it, but I have to rebuild openssl without no-asm. I have no
time to rebuild and test this evening, but I shall test as soon as possible.
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 agree, but I don't understand why :
- with printf() in signal handler, signal handler is called ;
- without printf() in signal handler, SIGILL is not caught.
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.
Yes, but by default, userland is only 32 bits on linux/sparc and I
don't understand why you check sparcv9 instructions in 32 bits mode. My
OpenSSL library is built in 32 bits mode.
As for generalization to Solaris. Is it possible that by the time you
had problem on Solaris it was another problem?
Maybe, but I'm not sure. SIGILL comes from same instruction (only in 32
bits mode). If I remember, openssl worked fine in 64 bits.
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.
Regards,
JKB
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
