Error _armv7_tick openssl

Discussion:

Jay D Bhatt

2014-10-10 03:52:18 UTC

Hi ,

I was working on a armv7l architecture platform and was trying to run webruntime related library, but it was crashing _armv7_tick(). So, I did GDB on the wrt binary and below are the logs:

root:/usr/bin> gdb wrt_launchpad_daemon
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-tizen-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/wrt_launchpad_daemon
warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/lib/libthread_db.so.1
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Program received signal SIGILL, Illegal instruction.
0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
(gdb) bt
#0 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
#1 0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0
#2 0x2aab5e0e in call_init () from /lib/ld-linux.so.3
#3 0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3
#4 0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3
#5 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
#6 0x2aab8642 in _dl_open () from /lib/ld-linux.so.3
#7 0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2
#8 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
#9 0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2
#10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2
#11 0x0000a744 in main ()
(gdb) disas _armv7_tick
Dump of assembler code for function _armv7_tick:
=> 0x2e2b76e8 <+0>: mrc 15, 0, r0, cr9, cr13, {0}
0x2e2b76ec <+4>: bx lr
End of assembler dump.

It seems that either the architecture platform is not able to identify the instructions or some other reason, due to which it fails.
Has anyone faced similar problem? Could anybody suggest some solution or patch which can solve this issue?

Thanks,
Jay

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or ***@igate.com <mailto:***@igate.com>. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com <http://www.igate.com>.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fedor Indutny

2014-10-10 09:59:17 UTC

Permalink

Hello!

I'm not a OpenSSL core developer, but anyway here are some thoughts from me.

SIGILL is totally a normal condition, as it is caught by:

https://github.com/openssl/openssl/blob/dabfbea7d91619b286e5d32ffc68ec7e5bd7e9bf/crypto/armcap.c#L96-L101

This is a part of detecting features, so if you wish to get more details -
please enter `continue` after catching SIGILL in gdb.

Thanks,
Fedor.

On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt <***@igate.com> wrote:

> Hi ,
>
>
>
> I was working on a armv7l architecture platform and was trying to run
> webruntime related library, but it was crashing _armv7_tick(). So, I did
> GDB on the wrt binary and below are the logs:
>
>
>
> root:/usr/bin> gdb wrt_launchpad_daemon
>
> GNU gdb (GDB) 7.5.1
>
> Copyright (C) 2012 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "armv7l-tizen-linux-gnueabi".
>
> For bug reporting instructions, please see:
>
> <http://www.gnu.org/software/gdb/bugs/>...
>
> Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols
> found)...done.
>
> (gdb) run
>
> Starting program: /usr/bin/wrt_launchpad_daemon
>
> warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined
> by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
>
> To enable execution of this file add
>
> add-auto-load-safe-path /usr/lib/libthread_db.so.1
>
> line to your configuration file "/root/.gdbinit".
>
> To completely disable this security protection add
>
> set auto-load safe-path /
>
> line to your configuration file "/root/.gdbinit".
>
> For more information about this security protection see the
>
> "Auto-loading safe path" section in the GDB manual. E.g., run from the
> shell:
>
> info "(gdb)Auto-loading safe path"
>
> warning: Unable to find libthread_db matching inferior's thread library,
> thread debugging will not be available.
>
>
>
> Program received signal SIGILL, Illegal instruction.
>
> 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> (gdb) bt
>
> #0 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> #1 0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0
>
> #2 0x2aab5e0e in call_init () from /lib/ld-linux.so.3
>
> #3 0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3
>
> #4 0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3
>
> #5 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #6 0x2aab8642 in _dl_open () from /lib/ld-linux.so.3
>
> #7 0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2
>
> #8 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #9 0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2
>
> #10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2
>
> #11 0x0000a744 in main ()
>
> (gdb) disas _armv7_tick
>
> Dump of assembler code for function _armv7_tick:
>
> => 0x2e2b76e8 <+0>: mrc 15, 0, r0, cr9, cr13, {0}
>
> 0x2e2b76ec <+4>: bx lr
>
> End of assembler dump.
>
>
>
>
>
>
>
> It seems that either the architecture platform is not able to identify the
> instructions or some other reason, due to which it fails.
>
> Has anyone faced similar problem? Could anybody suggest some solution or
> patch which can solve this issue?
>
>
>
> Thanks,
>
> Jay
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or ***@igate.com. IGATE does not enter
> into any agreement with any party by e-mail. Any views expressed by an
> individual do not necessarily reflect the view of IGATE. IGATE is not
> responsible for the consequences of any actions taken on the basis of
> information provided, through this email. The contents of an attachment to
> this e-mail may contain software viruses, which could damage your own
> computer system. While IGATE has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should carry out your own
> virus checks before opening an attachment. To know more about IGATE please
> visit www.igate.com.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

