Re: openssl 1.1.1k on solaris 2.6 sparc
Michael Wojcik wrote: From: openssl-users On Behalf Of david raingeard Sent: Thursday, 24 June, 2021 07:06 I compiled it using sun compiler, with some modifications to the source code. If memory serves, OpenSSL doesn't work on Solaris SPARC if built using the Sun compiler. You have to use GCC. I'm pretty sure we discovered this in our SPARC product builds. This, and some other platform issues (there's one with GCC optimization on x86 64-bit, the details of which escape me now), are things I keep hoping to find time to dig into, but more-pressing work never seems to ease up. -- Michael Wojcik You can build it on Solaris 10 SPARC, using Studio 12.2 for 32 bit, and Studio 12.4 for 64 bit. Make sure that these are fully patched up. -- Jeff Wieland, UNIX Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms
Re: building openssl 1.1.1 for Solaris 10
Michael Wojcik wrote: From: tim.j.culh...@gmail.com [mailto:tim.j.culh...@gmail.com] Sent: Tuesday, April 07, 2020 01:25 I ran the gmake and it fails with the below ld errors. Is this the known issue mentioned previously with building openssl on Sparc or is it caused by something else? ... Undefined first referenced symbol in file clock_gettime ./libcrypto.so It appears that's a known issue with building OpenSSL 1.1.1 on Solaris 10. (I think we haven't run into this in my team because we're now on Solaris 11, but I haven't investigated.) Quanah Gibson-Mount mentioned this in a reply to your first post in this thread: They may have run into <https://github.com/openssl/openssl/issues/6333> which the OpenSSL project seems disinclined to fix. If you look at that issue, you'll see people have posted workarounds. I believe it's just a matter of linking with an additional library. -- Michael Wojcik Distinguished Engineer, Micro Focus On Solaris 10, you need to link with -lrt to pick up the clock_gettime functions. If you do something like "export LDFLAGS='-lrt'" before you invoke Configure, it should work. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms
Re: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec
Dennis Clarke wrote: Have you tried running Oracle's builds of OpenSSL? They do the same thing on the UltraSPARC 2e: This is officially a bug. I'll file it and start looking into this one. Very odd. I will try this on a few other RISC architectures and see what I see. Starting with Power6. Dennis It's been a while for this :-). I'm thinking that this is a Solaris bug. Have you opened a ticket with Oracle about it? I just patched one of my UltraSPARC 2e systems with the latest patches, and the problem remains. It's still easy to demonstrate: On UltraSPARC 3i: $ /bin/time tar cf /dev/null /opt/solstudio12.2 real 48.7 user0.5 sys 4.4 On UltraSPARC 2e: $ /bin/time tar cf /dev/null /opt/solstudio12.2 real 1:08.1 user0.0 sys 0.0 On the UltraSPARC 2e (in this case a Sun Blade 150), the user and sys times shouldn't be 0.0. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec
Dennis Clarke wrote:
I do build with the no-asm option, and I'm seeing the problem.
I'm suspicious that somehow the compiler optimization is generating code
that doesn't work quite right on the UltraSPARC 2e.
I have seen this a few times now so I also felt, hrmmm, something not
quite right happening on these old slow netra boxes. Which, by the
way, make great indestructible DNS servers.
In any case I changed the CFLAGS for the solaris64-sparcv9-cc option in
Configure thus :
"solaris64-sparcv9-cc","cc:
-m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e -xcache=generic
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff
-xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee
-mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf
-xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS
-D_LARGEFILE64_SOURCE -D_REENTRANT -xdepend -DB_ENDIAN
::-D_REENTRANT:ULTRASPARC:-lsocket -lnsl -ldl:
BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL
BF_PTR:${sparcv9_asm}:dlfcn:solaris-shared:
-KPIC:-m64 -G -dy -z text:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/64",
So the objective was to correct the wrong -xarch flag that has been in
there for ages and also to get a full debug version which would be
easy to single step through.
So that works fine.
So what I will look for is where the time calc is done, single step
through that and find out why we get a 0.00sec time.
Dennis
I get the same results compiling with Oracle's build of gcc in
/usr/sfw/bin (which uses
the Solaris assembler, etc.) and my own build of gcc 3.4.6 (which uses
the GNU
assembler, etc.).
Have you tried running Oracle's builds of OpenSSL? They do the same
thing on the
UltraSPARC 2e:
$ /usr/bin/openssl version;/usr/bin/openssl speed
OpenSSL 1.0.1t 3 May 2016
Doing md2 for 3s on 16 size blocks: 140755 md2's in 0.00s
Doing md2 for 3s on 64 size blocks: 73864 md2's in 0.00s
Doing md2 for 3s on 256 size blocks: 25778 md2's in 0.00s
Doing md2 for 3s on 1024 size blocks: 6695 md2's in 0.00s
...
$ /usr/sfw/bin/openssl version;/usr/sfw/bin/openssl>
OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969
CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343
CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2008-7270
CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 CVE-2011-4576
CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 CVE-2012-2131
CVE-2012-2333 CVE-2013-0166 CVE-2013-0169 CVE-2014-0224 CVE-2014-3508
CVE-2014-3511 CVE-2014-3566 CVE-2014-3567 CVE-2014-3568 CVE-2014-3569
CVE-2014-3570 CVE-2014-8275 CVE-2015-0204 CVE-2015-0286 CVE-2015-0287
CVE-2015-0288 CVE-2015-0289 CVE-2015-0292 CVE-2015-0293 CVE-2015-1789
CVE-2015-1790 CVE-2015-3195 CVE-2015-3197 CVE-2015-4000 CVE-2016-0703
CVE-2016-0704 CVE-2016-0797 CVE-2016-0799 CVE-2016-0800 CVE-2016-2105
CVE-2016-2106 CVE-2016-2107 CVE-2016-2108 CVE-2016-2176)
Doing md2 for 3s on 16 size blocks: 79067 md2's in 0.00s
Doing md2 for 3s on 64 size blocks: 42773 md2's in 0.00s
Doing md2 for 3s on 256 size blocks: 15316 md2's in 0.00s
Doing md2 for 3s on 1024 size blocks: 4240 md2's in 0.00s
Doing md2 for 3s on 8192 size blocks: 543 md2's in 0.00s
...
They appear to work fine on the other SPARC machines that I can get test
it on.
--
Jeff Wieland, UNIX/Network Systems Administrator
Purdue University IT Infrastructure Services UNIX Platforms
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec
Dennis Clarke wrote: On 09/11/2016 03:44 PM, Jeff Wieland wrote: I see the same thing on Sun Blade 150 (650Mhz), with OpenSSL 1.0.2h compiled with Studio 12.2 -- and with a Sun Fire V100 (550Mhz). It works correctly on a Sun Fire V240 (1.5Ghz), a Sun Ultra 10 (440Mhz), a Sun Fire T1000, and Sun Enterprise M3000. I see these results with both 32 bit and 64 bit builds. It looks like you're building and running this on an UltraSPARC 2e architecture system -- this is what the SB150 and the V100 are. Hrmmm .. not sure what that means. Given that I run Configure with the "no-asm" option then I would think that cross platform consistency would happen. I would have to go diving into the source to find out where the timings are happening. On Solaris the best timer is the gethrtime() function as it works down to the nanosec and is accurate to the millisec at least. Dennis I do build with the no-asm option, and I'm seeing the problem. I'm suspicious that somehow the compiler optimization is generating code that doesn't work quite right on the UltraSPARC 2e. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec
I see the same thing on Sun Blade 150 (650Mhz), with OpenSSL 1.0.2h compiled with Studio 12.2 -- and with a Sun Fire V100 (550Mhz). It works correctly on a Sun Fire V240 (1.5Ghz), a Sun Ultra 10 (440Mhz), a Sun Fire T1000, and Sun Enterprise M3000. I see these results with both 32 bit and 64 bit builds. It looks like you're building and running this on an UltraSPARC 2e architecture system -- this is what the SB150 and the V100 are. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms Dennis Clarke wrote: Strange results from OpenSSL 1.0.2h built on an older sparc server with Oracle Studio 12.4 and with ALL testsuite tests passed : mimas$ openssl version OpenSSL 1.0.2h 3 May 2016 mimas$ openssl speed Doing mdc2 for 3s on 16 size blocks: 30887 mdc2's in 0.00s Doing mdc2 for 3s on 64 size blocks: 8500 mdc2's in 0.00s Doing mdc2 for 3s on 256 size blocks: 1858 mdc2's in 0.00s Doing mdc2 for 3s on 1024 size blocks: 549 mdc2's in 0.00s Doing mdc2 for 3s on 8192 size blocks: 69 mdc2's in 0.00s Doing md4 for 3s on 16 size blocks: 127674 md4's in 0.00s Doing md4 for 3s on 64 size blocks: 99595 md4's in 0.00s Doing md4 for 3s on 256 size blocks: 59892 md4's in 0.00s . . etc etc . Doing 163 bit ecdh's for 10s: 193 163-bit ECDH ops in 0.00s Doing 233 bit ecdh's for 10s: 94 233-bit ECDH ops in 0.00s Doing 283 bit ecdh's for 10s: 52 283-bit ECDH ops in 0.00s Doing 409 bit ecdh's for 10s: 22 409-bit ECDH ops in 0.00s Doing 571 bit ecdh's for 10s: 9 571-bit ECDH ops in 0.00s OpenSSL 1.0.2h 3 May 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/solarisstudio12.4/bin/cc -I. -I.. -I../include -KPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e -xcache=generic -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_REENTRANT -xdepend -DB_ENDIAN The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md20.00 0.00 0.00 0.00 0.00 mdc2Infk Infk Infk Infk Infk md4 Infk Infk Infk Infk Infk md5 Infk Infk Infk Infk Infk . . . ghash Infk Infk Infk Infk Infk signverifysign/s verify/s rsa 512 bits 0.00s 0.00s Inf Inf rsa 1024 bits 0.00s 0.00s Inf Inf rsa 2048 bits 0.00s 0.00s Inf Inf rsa 4096 bits 0.00s 0.00s Inf Inf signverifysign/s verify/s dsa 512 bits 0.00s 0.00s Inf Inf dsa 1024 bits 0.00s 0.00s Inf Inf dsa 2048 bits 0.00s 0.00s Inf Inf signverifysign/s verify/s 160 bit ecdsa (secp160r1) 0.s 0.s Inf Inf 192 bit ecdsa (nistp192) 0.s 0.s Inf Inf 224 bit ecdsa (nistp224) 0.s 0.s Inf Inf 256 bit ecdsa (nistp256) 0.s 0.s Inf Inf 384 bit ecdsa (nistp384) 0.s 0.s Inf Inf 521 bit ecdsa (nistp521) 0.s 0.s Inf Inf 163 bit ecdsa (nistk163) 0.s 0.s Inf Inf 233 bit ecdsa (nistk233) 0.s 0.s Inf Inf 283 bit ecdsa (nistk283) 0.s 0.s Inf Inf 409 bit ecdsa (nistk409) 0.s 0.s Inf Inf 571 bit ecdsa (nistk571) 0.s 0.s Inf Inf 163 bit ecdsa (nistb163) 0.s 0.s Inf Inf 233 bit ecdsa (nistb233) 0.s 0.s Inf Inf 283 bit ecdsa (nistb283) 0.s 0.s Inf Inf 409 bit ecdsa (nistb409) 0.s 0.s Inf Inf 571 bit ecdsa (nistb571) 0.s 0.s Inf Inf op op/s 160 bit ecdh (secp160r1) 0.s Inf 192 bit ecdh (nistp192) 0.s Inf 224 bit ecdh (nistp224) 0.s Inf 256 bit ecdh (nistp256) 0.s Inf 384 bit ecdh (nistp384) 0.s Inf 521 bit ecdh (nistp521) 0.s Inf 163 bit ecdh (nistk163) 0.s Inf 233 bit ecdh (nistk233) 0.s Inf 283 bit ecdh (nistk283) 0.s Inf 409 bit ecdh (nistk409) 0.s Inf 571 bit ecdh (nistk571) 0.s Inf 163 bit ecdh (nistb163) 0.s Inf 233 bit ecdh (nistb233) 0.s Inf 283 bit ecdh (nistb283) 0.s Inf 409 bi
Re: OpenSSL Security Advisory
Side-channel Attack" Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with additional details over time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJTkFm3AAoJENNXdQf6QOnihZAQAIFx8gw6s6HabFQ1b+GIpvdi aJ1BBE4RPVLvxVtApON0eOESjcuetkiz6aU2JUVeObWn9fiPjuRnNueuFe5CiK0P zVzv1AFyfae0m5IMzGSPgmffusbTo8cfjt6N6e77p6zWFncmlTW1wkr3th3RdjBk OyEZgrSq1lO22csiQVD/CG+sOFWJUxM1dDDzluVU+XCnNEFdfAKc/i6b26BLUjag zIDbptPgDu/5alRGqO/1A1EC0ODLYtu0xJWe7JUMPSPa/M8y2U9AKAMGPvlxJzs1 g2rNk14NT1YzN7KJBHJVMA70wMSmsU0jq3IYcXMUrhOkuBTAIKYb/KaivYS15Wrm LJWJJzC1uIuaJOnUhN9g0Q5WwVkQTwf0oY/n+qdhyup/9duJvuWpgSK4cW8c7xGe t7bYaOMlTjPKrUmulXDi0GBdcGd/UwctCWdaDeHORVlz7WM+aQHQfQMAaNmpzJzV /CA5h5t4OlrjLLJW/Im5axk7Li8HU8aypkhLLCZUNjkLmoYnl1buo4LmmikQ77A2 JyoSlioYWC+lry22VQien/JR4ute7DO+s9N0jcWMTjR/isTwwnehimpf8Pyc/MoQ kvKh+vXIVBX+u0jufSB4E2fDCgcr95bjjlQwnMTLhcDn1y1X39qU2LjXDdJIwwVw oAC+cB8GKalIUtUfXf4x =3foe -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Announcement Mailing List openssl-annou...@openssl.org Automated List Manager majord...@openssl.org -- Jeff Wieland| Purdue University Network Systems Administrator |ITIS UNIX Platforms Voice: (765)496-8234 |155 S. Grant Street FAX: (765)494-2253| West Lafayette, IN 47907 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Attack" Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with additional details over time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJTkFm3AAoJENNXdQf6QOnihZAQAIFx8gw6s6HabFQ1b+GIpvdi aJ1BBE4RPVLvxVtApON0eOESjcuetkiz6aU2JUVeObWn9fiPjuRnNueuFe5CiK0P zVzv1AFyfae0m5IMzGSPgmffusbTo8cfjt6N6e77p6zWFncmlTW1wkr3th3RdjBk OyEZgrSq1lO22csiQVD/CG+sOFWJUxM1dDDzluVU+XCnNEFdfAKc/i6b26BLUjag zIDbptPgDu/5alRGqO/1A1EC0ODLYtu0xJWe7JUMPSPa/M8y2U9AKAMGPvlxJzs1 g2rNk14NT1YzN7KJBHJVMA70wMSmsU0jq3IYcXMUrhOkuBTAIKYb/KaivYS15Wrm LJWJJzC1uIuaJOnUhN9g0Q5WwVkQTwf0oY/n+qdhyup/9duJvuWpgSK4cW8c7xGe t7bYaOMlTjPKrUmulXDi0GBdcGd/UwctCWdaDeHORVlz7WM+aQHQfQMAaNmpzJzV /CA5h5t4OlrjLLJW/Im5axk7Li8HU8aypkhLLCZUNjkLmoYnl1buo4LmmikQ77A2 JyoSlioYWC+lry22VQien/JR4ute7DO+s9N0jcWMTjR/isTwwnehimpf8Pyc/MoQ kvKh+vXIVBX+u0jufSB4E2fDCgcr95bjjlQwnMTLhcDn1y1X39qU2LjXDdJIwwVw oAC+cB8GKalIUtUfXf4x =3foe -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Announcement Mailing List openssl-annou...@openssl.org Automated List Manager majord...@openssl.org -- Jeff Wieland| Purdue University Network Systems Administrator |ITIS UNIX Platforms Voice: (765)496-8234 |155 S. Grant Street FAX: (765)494-2253| West Lafayette, IN 47907 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
