Re: [openssl.org #3202] Request to remove _sparcv9_random

[Misaki.Miyashita]

... The SPARC random
instruction was never implemented and never will be implemented.

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae19021

As for getisax. One of limiting factors is ability to test and perform
regression tests. We don't have access to hardware running SPARC Solaris
(anymore) and for this reason something we can test elsewhere [i.e.
current exception-based procedure] is actually preferable.



Thanks for looking into the bug, Andy.

We like your proposed fix, especially the nice block of explanation and 
workaround  in the FAQ.

We appreciate it if you can integrate the fix.

Regards,

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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Misaki.Miyashita via RT]

 ... The SPARC random
 instruction was never implemented and never will be implemented.
 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae19021

 As for getisax. One of limiting factors is ability to test and perform
 regression tests. We don't have access to hardware running SPARC Solaris
 (anymore) and for this reason something we can test elsewhere [i.e.
 current exception-based procedure] is actually preferable.


Thanks for looking into the bug, Andy.

We like your proposed fix, especially the nice block of explanation and 
workaround  in the FAQ.
We appreciate it if you can integrate the fix.

Regards,

Misaki Miyashita


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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Andy Polyakov via RT]

Feels like Oracle convention all of a sudden...

 I think we need to clarify why this should be done.

The lesson is to always report underlying reasons. Because as we see 
here, it might turn out misleading.

 ... The SPARC random 
 instruction was never implemented and never will be implemented.

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=926725b3d7c1528f2dc116a48623c42264188277
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=e79d34c24b96943ae653dc93371bcae19021

As for getisax. One of limiting factors is ability to test and perform 
regression tests. We don't have access to hardware running SPARC Solaris 
(anymore) and for this reason something we can test elsewhere [i.e. 
current exception-based procedure] is actually preferable.


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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Dan Anderson]

On 12/26/13 08:03 PM, David Miller wrote:

From: Valerie Anne Bubb Fenwick valerie.fenw...@oracle.com
Date: Thu, 26 Dec 2013 15:46:42 -0800


both Dan and Misaki have noted, though, that this specific SPARC
instruction OpenSSL is checking for never existed and will never
exist in any SPARC chipset that Sun/Oracle shipped.  Could we at
least remove that check?  That capability does not and will not
exist, so it seems a waste of cycles to check (and confuses users,
we get lots of questions about this specific instruction and
why it doesn't work or which platform it should work on)

Does that make sense?  thanks!

I'm against this on fundamental grounds, you are just pushing the
problem around rather than truly fixing the issue.

I know what you want, you want the SIGILL to not happen on the systems
you most care about, and this is how you're going to go about doing it
rather than solving this issue at it's core.  In the debugger.

That's really distasteful to me.  Please fix things properly, rather
than chase after a scarecrow like this random instruction.


Hi David,

I really don't understand the desire to preserve dead, never-used code 
in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never 
used it and never can use it, but you don't want to remove the check for 
it. It seems silly to me.


Dan




--
uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller]

From: Dan Anderson dan.ander...@oracle.com
Date: Fri, 27 Dec 2013 09:37:10 -0800

 I really don't understand the desire to preserve dead, never-used code
 in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
 used it and never can use it, but you don't want to remove the check
 for it. It seems silly to me.

Ok, how about we replace the random instruction detection with an
explicit forced illegal instruction test early in the sparc init code
that makes sure the SIGILL facility is working properly?

That is, we'll unconditionally and always generate a SIGILL every time
openssl is used.

I'm perfectly fine with that, but you guys will be in the same
position you are now, having to cope with the debugger issue.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Dan Anderson]

On 12/27/13 10:46 AM, David Miller wrote:

From: Dan Anderson dan.ander...@oracle.com
Date: Fri, 27 Dec 2013 09:37:10 -0800


I really don't understand the desire to preserve dead, never-used code
in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
used it and never can use it, but you don't want to remove the check
for it. It seems silly to me.

Ok, how about we replace the random instruction detection with an
explicit forced illegal instruction test early in the sparc init code
that makes sure the SIGILL facility is working properly?


Hi Dave,

That's fine--it's not all that we want (a Solaris-specific use of 
getisax()), but a half-a-loaf is better than none. At least a 
never-conceived SPARC instruction would not be checked for in OpenSSL.


