Re: [openssl.org #3202] Request to remove _sparcv9_random
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
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
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
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
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
