[openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

Sun Feb 25 01:36:18 UTC 2018

Morning Dennis, et al

This may be off thread topic, but one thing I have noticed with the x86 
openssl builds shipped by Oracle and Blastwave in the releases I have 
been testing FooCrypt against ( 10u11 through 11.3 ) is that openssl 
seems to ‘HANG’ when inputting a string greater than 262 characters 
which is quite different behavious to the Linux / macOS stock builds 
that accept a string of up to 522 characters.

Anyone know if this is a ‘feature’ of the Solaris x86 compiles or is it 
inherent to openssl compiling on Solaris x86 ?

name -a : SunOS FooCrypt 5.10 Generic_147148-26 i86pc i386 i86pc

/opt/csw/bin/openssl version OpenSSL 1.0.2n  7 Dec 2017

name -a : SunOS FooCrypt 5.11 11.3 i86pc i386 i86pc

/opt/csw/bin/openssl version : OpenSSL 1.0.2n  7 Dec 2017

/usr/bin/openssl version : OpenSSL 1.0.1p 9 Jul 2015

—

Regards,

Mark A. Lane

Cryptopocalypse NOW 01 04 2016

Volumes 0.0 NOW available through iTunes - iBooks @ 
https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11

Cryptopocalypse NOW is the TRUE story behind the trials and tribulations 
encountered in creating "FooCrypt, A Tale of Cynical Cyclical 
Encryption." due to the Australian Government's ( led by Malcolm 
Turnbull ) criminalisation of encryption technologies on the 1st of 
April, 2016, as told by a Convicted Hacker.

"FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening 
several commonly used Symmetric Open Source Encryption methods so that 
they are hardened to a standard that is commonly termed 'QUANTUM 
ENCRYPTION'.

"FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under 
export control by the Australian Department of Defence Defence Export 
Controls Office due to the listing of Cryptology as a ‘Dual Use’ 
Technology as per the ‘Wassenaar Arrangement’

Limited Edition Collectors versions and Hard Back Editions are available 
via the store on http://www.foocrypt.net/

© Mark A. Lane 1980 - 2018, All Rights Reserved.
© FooCrypt 1980 - 2018, All Rights Reserved.
© FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2018, All 
Rights Reserved.
© Cryptopocalypse 1980 - 2018, All Rights Reserved.