A separate bug on the debugger will be filed separately.

BTW, we appreciate your SPARC contributions to OpenSSL in the past.

Dan



That is, we'll unconditionally and always generate a SIGILL every time
openssl is used.

I'm perfectly fine with that, but you guys will be in the same
position you are now, having to cope with the debugger issue.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org



--
uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Tom Kacvinsky]

There is a way to turn off break at SIGILL, at least in mdb, based on the
reading I've done


On Fri, Dec 27, 2013 at 1:46 PM, David Miller da...@davemloft.net wrote:

 From: Dan Anderson dan.ander...@oracle.com
 Date: Fri, 27 Dec 2013 09:37:10 -0800

  I really don't understand the desire to preserve dead, never-used code
  in OpenSSL. The SPARC random instruction doesn't exist, OpenSSL never
  used it and never can use it, but you don't want to remove the check
  for it. It seems silly to me.

 Ok, how about we replace the random instruction detection with an
 explicit forced illegal instruction test early in the sparc init code
 that makes sure the SIGILL facility is working properly?

 That is, we'll unconditionally and always generate a SIGILL every time
 openssl is used.

 I'm perfectly fine with that, but you guys will be in the same
 position you are now, having to cope with the debugger issue.
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Misaki Miyashita]

Sorry for the late reply.

Checking for chip capabilities by calling an invalid instruction causes an 
issue especially when people run debugger with an OpenSSL application.

That can be easily avoided by calling getisax(2) for SPARC, as Dan Anderson 
noted.

Please consider determining the chip capabilities for SPARC by calling 
getisax(2) instead of causing and catching SIGILL.
(For RNG, we'll never support the random instruction, and it can be just 
removed).

Thank you

-- misaki


- dan.ander...@oracle.com wrote:

 On 12/21/2013 7:07 PM, David Miller via RT wrote:
  From: Dan Anderson dan.ander...@oracle.com
  Date: Sat, 21 Dec 2013 17:54:52 -0800
 
  I think we need to clarify why this should be done. The SPARC
 random
  instruction was designed at Sun Microsystems (now Oracle
 Corporation)
  for a never-released processor several years ago. For SPARC,
  randomness is obtained by reading a special control register. The
  SPARC random instruction was never implemented and never will be
  implemented. Please remove code to detect this instruction.
 Thanks!
  The patch was presented as a way to get rid of SIGILL dropping the
  application into the debugger.
 
 True, but forget this for the sake of argument.
 
  The same problem is going to exist if people run this library on
  chips without the crypto instructions, or other ones we check for.
 
 You are checking for a SPARC instruction that was never implemented,
 is 
 not on any SPARC processor, and never will exist.
 
 All I'm suggesting is to not check for this instruction.
 
 Dan
 
 
 
 
 __
  OpenSSL Project
 http://www.openssl.org
  Development Mailing List  
 openssl-dev@openssl.org
  Automated List Manager  
 majord...@openssl.org
 
 
 -- 
 uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1
 858-526-9418
 
 __
 OpenSSL Project
 http://www.openssl.org
 Development Mailing List  
 openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller]

From: Misaki Miyashita misaki.miyash...@oracle.com
Date: Thu, 26 Dec 2013 15:11:49 -0800 (PST)

 Checking for chip capabilities by calling an invalid instruction
 causes an issue especially when people run debugger with an OpenSSL
 application.

As has already been discussed in this thread, that's a debugger
problem.

 Please consider determining the chip capabilities for SPARC by
 calling getisax(2) instead of causing and catching SIGILL.  (For
 RNG, we'll never support the random instruction, and it can be just
 removed).

Again, as already discussed in this thread, the SIGILL technique
is portable across all operating systems, whereas getisax() is
not.

I really think you should work on getting the debugger to cope with
this SIGILL signal cleanly, rather than continuing to beat a dead
horse here.  This technique is quite common across libraries that
need to test for cpu instruction availability.

Thank you.

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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Valerie Anne Bubb Fenwick]

On 12/26/13 3:29 PM, David Miller wrote:

From: Misaki Miyashita misaki.miyash...@oracle.com
Date: Thu, 26 Dec 2013 15:11:49 -0800 (PST)


