Andy Polyakov via RT a écrit :
> Hi,

        Hello,

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

>> 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 (!).

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

        Regards,

        JKB


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

Reply via email to