On 2018-02-21 11:42, Dennis Clarke wrote:
> On 21/02/18 12:11 PM, Norm Green wrote:
>> On 2/21/2018 8:42 AM, Dennis Clarke wrote:
>>> Pretty sure I have done builds and tests. In fact I am certain of it.
>> 
>> If you added -xmemalign=8s to the SPARC compiler flags (as shown in 
>> one
>> of your emails from yesterday) then you would not see the problem.
>> -xmemalign=8s forces the compiler to use 8-byte alignment.
> 
> Which is correct way to do this on sparc systems.  I am digging into 
> the
> whole build process to see what needs to be "hacked" at to get solid 
> and
> reasonable results. The real issue is compilers.  Sorry but gcc just
> won't do the right things on sparc and that isn't anyones fault.
> 
> This is where we could go down a deep dark hole.  For the sake of
> getting it out there we may as well just admit that the compilers that
> are generally installed on Solaris systems were of the Forte flavour 
> way
> back when little dinosaurs were still roaming the datacenters and the
> cost of the license was about $3000 or so. The acquisitions and rename
> of everything happened for a while there and I am surprised no one at
> Sun lost their little minds and called it the Java Enterprise C 
> Compiler
> because everything else had "Java" slapped on it. Regardless, the Forte
> name went away and we then had "Sun Studio" which revved up until we
> were able to compile the whole source code base with it and Solaris
> "UNIX" was self hosted and self boot-strappable and time marched on. So
> here we are today with Oracle Studio compilers and they are very very
> good. At least on sparc they are. The concept of doing a compile for a
> very specific machine class was dropped on the market way back in 1999
> or so and I think by 2002 we could target flavours of sparc v9 with the
> vis instructions as well as a lot of hullabaloo about fused multiply
> etc.  However that was a sun4c and sun4m issue back when we needed the
> optional weitek coprocessor.
> 
> So anyways the "target" option was born out of necessity to get the
> right opcodes for given sparc units. People had fights over the entire
> x86 platform and Sun dropped it. Then picked it up again.  Then built a
> version for Itanium. Put that on a shelf and hid it. Buried it. Then
> went back and released a general x86 version again. Madness. I had a 
> sit
> down coffee with the global manager for the "solaris" product and it is
> history now but the compiler tools for x86 were never the same quality
> as the sparc tools.  Never have been.  One needs to use "fpversion" to
> get the correct target and cache line options but someone at Oracle has
> spilled a coffee and shuffled papers and forgot to release fpversion in
> the latest flavour of the Studio compilers. I will take a look on a big
> new shiney M-class machine and see what is there but I can tell you 
> that
> the openssl binaries I build from sources are at least the same speed 
> or
> better than the ones shipped out by Oracle. For a given specific type 
> of
> machine and sparc target.
> 
> 
> jupiter # /opt/developerstudio12.5/bin/fpversion
>  A SPARC-based CPU is available.
>  Kernel says main memory's clock rate is 1272.0 MHz.
> 
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
> 
>  Use "-xtarget=sparc64viiplus -xcache=64/64/2:11264/256/11"
> code-generation option.
> 
>  Hostid = 0xBADCAFFE.
> 
> 
> A much older system may say :
> 
> 
> mimas $ /opt/solarisstudio12.4/bin/fpversion
>  A SPARC-based CPU is available.
>  Kernel says CPU's clock rate is 500.0 MHz.
>  Kernel says main memory's clock rate is 100.0 MHz.
> 
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
> 
>  Use "-xtarget=ultra2e -xcache=16/32/1:256/64/1" code-generation 
> option.
> 
>  Hostid = 0xBADCAFFE.
> 
> 
> Even more bizarre and older :
> 
> ns1_$ /opt/solarisstudio12.4/bin/fpversion
>  A SPARC-based CPU is available.
>  Kernel says CPU's clock rate is 360.0 MHz.
>  Kernel says main memory's clock rate is 90.0 MHz.
> 
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
> 
>  Use "-xtarget=ultra2i -xcache=16/32/1:1024/64/1" code-generation 
> option.
> 
>  Hostid = 0xDEADBEEF.
> 
> 
> I say "bizarre" because that is a system that uses the memory options
> which were shipped on the E10k servers and those cache lines are wrong.
> That machine will always report "infinite" performance from openssl
> speed results and be damned if I can figure out why.  Yet.
> 
> ns1_$ /usr/local/ssl/bin/openssl speed rsa4096
> Doing 4096 bit private rsa's for 10s: 13 4096 bit private RSA's in 
> 0.00s
> Doing 4096 bit public rsa's for 10s: 1436 4096 bit public RSA's in 
> 0.00s
> OpenSSL 1.0.2n  7 Dec 2017
> 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/c99 -I. -I.. -I../include  -KPIC
> -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -Xc -g -errfmt=error -erroff=%none -xmemalign=8s
> -errshort=full -xstrconst -xildoff -m64 -xnolibmil -xcode=pic32
> -xregs=no%appl -xlibmieee -ftrap=%none -xarch=sparc -mc -xs
> -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DB_ENDIAN
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
>                   sign    verify    sign/s verify/s
> rsa 4096 bits 0.000000s 0.000000s      inf      inf
> 
> 
> However the latest from Oracle claims :
> 
> $ ls /opt/developerstudio12.6/bin/fpversion
> /opt/developerstudio12.6/bin/fpversion: No such file or directory
> 
> However it is in the manual still.
> 
> Messy.  Very.
> 
> So as I said earlier ... this should be fun.
> 
> Dennis