Checking for chip capabilities by calling an invalid instruction
causes an issue especially when people run debugger with an OpenSSL
application.


As has already been discussed in this thread, that's a debugger
problem.


Please consider determining the chip capabilities for SPARC by
calling getisax(2) instead of causing and catching SIGILL.  (For
RNG, we'll never support the random instruction, and it can be just
removed).


Again, as already discussed in this thread, the SIGILL technique
is portable across all operating systems, whereas getisax() is
not.

I really think you should work on getting the debugger to cope with
this SIGILL signal cleanly, rather than continuing to beat a dead
horse here.  This technique is quite common across libraries that
need to test for cpu instruction availability.


Hi David -

both Dan and Misaki have noted, though, that this specific SPARC
instruction OpenSSL is checking for never existed and will never
exist in any SPARC chipset that Sun/Oracle shipped.  Could we at
least remove that check?  That capability does not and will not
exist, so it seems a waste of cycles to check (and confuses users,
we get lots of questions about this specific instruction and
why it doesn't work or which platform it should work on)

Does that make sense?  thanks!


Valerie

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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller]

From: Valerie Anne Bubb Fenwick valerie.fenw...@oracle.com
Date: Thu, 26 Dec 2013 15:46:42 -0800

 both Dan and Misaki have noted, though, that this specific SPARC
 instruction OpenSSL is checking for never existed and will never
 exist in any SPARC chipset that Sun/Oracle shipped.  Could we at
 least remove that check?  That capability does not and will not
 exist, so it seems a waste of cycles to check (and confuses users,
 we get lots of questions about this specific instruction and
 why it doesn't work or which platform it should work on)
 
 Does that make sense?  thanks!

I'm against this on fundamental grounds, you are just pushing the
problem around rather than truly fixing the issue.

I know what you want, you want the SIGILL to not happen on the systems
you most care about, and this is how you're going to go about doing it
rather than solving this issue at it's core.  In the debugger.

That's really distasteful to me.  Please fix things properly, rather
than chase after a scarecrow like this random instruction.

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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Valerie Anne Bubb Fenwick]

On 12/26/13 8:03 PM, David Miller wrote:

From: Valerie Anne Bubb Fenwick valerie.fenw...@oracle.com
Date: Thu, 26 Dec 2013 15:46:42 -0800


both Dan and Misaki have noted, though, that this specific SPARC
instruction OpenSSL is checking for never existed and will never
exist in any SPARC chipset that Sun/Oracle shipped.  Could we at
least remove that check?  That capability does not and will not
exist, so it seems a waste of cycles to check (and confuses users,
we get lots of questions about this specific instruction and
why it doesn't work or which platform it should work on)

Does that make sense?  thanks!


I'm against this on fundamental grounds, you are just pushing the
problem around rather than truly fixing the issue.

I know what you want, you want the SIGILL to not happen on the systems
you most care about, and this is how you're going to go about doing it
rather than solving this issue at it's core.  In the debugger.

That's really distasteful to me.  Please fix things properly, rather
than chase after a scarecrow like this random instruction.


Hi David -

I'm sorry, that is not my intent. We really do get frequent questions about
this and it confuses users (who on one occasion at least tried to add the
instruction to other programs that used this as an example). This has been
popping up more lately, not sure why. These things seem to come in waves.

We can of course file bugs against the known impacted debuggers as
well as we get reports.  Obviously, we don't control those source bases,
but we are happy to make suggestions and file bugs as we come across
issues.  I will make sure the bugs get filed.

I now understand your concerns with wanting keep the code portable
in the most straight forward way, thank you for taking the time
to explain that portion of our initial request.

I hope that makes more sense, I am sorry I was not more clear with my
first message.  Does that make more sense?

Valerie



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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Peter Waltenberg]