Jay D Bhatt

2014-10-10 11:07:44 UTC

Permalink

Hi Fedor,

If I press âcontinueâ, then also it give segmentation fault. It is not working normally, it exits with seg fault: saying illegal instruction.Could you suggest any other solution? The assembly instruction which I mentioned in my log was identified as illegal instruction.

Thanks,
Jay

From: owner-openssl-***@openssl.org [mailto:owner-openssl-***@openssl.org] On Behalf Of Fedor Indutny
Sent: 10 October 2014 15:29
To: openssl-***@openssl.org
Subject: Re: Error _armv7_tick openssl

Hello!

I'm not a OpenSSL core developer, but anyway here are some thoughts from me.

SIGILL is totally a normal condition, as it is caught by:

https://github.com/openssl/openssl/blob/dabfbea7d91619b286e5d32ffc68ec7e5bd7e9bf/crypto/armcap.c#L96-L101

This is a part of detecting features, so if you wish to get more details - please enter `continue` after catching SIGILL in gdb.

Thanks,
Fedor.

On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt <***@igate.com<mailto:***@igate.com>> wrote:
Hi ,

I was working on a armv7l architecture platform and was trying to run webruntime related library, but it was crashing _armv7_tick(). So, I did GDB on the wrt binary and below are the logs:

root:/usr/bin> gdb wrt_launchpad_daemon
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-tizen-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/wrt_launchpad_daemon
warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/lib/libthread_db.so.1
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Program received signal SIGILL, Illegal instruction.
0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
(gdb) bt
#0 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
#1 0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0
#2 0x2aab5e0e in call_init () from /lib/ld-linux.so.3
#3 0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3
#4 0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3
#5 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
#6 0x2aab8642 in _dl_open () from /lib/ld-linux.so.3
#7 0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2
#8 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
#9 0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2
#10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2
#11 0x0000a744 in main ()
(gdb) disas _armv7_tick
Dump of assembler code for function _armv7_tick:
=> 0x2e2b76e8 <+0>: mrc 15, 0, r0, cr9, cr13, {0}
0x2e2b76ec <+4>: bx lr
End of assembler dump.

It seems that either the architecture platform is not able to identify the instructions or some other reason, due to which it fails.
Has anyone faced similar problem? Could anybody suggest some solution or patch which can solve this issue?

Thanks,
Jay

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or ***@igate.com<mailto:***@igate.com>. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com<http://www.igate.com>.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or ***@igate.com <mailto:***@igate.com>. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com <http://www.igate.com>.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fedor Indutny

2014-10-10 11:34:41 UTC

Permalink

Jay,

I seen the reports of this error on node.js issue tracker, but don't have
any other information about it yet, since I'm unable to reproduce it on my
raspberry pi.

What I tried to say, is that Illegal instruction and the SIGILL is the way
OpenSSL tries to figure out the supported features. It should not be the
source of the bug, just a part of initialisation process. The bug is most
likely happening right after this, when you see the actual crash.

Sorry for not much details,
Fedor.

On Fri, Oct 10, 2014 at 3:07 PM, Jay D Bhatt <***@igate.com> wrote:

> Hi Fedor,
>
>
>
> If I press âcontinueâ, then also it give segmentation fault. It is not
> working normally, it exits with seg fault: saying illegal instruction.Could
> you suggest any other solution? The assembly instruction which I mentioned
> in my log was identified as illegal instruction.
>
>
>
> Thanks,
>
> Jay
>
>
>
> *From:* owner-openssl-***@openssl.org [mailto:
> owner-openssl-***@openssl.org] *On Behalf Of *Fedor Indutny
> *Sent:* 10 October 2014 15:29
> *To:* openssl-***@openssl.org
> *Subject:* Re: Error _armv7_tick openssl
>
>
>
> Hello!
>
>
>
> I'm not a OpenSSL core developer, but anyway here are some thoughts from
> me.
>
>
>
> SIGILL is totally a normal condition, as it is caught by:
>
>
>
>
> https://github.com/openssl/openssl/blob/dabfbea7d91619b286e5d32ffc68ec7e5bd7e9bf/crypto/armcap.c#L96-L101
>
>
>
> This is a part of detecting features, so if you wish to get more details -
> please enter `continue` after catching SIGILL in gdb.
>
>
>
> Thanks,
>
> Fedor.
>
>
>
> On Fri, Oct 10, 2014 at 7:52 AM, Jay D Bhatt <***@igate.com> wrote:
>
> Hi ,
>
>
>
> I was working on a armv7l architecture platform and was trying to run
> webruntime related library, but it was crashing _armv7_tick(). So, I did
> GDB on the wrt binary and below are the logs:
>
>
>
> root:/usr/bin> gdb wrt_launchpad_daemon
>
> GNU gdb (GDB) 7.5.1
>
> Copyright (C) 2012 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "armv7l-tizen-linux-gnueabi".
>
> For bug reporting instructions, please see:
>
> <http://www.gnu.org/software/gdb/bugs/>...
>
> Reading symbols from /usr/bin/wrt_launchpad_daemon...(no debugging symbols
> found)...done.
>
> (gdb) run
>
> Starting program: /usr/bin/wrt_launchpad_daemon
>
> warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined
> by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
>
> To enable execution of this file add
>
> add-auto-load-safe-path /usr/lib/libthread_db.so.1
>
> line to your configuration file "/root/.gdbinit".
>
> To completely disable this security protection add
>
> set auto-load safe-path /
>
> line to your configuration file "/root/.gdbinit".
>
> For more information about this security protection see the
>
> "Auto-loading safe path" section in the GDB manual. E.g., run from the
> shell:
>
> info "(gdb)Auto-loading safe path"
>
> warning: Unable to find libthread_db matching inferior's thread library,
> thread debugging will not be available.
>
>
>
> Program received signal SIGILL, Illegal instruction.
>
> 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> (gdb) bt
>
> #0 0x2ea486e8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
>
> #1 0x2ea460ac in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0
>
> #2 0x2aab5e0e in call_init () from /lib/ld-linux.so.3
>
> #3 0x2aab5ea0 in _dl_init_internal () from /lib/ld-linux.so.3
>
> #4 0x2aab8c26 in dl_open_worker () from /lib/ld-linux.so.3
>
> #5 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #6 0x2aab8642 in _dl_open () from /lib/ld-linux.so.3
>
> #7 0x2c1dab00 in dlopen_doit () from /usr/lib/libdl.so.2
>
> #8 0x2aab5d2a in _dl_catch_error () from /lib/ld-linux.so.3
>
> #9 0x2c1daf54 in _dlerror_run () from /usr/lib/libdl.so.2
>
> #10 0x2c1dab8a in dlopen@@GLIBC_2.4 () from /usr/lib/libdl.so.2
>
> #11 0x0000a744 in main ()
>
> (gdb) disas _armv7_tick
>
> Dump of assembler code for function _armv7_tick:
>
> => 0x2e2b76e8 <+0>: mrc 15, 0, r0, cr9, cr13, {0}
>
> 0x2e2b76ec <+4>: bx lr
>
> End of assembler dump.
>
>
>
>
>
>
>
> It seems that either the architecture platform is not able to identify the
> instructions or some other reason, due to which it fails.
>
> Has anyone faced similar problem? Could anybody suggest some solution or
> patch which can solve this issue?
>
>
>
> Thanks,
>
> Jay
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or ***@igate.com. IGATE does not enter
> into any agreement with any party by e-mail. Any views expressed by an
> individual do not necessarily reflect the view of IGATE. IGATE is not
> responsible for the consequences of any actions taken on the basis of
> information provided, through this email. The contents of an attachment to
> this e-mail may contain software viruses, which could damage your own
> computer system. While IGATE has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should carry out your own
> virus checks before opening an attachment. To know more about IGATE please
> visit www.igate.com.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Information contained and transmitted by this e-mail is confidential and
> proprietary to IGATE and its affiliates and is intended for use only by the
> recipient. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution, copying or use of this e-mail is
> strictly prohibited and you are requested to delete this e-mail immediately
> and notify the originator or ***@igate.com. IGATE does not enter
> into any agreement with any party by e-mail. Any views expressed by an
> individual do not necessarily reflect the view of IGATE. IGATE is not
> responsible for the consequences of any actions taken on the basis of
> information provided, through this email. The contents of an attachment to
> this e-mail may contain software viruses, which could damage your own
> computer system. While IGATE has taken every reasonable precaution to
> minimise this risk, we cannot accept liability for any damage which you
> sustain as a result of software viruses. You should carry out your own
> virus checks before opening an attachment. To know more about IGATE please
> visit www.igate.com.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