FWIW. We have a similar problem on AIX with the capability probes there. The debugger has an 'ignore' option - which allows us to bypass the sigill traps.I can understand the logic of not probing for an instruction that'll never exist, but some archictectures you WILL hit this problem as there's no other way to do capability probes in user space code. All you can do there is hope the debugger has some way of coping.Peter-owner-openssl-...@openssl.org wrote: -To: David Miller da...@davemloft.netFrom: Dan Anderson Sent by: owner-openssl-...@openssl.orgDate: 12/22/2013 03:37PMCc: openssl-dev@openssl.orgSubject: Re: [openssl.org #3202] Request to remove _sparcv9_randomOn 12/21/2013 7:07 PM, David Miller via RT wrote: From: Dan Anderson dan.ander...@oracle.com Date: Sat, 21 Dec 2013 17:54:52 -0800 I think we need to clarify why this should be done. The SPARC "random" instruction was designed at Sun Microsystems (now Oracle Corporation) for a never-released processor several years ago. For SPARC, randomness is obtained by reading a special control register. The SPARC "random" instruction was never implemented and never will be implemented. Please remove code to detect this instruction. Thanks! The patch was presented as a way to get rid of SIGILL dropping the application into the debugger.True, but forget this for the sake of argument. The same problem is going to exist if people run this library on chips without the crypto instructions, or other ones we check for.You are checking for a SPARC instruction that was never implemented, is not on any SPARC processor, and never will exist.All I'm suggesting is to not check for this instruction.Dan __ OpenSSL Project http://www.openssl.org Development Mailing Listopenssl-dev@openssl.org Automated List Manager  majord...@openssl.org-- uospu up dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418__OpenSSL Project http://www.openssl.orgDevelopment Mailing Listopenssl-dev@openssl.orgAutomated List Manager  majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Dan Anderson]

On 12/20/2013 10:29 AM, David Miller wrote:

From: Misaki.Miyashita via RT r...@openssl.org
Date: Fri, 20 Dec 2013 06:59:18 +0100


Hi,

We don't have RNG instructions, and calling _sparcv9_random() causes
SIGILL and debug tools (i.e. gdb and mdb) stops when libcrypto.so is
loaded (at _init()).
% mdb `which openssl`
   ::run
mdb: stop on SIGILL
mdb: target stopped at:
libcrypto.so.1.0.0`_sparcv9_random+4:   random%d8

Do not do this, the instruction is valid and we'd like to detect
the presence of it on chips that actually have it.f


David,

I think we need to clarify why this should be done. The SPARC random 
instruction was designed at Sun Microsystems (now Oracle Corporation) 
for a never-released processor several years ago. For SPARC, randomness 
is obtained by reading a special control register. The SPARC random 
instruction was never implemented and never will be implemented. Please 
remove code to detect this instruction. Thanks!


Dan




We use SIGILL sequence to detect presence for all crypto instructions,
so if your logic would apply to all of the instructions we try to
detect.

This is the standard way that openssl probes for instruction
presence.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org



--
uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418

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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Dan Anderson via RT]

On 12/20/2013 10:29 AM, David Miller wrote:
 From: Misaki.Miyashita via RT r...@openssl.org
 Date: Fri, 20 Dec 2013 06:59:18 +0100

 Hi,

 We don't have RNG instructions, and calling _sparcv9_random() causes
 SIGILL and debug tools (i.e. gdb and mdb) stops when libcrypto.so is
 loaded (at _init()).
 % mdb `which openssl`
::run
 mdb: stop on SIGILL
 mdb: target stopped at:
 libcrypto.so.1.0.0`_sparcv9_random+4:   random%d8
 Do not do this, the instruction is valid and we'd like to detect
 the presence of it on chips that actually have it.f

David,

I think we need to clarify why this should be done. The SPARC random 
instruction was designed at Sun Microsystems (now Oracle Corporation) 
for a never-released processor several years ago. For SPARC, randomness 
is obtained by reading a special control register. The SPARC random 
instruction was never implemented and never will be implemented. Please 
remove code to detect this instruction. Thanks!

Dan



 We use SIGILL sequence to detect presence for all crypto instructions,
 so if your logic would apply to all of the instructions we try to
 detect.

 This is the standard way that openssl probes for instruction
 presence.
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org


-- 
uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418


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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Dan Anderson]

On 12/21/2013 5:54 PM, Dan Anderson wrote:

On 12/20/2013 10:29 AM, David Miller wrote:

From: Misaki.Miyashita via RT r...@openssl.org
Date: Fri, 20 Dec 2013 06:59:18 +0100


Hi,

We don't have RNG instructions, and calling _sparcv9_random() causes
SIGILL and debug tools (i.e. gdb and mdb) stops when libcrypto.so is
loaded (at _init()).
% mdb `which openssl`
   ::run
mdb: stop on SIGILL
mdb: target stopped at:
libcrypto.so.1.0.0`_sparcv9_random+4:   random%d8

Do not do this, the instruction is valid and we'd like to detect
the presence of it on chips that actually have it.f


David,

I think we need to clarify why this should be done. The SPARC random 
instruction was designed at Sun Microsystems (now Oracle Corporation) 
for a never-released processor several years ago. For SPARC, 
randomness is obtained by reading a special control register. The 
SPARC random instruction was never implemented and never will be 
implemented. Please remove code to detect this instruction. Thanks!


Dan


P.S., as a separate issue, please consider using the Solaris getisax(2) 
to determine SPARC processor features.


Dan






We use SIGILL sequence to detect presence for all crypto instructions,
so if your logic would apply to all of the instructions we try to
detect.

This is the standard way that openssl probes for instruction
presence.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org






--
uosบǝpuɐ uɐp dan.ander...@oracle.com, Oracle Solaris, San Diego, +1 858-526-9418

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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller]

From: Dan Anderson dan.ander...@oracle.com
Date: Sat, 21 Dec 2013 17:54:52 -0800

 I think we need to clarify why this should be done. The SPARC random
 instruction was designed at Sun Microsystems (now Oracle Corporation)
 for a never-released processor several years ago. For SPARC,
 randomness is obtained by reading a special control register. The
 SPARC random instruction was never implemented and never will be
 implemented. Please remove code to detect this instruction. Thanks!

The patch was presented as a way to get rid of SIGILL dropping the
application into the debugger.

The same problem is going to exist if people run this library on
chips without the crypto instructions, or other ones we check for.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller via RT]

From: Dan Anderson dan.ander...@oracle.com
Date: Sat, 21 Dec 2013 17:54:52 -0800

 I think we need to clarify why this should be done. The SPARC random
 instruction was designed at Sun Microsystems (now Oracle Corporation)
 for a never-released processor several years ago. For SPARC,
 randomness is obtained by reading a special control register. The
 SPARC random instruction was never implemented and never will be
 implemented. Please remove code to detect this instruction. Thanks!

The patch was presented as a way to get rid of SIGILL dropping the
application into the debugger.

The same problem is going to exist if people run this library on
chips without the crypto instructions, or other ones we check for.


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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller]

From: Dan Anderson dan.ander...@oracle.com
Date: Sat, 21 Dec 2013 17:57:02 -0800

 P.S., as a separate issue, please consider using the Solaris
 getisax(2) to determine SPARC processor features.

The SIGILL mechanism is portable and works on every OS, not
just Solaris.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller]

From: Misaki.Miyashita via RT r...@openssl.org
Date: Fri, 20 Dec 2013 06:59:18 +0100

 Hi,
 
 We don't have RNG instructions, and calling _sparcv9_random() causes 
 SIGILL and debug tools (i.e. gdb and mdb) stops when libcrypto.so is 
 loaded (at _init()).
 % mdb `which openssl`
   ::run
 mdb: stop on SIGILL
 mdb: target stopped at:
 libcrypto.so.1.0.0`_sparcv9_random+4:   random%d8

Do not do this, the instruction is valid and we'd like to detect
the presence of it on chips that actually have it.

We use SIGILL sequence to detect presence for all crypto instructions,
so if your logic would apply to all of the instructions we try to
detect.

This is the standard way that openssl probes for instruction 
presence.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3202] Request to remove _sparcv9_random

[David Miller via RT]