Andy Polyakov

2014-10-10 15:15:37 UTC

Permalink

> If I press ‘continue’, then also it give segmentation fault. It is not
> working normally, it exits with seg fault: saying illegal
> instruction.

??? Segmentation fault != illegal instruction. What does "exits with seg
fault saying illegal instruction" mean? Where is the segmentation fault?

> Could you suggest any other solution? The assembly
> instruction which I mentioned in my log was identified as illegal
> instruction.

https://www.openssl.org/support/faq.html#PROG17. There are two options
listed.

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

Misaki.Miyashita

2014-10-10 16:02:20 UTC

Permalink

On 10/10/14 10:15, Andy Polyakov wrote:
>> If I press ‘continue’, then also it give segmentation fault. It is not
>> working normally, it exits with seg fault: saying illegal
>> instruction.
> ??? Segmentation fault != illegal instruction. What does "exits with seg
> fault saying illegal instruction" mean? Where is the segmentation fault?
>
>> Could you suggest any other solution? The assembly
>> instruction which I mentioned in my log was identified as illegal
>> instruction.
> https://www.openssl.org/support/faq.html#PROG17. There are two options
> listed.

As Fedor mentioned, it is expected to see some SIGILL at the beginning
of the OpenSSL application as that's how OpenSSL checks the hardware
capabilities. If you are running your application with a debugger, a
debugger may catch SIGILL signals multiple times, so you may have to hit
"continue" multiple times to resume.

As explained in the FAQ page listed by Andy, you can workaround it by:

/@ == gdb ==/
/@ adding 'handle SIGILL nostop' to your .gdbinit./

/@ == mdb ==/
/@ running '4:i' at the mdb prompt./

Once you set the workaround, the debugger ignores SIGILL so that you
don't have to hit "continue".

-- misaki

Oracle Solaris Security
Senior Software Engineer
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

Peter Waltenberg

2014-10-11 00:21:13 UTC

Permalink

ARM is one of those awkward processors, the event counter isn't always directly readable from userspace, if it's not directly readable you get an illegal instruction trap. A syscall to access the event counters is only present in recent kernels. And even more fun, the event counter data is only readable from the thread that enabled the event counters. 
 The bad news is that without  the event counters, there are no good entropy sources - and dying with a segv is likely the best possible outcome. 
 Peter This  code works (for a certain value of 'work') on recent kernels. 
 #elif defined(__ARMEL__) || defined(__ARMEB__) /* ARM */ 
#include <stdlib.h> #include <stdio.h> #include <unistd.h> 
#include <string.h> #include <sys/ioctl.h> #include <linux/perf_event.h> 
#include <asm/unistd.h> static inline long long armtick(void) 
{   int fddev = -1;  long long result = 0;  static struct perf_event_attr attr; 
 attr.type = PERF_TYPE_HARDWARE;  attr.config = PERF_COUNT_HW_CPU_CYCLES; 
 fddev = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0); 
 if (read(fddev, &result, sizeof(result)) < sizeof(result)) return 0; 
 close(fddev);  return result; } Not exactly efficient. 
 Peter -----owner-openssl-***@openssl.org wrote: -----
<div style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">
To: openssl-***@openssl.org From: Andy Polyakov <***@openssl.org> 
Sent by: owner-openssl-***@openssl.org Date: 10/11/2014 01:17AM Subject: Re: Error _armv7_tick openssl 
 <div>> If I press ‘continue’, then also it give segmentation fault. It is not 
> working normally, it exits with seg fault: saying illegal > instruction. 
 ??? Segmentation fault != illegal instruction. What does "exits with seg 
fault saying illegal instruction" mean? Where is the segmentation fault? 
 > Could you suggest any other solution? The assembly > instruction which I mentioned in my log was identified as illegal 
> instruction. <a href="https://www.openssl.org/support/faq.html#PROG17">
https://www.openssl.org/support/faq.html#PROG17</a>. There are two options 
listed. ______________________________________________________________________ 
OpenSSL Project                                 <a href="http://www.openssl.org">
http://www.openssl.org</a> Development Mailing List                       openssl-***@openssl.org 
Automated List Manager                           ***@openssl.org 
 </div></***@openssl.org></div></div>

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