From: Misaki.Miyashita via RT r...@openssl.org
Date: Fri, 20 Dec 2013 06:59:18 +0100

 Hi,
 
 We don't have RNG instructions, and calling _sparcv9_random() causes 
 SIGILL and debug tools (i.e. gdb and mdb) stops when libcrypto.so is 
 loaded (at _init()).
 % mdb `which openssl`
   ::run
 mdb: stop on SIGILL
 mdb: target stopped at:
 libcrypto.so.1.0.0`_sparcv9_random+4:   random%d8

Do not do this, the instruction is valid and we'd like to detect
the presence of it on chips that actually have it.

We use SIGILL sequence to detect presence for all crypto instructions,
so if your logic would apply to all of the instructions we try to
detect.

This is the standard way that openssl probes for instruction 
presence.


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

Re: [openssl.org #3202] Request to remove _sparcv9_random

[Kurt Roeckx via RT]

On Fri, Dec 20, 2013 at 01:29:39PM -0500, David Miller wrote:
 From: Misaki.Miyashita via RT r...@openssl.org
 Date: Fri, 20 Dec 2013 06:59:18 +0100
 
  Hi,
  
  We don't have RNG instructions, and calling _sparcv9_random() causes 
  SIGILL and debug tools (i.e. gdb and mdb) stops when libcrypto.so is 
  loaded (at _init()).
  % mdb `which openssl`
::run
  mdb: stop on SIGILL
  mdb: target stopped at:
  libcrypto.so.1.0.0`_sparcv9_random+4:   random%d8
 
 Do not do this, the instruction is valid and we'd like to detect
 the presence of it on chips that actually have it.
 
 We use SIGILL sequence to detect presence for all crypto instructions,
 so if your logic would apply to all of the instructions we try to
 detect.
 
 This is the standard way that openssl probes for instruction 
 presence.

I keep running into people having this problem when trying to
debug something.  Maybe this should get added to the FAQ?


Kurt


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

[openssl.org #3202] Request to remove _sparcv9_random

[Misaki.Miyashita via RT]

Hi,

We don't have RNG instructions, and calling _sparcv9_random() causes 
SIGILL and debug tools (i.e. gdb and mdb) stops when libcrypto.so is 
loaded (at _init()).
% mdb `which openssl`
  ::run
mdb: stop on SIGILL
mdb: target stopped at:
libcrypto.so.1.0.0`_sparcv9_random+4:   random%d8


Without those debugging tools, it's very hard to do any debugging, and 
we would like the call to be removed.

The following suggested fix seems to fix the problem we are having with 
the debugging tools.


*--- sparc_arch.h.orig   Thu Dec 19 14:37:27 2013
+++ sparc_arch.hThu Dec 19 14:37:45 2013*
@@ -8,7 +8,6 @@
  #defineSPARCV9_FMADD   (14)  /* reserved for SPARC64 
V */
  #defineSPARCV9_BLK (15)  /* VIS1 block copy */
  #defineSPARCV9_VIS3(16)
-#defineSPARCV9_RANDOM  (17)
  #defineSPARCV9_64BIT_STACK (18)

  /*

*--- sparccpuid.S.orig Thu Dec 19 14:34:25 2013
+++ sparccpuid.SThu Dec 19 14:34:25 2013*
@@ -341,14 +341,6 @@
  .type  _sparcv9_vis3_probe,#function
  .size  _sparcv9_vis3_probe,.-_sparcv9_vis3_probe

-.global_sparcv9_random
-.align 8
-_sparcv9_random:
-   retl
-   .word   0x91b002a0  !random %o0
-.type  _sparcv9_random,#function
-.size  _sparcv9_random,.-_sparcv9_vis3_probe
-
  .globalOPENSSL_cleanse
  .align 32
  OPENSSL_cleanse:

*--- sparcv9cap.c.orig Thu Dec 19 14:34:25 2013
+++ sparcv9cap.cThu Dec 19 14:34:25 2013*
@@ -62,7 +62,6 @@
  void   _sparcv9_fmadd_probe(void);
  unsigned long  _sparcv9_rdcfr(void);
  void   _sparcv9_vis3_probe(void);
-unsigned long  _sparcv9_random(void);
  #ifndef _BOOT
  size_t _sparcv9_vis1_instrument_bus(unsigned int *,size_t);
  size_t _sparcv9_vis1_instrument_bus2(unsigned int 
*,size_t,size_t);
@@ -305,12 +304,6 @@
 OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS3;
 }

-   if (sigsetjmp(common_jmp,1) == 0)
-   {
-   (void)_sparcv9_random();
-   OPENSSL_sparcv9cap_P[0] |= SPARCV9_RANDOM;
-   }
-
 /*
  * In wait for better solution _sparcv9_rdcfr is masked by
  * VIS3 flag, because it goes to uninterruptable endless



Thank you

-- misaki


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