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

[openssl]

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 

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

[Dennis Clarke]

On 24/02/18 02:18 PM, Erik Forsberg wrote:



-- Original Message --


As for -lm, which symbol was undefined?



Undefined   first referenced
   symbol in file
fabs    test/ct_test.o


??? One can only wonder where does it come from. I see no fabs
anywhere...


Ah! Missed it! There is fabs call in ct_test. I was looking for
reference in binary code. On multiple platforms including Solaris x86.
Question is how come it isn't a problem anywhere else. It looks like
it's customarily inlined, but not here. Well, you insist on
-xbuiltin=%none, so I suppose this has to be it. In such case it's on you...


Most compilers (including gcc) inlines fabs()
Solaris cc does not when using -O0 -g which I use when debugging.
If I remember correctly, solaris cc also inlines when using higher level of 
optimization
but I may remember wrong.



I like having nice debug builds first that I can single step through if
needed.  The joy of fast processors and buckets of cheap memory is that
I can have an entire dev type amp stack that runs just fine with debug
libs everywhere and then a prod stack which is slightly more optimal.

In any case, this seems to me like we are fetching a unit64_t type of
number for milliseconds and should just check if it is within 60
of some value for "now".  No need for the divide by 1000 in there.

Looking in ./include/openssl/ct.h  we see :

/*
 * Gets the time, in milliseconds since the Unix epoch, that will be 
used as the

 * current time when checking whether an SCT was issued in the future.
 * Such SCTs will fail validation, as required by RFC6962.
 */
uint64_t CT_POLICY_EVAL_CTX_get_time(const CT_POLICY_EVAL_CTX *ctx);


OKay so it is an uint64_t for milliseconds.  Perfect.  So maybe just use 
that in line 503 :




uint64_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx);


What in the name of Smokey Robinson is TEST_uint_le?  Looks to be a
 "define" in ./test/testutil.h :

# define TEST_uint_le(a, b)   test_uint_le(__FILE__, __LINE__, #a, #b, a, b)

uh huh ...  and in turn where is test_uint_le coming from ?

I don't know.  No where in the tarball that is for sure.

I do see it out in the world at :

https://github.com/openssl/openssl/blob/master/test/test_test.c

Seems like a test for "less than or equal to" for two uintXX_t things.

Regardless there isn't a need for a double difftime nor a floating point
 fabs here.  Am I missing something obvious ?


dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Erik Forsberg]

>-- Original Message --
>
> As for -lm, which symbol was undefined?
>

 Undefined   first referenced
   symbol in file
 fabs    test/ct_test.o
>>>
>>> ??? One can only wonder where does it come from. I see no fabs
>>> anywhere...
>
>Ah! Missed it! There is fabs call in ct_test. I was looking for
>reference in binary code. On multiple platforms including Solaris x86.
>Question is how come it isn't a problem anywhere else. It looks like
>it's customarily inlined, but not here. Well, you insist on
>-xbuiltin=%none, so I suppose this has to be it. In such case it's on you...

Most compilers (including gcc) inlines fabs()
Solaris cc does not when using -O0 -g which I use when debugging.
If I remember correctly, solaris cc also inlines when using higher level of 
optimization
but I may remember wrong.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Erik Forsberg]

>-- Original Message --
>
>>> As for -lm, which symbol was undefined?
>>>
>> 
>> Undefined   first referenced
>>  symbol in file
>> fabs    test/ct_test.o
>
>??? One can only wonder where does it come from. I see no fabs anywhere...
>

/*
 * Tests that the CT_POLICY_EVAL_CTX default time is approximately now.
 * Allow +-10 minutes, as it may compensate for clock skew.
 */
static int test_default_ct_policy_eval_ctx_time_is_now()
{
int success = 0;
CT_POLICY_EVAL_CTX *ct_policy_ctx = CT_POLICY_EVAL_CTX_new();
const time_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) /
1000;
const time_t time_tolerance = 600;  /* 10 minutes */

if (fabs(difftime(time(NULL), default_time)) > time_tolerance) {
fprintf(stderr,
"Default CT_POLICY_EVAL_CTX time is not approximately now.\n");
goto end;
}
if (fabs(difftime(time(NULL), default_time)) > time_tolerance) {
fprintf(stderr,
"Default CT_POLICY_EVAL_CTX time is not approximately now.\n");
goto end;
}

success = 1;
end:
CT_POLICY_EVAL_CTX_free(ct_policy_ctx);
return success;
}



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Erik Forsberg]

as that is the ONLY -lm reference and the fact its in test code, why not
simply avoid using fabs(), that is so trivial here ?

if (value < 0)
value = -value;


>-- Original Message --
>
>On 24/02/18 04:47 AM, Andy Polyakov wrote:
>>> So testsuite is running but this is a non-optimal debug build and only
>>> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
>>> ELF header below which is somewhat restrictive.
>>>
>>>    e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
>> 
>> If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and
>> EF_SPARC_SUN_US3 ...
>
>
>I wasn't clear. I know exactly what causes this. I am saying that I will
>have to redo everything again and get the process down to a baseline
>config.
>
>> As for -lm, which symbol was undefined?
>> 
>
>Undefined   first referenced
>  symbol in file
>fabstest/ct_test.o
>
>dc
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

> As for -lm, which symbol was undefined?
>

 Undefined   first referenced
   symbol in file
 fabs    test/ct_test.o
>>>
>>> ??? One can only wonder where does it come from. I see no fabs
>>> anywhere...
> 
> Ah! Missed it! There is fabs call in ct_test. I was looking for
> reference in binary code. On multiple platforms including Solaris x86.
> Question is how come it isn't a problem anywhere else. It looks like
> it's customarily inlined, but not here. Well, you insist on
> -xbuiltin=%none, so I suppose this has to be it. In such case it's on you...

Well, one can probably argue that it might be appropriate to solve it
anyway. And provided that this is the *only* reference to -lm, it
wouldn't be inappropriate to solve it rather by casting difftime return
value to integer and then passing it to abs(3).
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

 As for -lm, which symbol was undefined?

>>>
>>> Undefined   first referenced
>>>   symbol in file
>>> fabs    test/ct_test.o
>>
>> ??? One can only wonder where does it come from. I see no fabs
>> anywhere...

Ah! Missed it! There is fabs call in ct_test. I was looking for
reference in binary code. On multiple platforms including Solaris x86.
Question is how come it isn't a problem anywhere else. It looks like
it's customarily inlined, but not here. Well, you insist on
-xbuiltin=%none, so I suppose this has to be it. In such case it's on you...
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Levitte]

In message  on Sat, 24 Feb 
2018 13:51:45 +0100, Andy Polyakov  said:

appro> >> As for -lm, which symbol was undefined?
appro> >>
appro> > 
appro> > Undefined   first referenced
appro> >  symbol in file
appro> > fabs    test/ct_test.o
appro> 
appro> ??? One can only wonder where does it come from. I see no fabs 
anywhere...

E

: ; git grep fabs
test/ct_test.c:if (!TEST_uint_le((unsigned 
int)fabs(difftime(time(NULL), default_time)),

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Levitte]

In message  on Sat, 24 Feb 
2018 06:14:50 -0500, Dennis Clarke  said:

dclarke> On 24/02/18 05:13 AM, Richard Levitte wrote:
dclarke> > In message <607c8d70-4283-1b55-2eac-c9f30a3a3...@blastwave.org> on
dclarke> > Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke 

dclarke> > said:
dclarke> > dclarke> Not sure why but the various scripts and test files are hell
dclarke> > dclarke> bent on using the perl in the system as opposed to what I
dclarke> > dclarke> have set in an env var PERL=/usr/local/bin/perl.
dclarke> > Hmmm, if it's hell bent on anything, it's on what perl was used to 
run
dclarke> > 'Configure'.  I'm not sure if you use that script directly or if you
dclarke> > use 'config'...  the latter will certainly look at $PERL to run
dclarke> 
dclarke> OKay ... I can try "config" however I did use "Configure" :
dclarke> 
dclarke> corv $ ./Configure shared zlib threads solaris64-sparcv9-cc

Ah, yes.  And since you probably have the system perl first along your
$PATH, that's the one you're gonna get registered.  The workaround
would be this:

/usr/local/bin/perl ./Configure shared zlib threads solaris64-sparcv9-cc

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 24/02/18 07:51 AM, Andy Polyakov wrote:

As for -lm, which symbol was undefined?



Undefined   first referenced
  symbol in file
fabs    test/ct_test.o


??? One can only wonder where does it come from. I see no fabs anywhere...




${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa 
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs 
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -L. -mt  \

-o test/crltest test/crltest.o \
  test/libtestutil.a -lcrypto -lz -lsocket -lnsl -ldl -lpthread
/opt/developerstudio12.6/bin/cc  -Iinclude -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa 
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs 
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -DDSO_DLFCN 
-DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -I/usr/local/include 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO  -c -o 
test/ct_test.o test/ct_test.c
/usr/openwin/bin/makedepend -f- -o"|test/ct_test.o" --  -Iinclude 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
-xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -Qy -xs -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
-DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE 
-DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
-D_TS_ERRNO  -c -- test/ct_test.c \

>test/ct_test.d.tmp 2>/dev/null
/usr/local/bin/perl -i -pe 's/^.*\|//; s/ \/(\\.|[^ ])*//; $_ = undef if 
(/: *$/ || /^(#.*| *)$/); $_.="\n" unless !defined($_) or /\R$/g;' 
test/ct_test.d.tmp

rm -f test/ct_test
${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa 
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs 
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -L. -mt  \

-o test/ct_test test/ct_test.o \
  test/libtestutil.a -lcrypto -lz -lsocket -lnsl -ldl -lpthread
Undefined   first referenced
 symbol in file
fabstest/ct_test.o
ld: fatal: symbol referencing errors. No output written to test/ct_test
gmake[1]: *** [Makefile:10579: test/ct_test] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.002'

gmake: *** [Makefile:143: all] Error 2
corv $ find . | grep "ct_test"
./test/ct_test.c
./test/ct_test.d
./test/ct_test.o
corv $
corv $ grep "math\.h" ./test/ct_test.c
#include 
corv $
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

>> As for -lm, which symbol was undefined?
>>
> 
> Undefined   first referenced
>  symbol in file
> fabs    test/ct_test.o

??? One can only wonder where does it come from. I see no fabs anywhere...

There also was remark about shell. Why? We don't aim for any specific
flavour, or in other words it's expected to work with *any*
Bourne-compatible shell, or in yet other words if it doesn't, then we'd
rather hear about it and eliminate the dependency.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 24/02/18 05:13 AM, Richard Levitte wrote:

In message <607c8d70-4283-1b55-2eac-c9f30a3a3...@blastwave.org> on Sat, 24 Feb 2018 
00:24:34 -0500, Dennis Clarke  said:


dclarke> Not sure why but the various scripts and test files are hell
dclarke> bent on using the perl in the system as opposed to what I
dclarke> have set in an env var PERL=/usr/local/bin/perl.

Hmmm, if it's hell bent on anything, it's on what perl was used to run
'Configure'.  I'm not sure if you use that script directly or if you
use 'config'... 


Ah well ... config isn't too helpful with building a 64-bit lib :


corv $
corv $ ./config
Operating system: sun4u-whatever-solaris2
WARNING! If you wish to build 64-bit library, then you have to
 invoke './Configure solaris64-sparcv9-cc' *manually*.
Using implicit seed configuration
Configuring OpenSSL version 1.1.1-pre1 (0x10101001L) for solaris-sparcv9-cc
Creating configdata.pm
Creating Makefile

NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the 
disabled

options or the "make variables" with their values.  Instead, you must use
'configdata.pm' as a script to get a display of the configuration data.  For
help, please do this:

perl configdata.pm --help
corv $


dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 24/02/18 05:13 AM, Richard Levitte wrote:

In message <607c8d70-4283-1b55-2eac-c9f30a3a3...@blastwave.org> on Sat, 24 Feb 2018 
00:24:34 -0500, Dennis Clarke  said:


dclarke> Not sure why but the various scripts and test files are hell
dclarke> bent on using the perl in the system as opposed to what I
dclarke> have set in an env var PERL=/usr/local/bin/perl.

Hmmm, if it's hell bent on anything, it's on what perl was used to run
'Configure'.  I'm not sure if you use that script directly or if you
use 'config'...  the latter will certainly look at $PERL to run


OKay ... I can try "config" however I did use "Configure" :

corv $ ./Configure shared zlib threads solaris64-sparcv9-cc


dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 24/02/18 04:47 AM, Andy Polyakov wrote:

So testsuite is running but this is a non-optimal debug build and only
on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
ELF header below which is somewhat restrictive.

   e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]


If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and
EF_SPARC_SUN_US3 ...



I wasn't clear. I know exactly what causes this. I am saying that I will
have to redo everything again and get the process down to a baseline
config.


As for -lm, which symbol was undefined?



Undefined   first referenced
 symbol in file
fabstest/ct_test.o

dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Levitte]

In message <607c8d70-4283-1b55-2eac-c9f30a3a3...@blastwave.org> on Sat, 24 Feb 
2018 00:24:34 -0500, Dennis Clarke  said:


dclarke> Not sure why but the various scripts and test files are hell
dclarke> bent on using the perl in the system as opposed to what I
dclarke> have set in an env var PERL=/usr/local/bin/perl.

Hmmm, if it's hell bent on anything, it's on what perl was used to run
'Configure'.  I'm not sure if you use that script directly or if you
use 'config'...  the latter will certainly look at $PERL to run
'Configure', and this one will register $^X (perl's internal variable
to indicate the exact file name of the interpreter), which is then
propagated to Makefile (make variable $(PERL)) and used there.  Did we
miss a spot?  I'm willing to correct that...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

> So testsuite is running but this is a non-optimal debug build and only
> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
> ELF header below which is somewhat restrictive.
> 
>   e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]

If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and
EF_SPARC_SUN_US3, then it's likely to be between you and
compiler/run-time. The flags are set by linker as logical 'or' of flags
from all input object files involved. What you need is to identify which
of the *.o files that carries additional flags. On Linux I'd simply
'find . -name \*.o -exec file {} \;' and would show things like "Sun
UltraSPARC1 Extensions Required". If you find nothing among OpenSSL .o
files, then flag comes from elsewhere, and that would be question to
vendor. But even if you find OpenSSL *.o file with undesired flag, it
would still be question to vendor, because -xarch=v9 is documented to
mean "no extensions please", so there shouldn't be any.

As for -lm, which symbol was undefined?

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

I have run into a bit of a snag here.  Firstly everything compiles just
fine with zero code changes. Zero. All we need are some careful CFLAGS
and the compile moves along swimmingly. However the test stage gets
terribly wedged just after test 70-test_clienthello.t completes. Not
sure why but the various scripts and test files are hell bent on using
the perl in the system as opposed to what I have set in an env var
PERL=/usr/local/bin/perl.  That may be the issue. Not sure.  Also would
be really nice if all the shell scripts could use the the bash shell in
the env var CONFIG_SHELL which is pointed to /usr/local/bin/bash.

If you have any thoughts let me know or I will jsut keep on with my awk
and sed kung fu here changing all the scripts.

Dennis


ps: I still need to get this all built for baseline v9 and not the
 more modern processors :


corv $ elfdump -devl ./apps/openssl

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS64  ei_data:   ELFDATA2MSB
  ei_osabi:   ELFOSABI_SOLARISei_abiversion: EAV_SUNW_CURRENT
  e_machine:  EM_SPARCV9  e_version: EV_CURRENT
  e_type: ET_EXEC
  e_flags:[ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
  e_entry:   0x10001c600  e_ehsize: 64  e_shstrndx:  29
  e_shoff:  0xe0ea38  e_shentsize:  64  e_shnum: 31
  e_phoff:  0x40  e_phentsize:  56  e_phnum: 6

Version Needed Section:  .SUNW_version
 index  fileversion
   [2]  libssl.so   OPENSSL_1_1_0[ INFO ]
   [3]  OPENSSL_1_1_1
   [4]  libcrypto.soOPENSSL_1_1_0[ INFO ]
   [5]  OPENSSL_1_1_1
   [6]  libsocket.so.1  SUNW_0.7
   [7]  libpthread.so.1 SUNW_1.2
   [8]  SUNW_0.9 [ INFO ]
   [9]  libc.so.1   SUNW_1.21.2
  [10]  SUNW_0.7 [ INFO ]

Dynamic Section:  .dynamic
 index  tagvalue
   [0]  NEEDED0x6d18  libssl.so
   [1]  NEEDED0x6d3e  libcrypto.so
   [2]  NEEDED0x6d9b  libz.so.1
   [3]  NEEDED0x6d4b  libsocket.so.1
   [4]  NEEDED0x6da5  libnsl.so.1
   [5]  NEEDED0x6db1  libdl.so.1
   [6]  NEEDED0x6d63  libpthread.so.1
   [7]  NEEDED0x6d85  libc.so.1
   [8]  INIT  0x1006caa58
   [9]  FINI  0x1006caa68
  [10]  RUNPATH   0x6dbc /usr/local/lib:/usr/local/ssl/lib
  [11]  RPATH 0x6dbc /usr/local/lib:/usr/local/ssl/lib
  [12]  HASH  0x101d0
  [13]  STRTAB0x1c9c0
  [14]  STRSZ 0x6fde
  [15]  SYMTAB0x133d8
  [16]  SYMENT0x18
  [17]  CHECKSUM  0x33bc
  [18]  VERNEED   0x1000139a0
  [19]  VERNEEDNUM0x5
  [20]  PLTRELSZ  0x7b60
  [21]  PLTREL0x7
  [22]  JMPREL0x100014a90
  [23]  RELA  0x100014700
  [24]  RELASZ0x7ef0
  [25]  RELAENT   0x18
  [26]  DEBUG 0
  [27]  SUNW_CAP  0x101b0
  [28]  FLAGS 0   0
  [29]  FLAGS_1   0   0
  [30]  SUNW_STRPAD   0x200
  [31]  SUNW_LDMACH   0x2bEM_SPARCV9
  [32]  PLTGOT0x1007ead00
   [33-43]  NULL  0

corv $ LD_LIBRARY_PATH=`pwd` ./apps/openssl version
OpenSSL 1.1.1-pre1 (alpha) 13 Feb 2018
corv $
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 21/02/18 04:53 PM, Norm Green wrote:

On 2/21/2018 12:46 PM, Andy Polyakov wrote:

And "the default for all v9 architectures is -xmemalign=8s".

I'm getting confused.  Since I did not specify -xmemalign at all..


Without getting into some needed CFLAGS let me just say that the build
ran fine here other than test/ct_test.c needs to link with libm. I just
tossed in the required -lm on the EX_LIBS in the Makefile.  Not optimal
but gets the job done for the moment.  Also there is a nagging perl
version problem and that is just .. annoying.

So testsuite is running but this is a non-optimal debug build and only
on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
ELF header below which is somewhat restrictive.

corv $ elfdump -devl ./apps/openssl

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS64  ei_data:   ELFDATA2MSB
  ei_osabi:   ELFOSABI_SOLARISei_abiversion: EAV_SUNW_CURRENT
  e_machine:  EM_SPARCV9  e_version: EV_CURRENT
  e_type: ET_EXEC
  e_flags:[ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
  e_entry:   0x10001c600  e_ehsize: 64  e_shstrndx:  29
  e_shoff:  0xe0ea38  e_shentsize:  64  e_shnum: 31
  e_phoff:  0x40  e_phentsize:  56  e_phnum: 6

Version Needed Section:  .SUNW_version
 index  fileversion
   [2]  libssl.so   OPENSSL_1_1_0[ INFO ]
   [3]  OPENSSL_1_1_1
   [4]  libcrypto.soOPENSSL_1_1_0[ INFO ]
   [5]  OPENSSL_1_1_1
   [6]  libsocket.so.1  SUNW_0.7
   [7]  libpthread.so.1 SUNW_1.2
   [8]  SUNW_0.9 [ INFO ]
   [9]  libc.so.1   SUNW_1.21.2
  [10]  SUNW_0.7 [ INFO ]

Dynamic Section:  .dynamic
 index  tagvalue
   [0]  NEEDED0x6d18  libssl.so
   [1]  NEEDED0x6d3e  libcrypto.so
   [2]  NEEDED0x6d9b  libz.so.1
   [3]  NEEDED0x6d4b  libsocket.so.1
   [4]  NEEDED0x6da5  libnsl.so.1
   [5]  NEEDED0x6db1  libdl.so.1
   [6]  NEEDED0x6d63  libpthread.so.1
   [7]  NEEDED0x6d85  libc.so.1
   [8]  INIT  0x1006caa58
   [9]  FINI  0x1006caa68
  [10]  RUNPATH   0x6dbc 
/usr/local/lib:/usr/local/ssl/lib
  [11]  RPATH 0x6dbc 
/usr/local/lib:/usr/local/ssl/lib

  [12]  HASH  0x101d0
  [13]  STRTAB0x1c9c0
  [14]  STRSZ 0x6fde
  [15]  SYMTAB0x133d8
  [16]  SYMENT0x18
  [17]  CHECKSUM  0x33bc
  [18]  VERNEED   0x1000139a0
  [19]  VERNEEDNUM0x5
  [20]  PLTRELSZ  0x7b60
  [21]  PLTREL0x7
  [22]  JMPREL0x100014a90
  [23]  RELA  0x100014700
  [24]  RELASZ0x7ef0
  [25]  RELAENT   0x18
  [26]  DEBUG 0
  [27]  SUNW_CAP  0x101b0
  [28]  FLAGS 0   0
  [29]  FLAGS_1   0   0
  [30]  SUNW_STRPAD   0x200
  [31]  SUNW_LDMACH   0x2bEM_SPARCV9
  [32]  PLTGOT0x1007ead00
   [33-43]  NULL  0

corv $ LD_LIBRARY_PATH=`pwd` ./apps/openssl version
OpenSSL 1.1.1-pre1 (alpha) 13 Feb 2018
corv $

So .. this is progress.

Dennis

ps: Oracle bugid 26277061 explains e_flags must only be EF_SPARCV9_TSO
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

>> And "the default for all v9 architectures is -xmemalign=8s".
> I'm getting confused.  Since I did not specify -xmemalign at all,

And not specifying -xmemalign is equivalent of specifying 8s in 64-bit
build such as one in question.

> why
> did the test fail with SIGBUS in the first place?  Seems like there
> should have been no alignment problem if the compiler is doing the right
> thing by default as you say.

Once again, objects on stack are *customarily* aligned at pointer size,
i.e. at 8 bytes in -xarch=v9 case, even if their declaration doesn't
imply corresponding guarantee. Or in other words, specifically in
context of this question, even though 'buf' is *not required* to be
aligned at 8 bytes by language standard, so far it was effectively
observed to be aligned anyway, at least on other RISC platforms. Now,
I'm *not* saying that we should *rely* on this custom, rather contrary,
we definitely should *not*. Question is what does the fact that it went
unnoticed till now mean. Or in more practical terms are there more such
dependencies that shouldn't be there? Because if possible, it would only
be appropriate to locate and eliminate them. In yet other words, mystery
is not why this specific test crashed on you, but rather what else can
crash (but doesn't for some reason).
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

On 2/21/2018 12:46 PM, Andy Polyakov wrote:

And "the default for all v9 architectures is -xmemalign=8s".
I'm getting confused.  Since I did not specify -xmemalign at all, why 
did the test fail with SIGBUS in the first place?  Seems like there 
should have been no alignment problem if the compiler is doing the right 
thing by default as you say.


Norm

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

> So really we could do all manner of nasty things here and watch all
> manner of performance results and cool coredumps and it would be fun to
> try.  However the option -xmemalign=8s will enforce "There should be no
> misaligned accesses in the program".

And "the default for all v9 architectures is -xmemalign=8s". Other
values are effectively for those who are lazy enough to fix broken code
taken from x86[_64]. Values other than 8s are also kind of "whole
application" things, i.e. it would be inappropriate to compile a
*library* [such as OpenSSL] with any other flag than -xmemalign=8s.
Which is why it *is* the default, has to be, so you don't have to
actually specify it. In other words assertion that not specifying
-xmemalign=8s is somehow wrong is not actually substantiated. Not
specifying it is perfectly appropriate. On related note OpenSSL is
periodically tested on RISC platforms and misalignment issues get ironed
out in time. [That's why I wondered how come it went unnoticed so far.]

Just in case for reference, default for 32-bit code is 8i. I assume that
it implies 4s, which would be consistent with expected RISC behaviour,
i.e. SIGBUS on register-sized loads/stores. Though there is ambiguity.
One would expect SIGBUG on double-precision floating point load/store
even on 32-bit system. So does 8i mean that it would actually tolerate
misaligned doubles?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 21/02/18 12:57 PM, Norm Green wrote:

On 2/21/2018 9:42 AM, Dennis Clarke wrote:

Which is correct way to do this on sparc systems.


Why do you say that?  We've been building OpenSSL on SPARC for the past 
7 years without that flag and it's worked just fine with only a few 
minor changes to the compile/link flags.


Norm



More simply ... there may be no code issue here at all.

This is a compiler issue.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 21/02/18 12:57 PM, Norm Green wrote:

On 2/21/2018 9:42 AM, Dennis Clarke wrote:

Which is correct way to do this on sparc systems.


Why do you say that?  We've been building OpenSSL on SPARC for the past 
7 years without that flag and it's worked just fine with only a few 
minor changes to the compile/link flags.




The whole idea here is that openssl ( like a lot of things ) is supposed
to be portable code across a whack of platforms and while I can not
recall the dusty memories of why this option was invented way way back
in time I can at least quote the manual :


B.2.144 -xmemalign=ab

(SPARC) Use the -xmemalign option to control the assumptions that the
compiler makes about the alignment of data. By controlling the code
generated for potentially misaligned memory accesses and by controlling
program behavior in the event of a misaligned access, you can more
easily port your code to the SPARC platform.


Right ... like it says.

However what we are not saying here is what happens ( sig sig core dump
and halt ) when the system attempts to reach out and touch memory in an
icky way?  You must provide a value for both alignment and behavior :

  Alignment  Behavior
  1 at most 1 byte alignment.i Interpret access and continue exec
  2 at most 2 byte alignment.s Raise signal SIGBUS
  4 at most 4 byte alignment.f same as specifying i when the
   alignment is 1, 2, or 4,
   also same as s when a=8 or 16

  8 at most 8 byte alignment.
 16 at most 16 byte alignment.

So really we could do all manner of nasty things here and watch all
manner of performance results and cool coredumps and it would be fun to
try.  However the option -xmemalign=8s will enforce "There should be no
misaligned accesses in the program".

So sayeth the manual going back way way back in time and so sayeth ye
gray beard here from experience.  So I guess that is why I would say
this is the right way to do stuff.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

On 2/21/2018 9:42 AM, Dennis Clarke wrote:

Which is correct way to do this on sparc systems.


Why do you say that?  We've been building OpenSSL on SPARC for the past 
7 years without that flag and it's worked just fine with only a few 
minor changes to the compile/link flags.


Norm

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

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 

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

[Norm Green]

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.


Norm

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

> On Feb 21, 2018, at 11:42 AM, Dennis Clarke  wrote:
> 
> On 21/02/18 09:14 AM, Viktor Dukhovni wrote:
>>> On Feb 21, 2018, at 5:06 AM, Andy Polyakov  wrote:
>>> 
>>> I wonder how come the problem with asn1_encode_test.c went unnoticed so
>>> far. Objects on stack are customarily aligned at pointer size, even if
>>> their declaration doesn't imply corresponding guarantee. So there are
>>> two options here: a) it's first time it's tested with SPARC Solaris cc
>>> (note that it is regularly tested on SPARC Linux, naturally with gcc);
>>> b) compiler was recently patched/upgraded. Do note that I don't dispute
>>> suggested fix (or compiler's "right" to misalign buf in this case), only
>>> wonder how come it worked so far. Implied question would be what are
>>> other possible implications of b).
>> The code introduced the misaligned "bug" is master-only, added in Apr/2017,
>> so quite possibly nobody has ever built in SunOS+SPARC, in which case it
>> never worked, but simply was never tested until now.
> 
> Pretty sure I have done builds and tests. In fact I am certain of it.

Were you testing "master"?  Or OpenSSL_1_1_0-stable?  The alignment of
"buf" is of course compiler-version dependent, and can also change from
unrelated later changes in the surrounding code.  In any case, the problem
code is comparatively recent (less than a year old), and only users testing
the master development branch on SPARC would have run into the issue.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 21/02/18 09:14 AM, Viktor Dukhovni wrote:




On Feb 21, 2018, at 5:06 AM, Andy Polyakov  wrote:

I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarantee. So there are
two options here: a) it's first time it's tested with SPARC Solaris cc
(note that it is regularly tested on SPARC Linux, naturally with gcc);
b) compiler was recently patched/upgraded. Do note that I don't dispute
suggested fix (or compiler's "right" to misalign buf in this case), only
wonder how come it worked so far. Implied question would be what are
other possible implications of b).


The code introduced the misaligned "bug" is master-only, added in Apr/2017,
so quite possibly nobody has ever built in SunOS+SPARC, in which case it
never worked, but simply was never tested until now.



Pretty sure I have done builds and tests. In fact I am certain of it.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

> On Feb 21, 2018, at 5:06 AM, Andy Polyakov  wrote:
> 
> I wonder how come the problem with asn1_encode_test.c went unnoticed so
> far. Objects on stack are customarily aligned at pointer size, even if
> their declaration doesn't imply corresponding guarantee. So there are
> two options here: a) it's first time it's tested with SPARC Solaris cc
> (note that it is regularly tested on SPARC Linux, naturally with gcc);
> b) compiler was recently patched/upgraded. Do note that I don't dispute
> suggested fix (or compiler's "right" to misalign buf in this case), only
> wonder how come it worked so far. Implied question would be what are
> other possible implications of b).

The code introduced the misaligned "bug" is master-only, added in Apr/2017,
so quite possibly nobody has ever built in SunOS+SPARC, in which case it
never worked, but simply was never tested until now.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

> https://github.com/openssl/openssl/pull/5423

I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarantee. So there are
two options here: a) it's first time it's tested with SPARC Solaris cc
(note that it is regularly tested on SPARC Linux, naturally with gcc);
b) compiler was recently patched/upgraded. Do note that I don't dispute
suggested fix (or compiler's "right" to misalign buf in this case), only
wonder how come it worked so far. Implied question would be what are
other possible implications of b).

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Andy Polyakov]

> Interesting comment :
> 
> 
>  Solaris x86 with Sun C setups
>     # There used to be solaris-x86-cc target, but it was removed,
>     # primarily because vendor assembler can't assemble our modules
>     # with -KPIC flag. As result it, assembly support, was not even
>     # available as option. But its lack means lack of side-channel
>     # resistant code, which is incompatible with security by todays
>     # standards. Fortunately gcc is readily available prepackaged
>     # option, which we can firmly point at...
>     #
>     # On related note, solaris64-x86_64-cc target won't compile code
>     # paths utilizing AVX and post-Haswell instruction extensions.
>     # Consider switching to solaris64-x86_64-gcc even here...
>     #
> 
> 
> Pre-packaged? Really ...

Nowadays you just pkgadd it from some common Oracle repository. Well, at
least on x86, as I have no idea if SPARC Solaris offers it. But the
comment is explicitly about x86.

> let's not go down the route of argument today.
> 
> 
>     "solaris64-sparcv9-cc" => {
>     inherit_from => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
>     cflags   => add_before("-xarch=v9"),
>     bn_ops   => "BN_LLONG RC4_CHAR",
>     multilib => "/64",
>     },
> 
> 
> Actually xarch=v9 is wrong.  Should just say "sparc".

So assertion is that compiler recognizes option -sparc? Don't see
anything of the sort in the manual page. Well, I can see that
contemporary compiler would recognize -xarch=sparc, but that's
*contemporary* version. But more importantly manual also says that
-xarch=v9 is equivalent to -m64 -xarch=sparc and -m64 is the essence of
this configuration. So -xarch=v9 is right, because it generates 64-bit
code and works with all compiler versions. [Well, one can probably argue
that it's time to reconsider meaning of "all compiler versions" in the
context, yet it wouldn't make "just say "sparc"" right :-)]
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Levitte]

In message <6088d4cb-7566-c216-1e28-0892641cd...@blastwave.org> on Tue, 20 Feb 
2018 21:17:32 -0500, Dennis Clarke  said:

dclarke> Have to dig around and see what LDCMD was intended to be.

LDCMD is a convenience variable for some users to specify a different
command than the configured C compiler for linking programs.  So
unless you define it specifically, it will remain undefined.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich via openssl-users]

https://github.com/openssl/openssl/pull/5423


On 2/20/18, 2:10 PM, "Salz, Rich via openssl-users" 
 wrote:

I agree, let's just use malloc for the reasons you said.  PR later today.

On 2/20/18, 2:08 PM, "Viktor Dukhovni"  wrote:



> On Feb 20, 2018, at 11:36 AM, Norm Green 
 wrote:
> 
> Your patch tests clean, however there is an easier way which avoids 
malloc:

Great, so it was the unaligned "buf".  Great.  As for malloc vs. tricks 
to
align the stack-based array, I see little need to avoid malloc() this 
is a
test function, not a performance-critical library function.  Exercising
OPENSSL_malloc() is arguably a feature. :-)

That said, I have no religion on which approach is taken to align "buf".
I prefer "malloc" because it unasks the question of which type to use
in an array or union to ensure the "proper" alignment.  Using any of
"long" or "long long" is likely good enough, but could prove more 
fragile
as the code evolves.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 20/02/18 01:36 PM, Norm Green wrote:

Hi Dennis,

You're right, I did modify the config file...



I have managed to get to the link stage here and ran into some odd
 syntax issue.

Have to dig around and see what LDCMD was intended to be.

${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc 
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs -g 
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=sparc64viiplus 
-xarch=sparcima -xchip=sparc64viiplus -xcache=64/64/2:11264/256/11 
-D_TS_ERRNO -D__EXTENSIONS__ -D_POSIX_C_SOURCE 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -L. -mt  \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o 
apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o 
apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o 
apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o 
apps/nseq.o apps/ocsp.o apps/openssl.o apps/passwd.o apps/pkcs12.o 
apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o 
apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o 
apps/rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o 
apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o 
apps/storeutl.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \

  apps/libapps.a -lssl -lcrypto -lz -lsocket -lnsl -ldl -lpthread
Undefined   first referenced
 symbol in file
OPENSSL_LH_stats_bioapps/asn1pars.o
SSL_stateless   apps/s_server.o
BN_GENCB_free   apps/dhparam.o
SSL_CTX_set_ctlog_list_file apps/libapps.a(apps.o)
TLS_client_method   apps/ocsp.o
SSL_SESSION_get0_cipher apps/s_client.o
OPENSSL_strlcpy apps/ca.o
OPENSSL_strlcat apps/ca.o
OPENSSL_sk_pop_free apps/asn1pars.o
SSL_CTX_set_options apps/s_time.o
BN_is_zero  apps/ca.o
BIO_ADDRINFO_free   apps/libapps.a(s_socket.o)
BIO_ADDRINFO_next   apps/libapps.a(s_socket.o)
SSL_is_dtls apps/libapps.a(s_cb.o)
BIO_sock_info   apps/s_client.o
OpenSSL_version apps/speed.o
PKCS12_SAFEBAG_get0_attrs   apps/pkcs12.o
PKCS12_SAFEBAG_get_nid  apps/pkcs12.o
PKCS12_SAFEBAG_get0_safes   apps/pkcs12.o
PKCS12_SAFEBAG_get0_p8inf   apps/pkcs12.o
PKCS12_SAFEBAG_get0_pkcs8   apps/pkcs12.o
SSL_get0_dane_authority apps/libapps.a(s_cb.o)
PEM_write_bio_PrivateKey_traditional apps/pkcs8.o
CRYPTO_clear_free   apps/dgst.o
SSL_CTX_set_default_read_buffer_len apps/s_client.o
SSL_write_early_dataapps/s_client.o
RSA_check_key_exapps/rsa.o
SSL_get1_supported_ciphers  apps/ciphers.o
SSL_SESSION_get_max_early_data  apps/s_client.o
EVP_PKEY_meth_get0  apps/openssl.o
X509_STORE_CTX_set0_trusted_stack   apps/verify.o
PKCS12_SAFEBAG_get0_attrapps/pkcs12.o
PKCS12_SAFEBAG_get0_typeapps/pkcs12.o
PKCS12_SAFEBAG_get1_certapps/pkcs12.o
ASN1_TIME_set_string_X509   apps/ca.o
OPENSSL_sk_dup  apps/asn1pars.o
OPENSSL_sk_pop  apps/asn1pars.o
OPENSSL_sk_num  apps/asn1pars.o
OPENSSL_sk_new  apps/asn1pars.o
OPENSSL_sk_set  apps/asn1pars.o
EVP_PKEY_meth_get_count apps/openssl.o
BIO_ADDRINFO_protocol   apps/libapps.a(s_socket.o)
SCT_validation_status_stringapps/s_client.o
SSL_ct_is_enabled   apps/s_client.o
IDEA_optionsapps/speed.o
IDEA_set_encrypt_keyapps/speed.o
PKCS8_pkey_get0_attrs   apps/pkcs12.o
RSA_generate_multi_prime_keyapps/genrsa.o
X509_STORE_CTX_get_obj_by_subject   apps/crl.o
X509_CRL_get0_nextUpdateapps/crl.o
X509_CRL_get0_lastUpdateapps/crl.o
ASN1_ITEM_lookupapps/asn1pars.o
SSL_get0_peer_CA_list   apps/libapps.a(s_cb.o)
X509_CRL_set1_nextUpdateapps/ca.o
X509_CRL_set1_lastUpdateapps/ca.o
SSL_CTX_dane_enable apps/s_client.o
SSL_CTX_set_default_ctlog_list_file apps/libapps.a(apps.o)
SSL_CTX_set_keylog_callback apps/libapps.a(s_cb.o)
X509_CRL_get0_signature apps/crl.o
PKCS8_set0_pbe  apps/pkcs8.o
EVP_MD_CTX_new  apps/ocsp.o
PKCS12_get0_mac apps/pkcs12.o
SSL_set_options apps/s_client.o
ASYNC_WAIT_CTX_free apps/speed.o
SSL_get_options apps/s_server.o
OPENSSL_sk_free apps/asn1pars.o
OPENSSL_sk_find apps/asn1pars.o
OPENSSL_sk_push   

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

[Dennis Clarke]

On 20/02/18 01:52 PM, Salz, Rich via openssl-users wrote:
  

 So ... this will be fun.

:)


Thanks for poking at this, folks.  Please take a look at the INSTALL and README files 
which do cover some of this prerequisites.  And then once you've "fixed" it, 
let us  know what we need to change!!



fixed? .. well .. hacked at for sure.

getting there .. hitting little snags as I go :

/opt/developerstudio12.6/bin/c99  -I. -Icrypto/include -Iinclude 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -Qy -xs -g -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xtarget=sparc64viiplus -xarch=sparcima -xchip=sparc64viiplus 
-xcache=64/64/2:11264/256/11 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -KPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -D_TS_ERRNO -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines-1.1\""  -c -o crypto/sparcv9cap.o 
crypto/sparcv9cap.c

"crypto/sparcv9cap.c", line 132: warning: no explicit type given
"crypto/sparcv9cap.c", line 132: error: syntax error before or at: 
common_jmp
"crypto/sparcv9cap.c", line 132: warning: old-style declaration or 
incorrect type for: common_jmp
"crypto/sparcv9cap.c", line 135: warning: implicit function declaration: 
siglongjmp
"crypto/sparcv9cap.c", line 214: warning: implicit function declaration: 
sigfillset
"crypto/sparcv9cap.c", line 215: warning: implicit function declaration: 
sigdelset
"crypto/sparcv9cap.c", line 223: warning: implicit function declaration: 
sigprocmask
"crypto/sparcv9cap.c", line 229: warning: implicit function declaration: 
sigaction
"crypto/sparcv9cap.c", line 233: warning: implicit function declaration: 
sigsetjmp

c99: acomp failed for crypto/sparcv9cap.c
gmake[1]: *** [Makefile:6253: crypto/sparcv9cap.o] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001'

gmake: *** [Makefile:143: all] Error 2
corv $

yep .


Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 20/02/18 02:06 PM, Erik Forsberg wrote:



-- Original Message --

On 20/02/18 12:47 PM, Norm Green wrote:

On 2/20/2018 5:43 AM, Michael Wojcik wrote:

<... snippage ...>


I also tried building with c99 instead of cc, without success.





I build my Solaris OpenSSL binaries using studo compiler 12.4 cc -xc99
Havent tried latest 1.1.1 snapshot yet though, probably a good time



working on it now .. gimme a few coffee cups to dig into this.

Dennis


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Erik Forsberg]

>-- Original Message --
>
>On 20/02/18 12:47 PM, Norm Green wrote:
>> On 2/20/2018 5:43 AM, Michael Wojcik wrote:
>>> Not by default. The comments in /usr/include/sys/feature_tests.h (on a 
>>> Solaris system) explain this in excruciating detail, but in short you 
>>> need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the 
>>> equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001).
>> Thanks for the suggestions Michael.  Neither resolves the problem. In 
>> fact, adding -D_XOPEN_SOURCE=600 causes a new problem:
>> 
>> /opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
>> -xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W 
>> -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H 
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
>> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
>> -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT 
>> -DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\""
>>  
>> -DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\""
>>  
>> -c -o crypto/bio/b_addr.o crypto/bio/b_addr.c
>> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
>> "crypto/bio/b_addr.c", line 198: variable length array can not be 
>> initialized: host
>> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
>> "crypto/bio/b_addr.c", line 198: variable length array can not be 
>> initialized: serv
>> c99: acomp failed for crypto/bio/b_addr.c
>> Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed
>> 
>> 
>> I also tried building with c99 instead of cc, without success.
>> 
>

I build my Solaris OpenSSL binaries using studo compiler 12.4 cc -xc99
Havent tried latest 1.1.1 snapshot yet though, probably a good time


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich via openssl-users]

I agree, let's just use malloc for the reasons you said.  PR later today.

On 2/20/18, 2:08 PM, "Viktor Dukhovni"  wrote:



> On Feb 20, 2018, at 11:36 AM, Norm Green  
wrote:
> 
> Your patch tests clean, however there is an easier way which avoids 
malloc:

Great, so it was the unaligned "buf".  Great.  As for malloc vs. tricks to
align the stack-based array, I see little need to avoid malloc() this is a
test function, not a performance-critical library function.  Exercising
OPENSSL_malloc() is arguably a feature. :-)

That said, I have no religion on which approach is taken to align "buf".
I prefer "malloc" because it unasks the question of which type to use
in an array or union to ensure the "proper" alignment.  Using any of
"long" or "long long" is likely good enough, but could prove more fragile
as the code evolves.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

> On Feb 20, 2018, at 11:36 AM, Norm Green  
> wrote:
> 
> Your patch tests clean, however there is an easier way which avoids malloc:

Great, so it was the unaligned "buf".  Great.  As for malloc vs. tricks to
align the stack-based array, I see little need to avoid malloc() this is a
test function, not a performance-critical library function.  Exercising
OPENSSL_malloc() is arguably a feature. :-)

That said, I have no religion on which approach is taken to align "buf".
I prefer "malloc" because it unasks the question of which type to use
in an array or union to ensure the "proper" alignment.  Using any of
"long" or "long long" is likely good enough, but could prove more fragile
as the code evolves.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 20/02/18 01:50 PM, Dennis Clarke wrote:

On 20/02/18 01:36 PM, Norm Green wrote:


Making progress here ...

/opt/developerstudio12.6/bin/c99  -I. -Icrypto/include -Iinclude 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -Qy -xs -g -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -KPIC 
-DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE 
-DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
-D_TS_ERRNO -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines-1.1\""  -c -o 
crypto/bio/bss_bio.o crypto/bio/bss_bio.c

"crypto/bio/bss_bio.c", line 244: error: undefined symbol: OSSL_SSIZE_MAX
"crypto/bio/bss_bio.c", line 400: error: undefined symbol: OSSL_SSIZE_MAX
c99: acomp failed for crypto/bio/bss_bio.c
gmake[1]: *** [Makefile:1781: crypto/bio/bss_bio.o] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001'

gmake: *** [Makefile:143: all] Error 2
corv $

let me track down that undef there


dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich via openssl-users]

 
> So ... this will be fun.
   
:)

Thanks for poking at this, folks.  Please take a look at the INSTALL and README 
files which do cover some of this prerequisites.  And then once you've "fixed" 
it, let us  know what we need to change!!

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 20/02/18 01:36 PM, Norm Green wrote:

Hi Dennis,

You're right, I did modify the config file, sorry.  I did it so long ago 
I had forgotten.  I will email it to you shortly.




Not a problem .. everyone does.

I mean look at this mess if you don't :


corv $ ./Configure shared zlib threads solaris64-sparcv9-cc
Perl v5.10.0 required--this is only v5.8.4, stopped at ./Configure line 12.
BEGIN failed--compilation aborted at ./Configure line 12.
corv $

uh huh.

I have newer perl I built myself but I generally start with the baseline
 system stuff .. which is covered in dust and mold :

corv $ /usr/local/bin/perl -V
Summary of my perl5 (revision 5 version 26 subversion 0) configuration:
.
.
.


So ... this will be fun.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

Hi Dennis,

You're right, I did modify the config file, sorry.  I did it so long ago 
I had forgotten.  I will email it to you shortly.


Norm


On 2/20/2018 10:14 AM, Dennis Clarke wrote:

On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did. Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Did you modify the Configure file ?  Last time I looked the CFLAGS
as well as some other bits in there were terribly out of date and
not really what we want for a debug build.

Dennis



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did.  Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Let's have a look.


corv $ uname -a
SunOS corv 5.10 Generic_150400-59 sun4u sparc SUNW,SPARC-Enterprise

corv $ /opt/developerstudio12.6/bin/c99 -V
c99: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30

corv $ psrinfo -pv
The physical processor has 8 virtual processors (0-7)
  SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)

corv $ pwd
/usr/local/src
corv $ cd ../build
corv $ gzip -dc ../src/openssl-1.1.1-pre1.tar.gz | tar -xf -
corv $ mv openssl-1.1.1-pre1 openssl-1.1.1-pre1_SunOS5.10_sparcv9.001
corv $ cd openssl-1.1.1-pre1_SunOS5.10_sparcv9.001
corv $ cp -p Configure Configure.backup
corv $ OPENSSL_SOURCE=`pwd`
corv $ export OPENSSL_SOURCE
corv $ echo $OPENSSL_SOURCE
/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.001

OKay .. whats going on here ?

corv $ grep -i "sparc" Configure

Doesn't exist ... has to have been moved somewhere.

These two files make reference to solaris64 in some way :

./Configurations/10-main.conf
./config




Interesting comment :


 Solaris x86 with Sun C setups
# There used to be solaris-x86-cc target, but it was removed,
# primarily because vendor assembler can't assemble our modules
# with -KPIC flag. As result it, assembly support, was not even
# available as option. But its lack means lack of side-channel
# resistant code, which is incompatible with security by todays
# standards. Fortunately gcc is readily available prepackaged
# option, which we can firmly point at...
#
# On related note, solaris64-x86_64-cc target won't compile code
# paths utilizing AVX and post-Haswell instruction extensions.
# Consider switching to solaris64-x86_64-gcc even here...
#


Pre-packaged? Really ... let's not go down the route of argument today.


"solaris64-sparcv9-cc" => {
inherit_from => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
cflags   => add_before("-xarch=v9"),
bn_ops   => "BN_LLONG RC4_CHAR",
multilib => "/64",
},


Actually xarch=v9 is wrong.  Should just say "sparc".

Well it looks like lots has changed ... so let me fish around in here
and find what is going on with Configure and its new sub-files and then
see if I can get a compile going as a debug build. Also I have gcc 7.2.0
here but there isn't any such thing as "pre-packaged".

Dennis








--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did.  Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Did you modify the Configure file ?  Last time I looked the CFLAGS
as well as some other bits in there were terribly out of date and
not really what we want for a debug build.

Dennis

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

Just download and build v1.1.1 pre alpha 1 on Solaris.  It's on 
ftp.openssl.org.  That's all I did.  Configure using 
solaris64-sparcv9-cc .  I'm using Solaris studio 12.3.


Norm


On 2/20/2018 10:01 AM, Dennis Clarke wrote:

On 20/02/18 12:47 PM, Norm Green wrote:

On 2/20/2018 5:43 AM, Michael Wojcik wrote:
Not by default. The comments in /usr/include/sys/feature_tests.h (on 
a Solaris system) explain this in excruciating detail, but in short 
you need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or 
the equivalent in the code) to compile with XPG6 (aka IEEE 
1003.1-2001).
Thanks for the suggestions Michael.  Neither resolves the problem. In 
fact, adding -D_XOPEN_SOURCE=600 causes a new problem:


/opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
-xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN 
-DBN_DIV2W -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN 
-DHAVE_DLFCN_H -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W 
-D_REENTRANT 
-DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" 
-DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" 
-c -o crypto/bio/b_addr.o crypto/bio/b_addr.c

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: host

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: serv

c99: acomp failed for crypto/bio/b_addr.c
Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed


I also tried building with c99 instead of cc, without success.




Is there a handy source tarball somewhere so that I may also have a
look at this?  I have had good success in the past with both c99 and
with fairly restrictive CFLAGS so I would like to look into this
also.

Dennis





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Dennis Clarke]

On 20/02/18 12:47 PM, Norm Green wrote:

On 2/20/2018 5:43 AM, Michael Wojcik wrote:
Not by default. The comments in /usr/include/sys/feature_tests.h (on a 
Solaris system) explain this in excruciating detail, but in short you 
need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the 
equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001).
Thanks for the suggestions Michael.  Neither resolves the problem. In 
fact, adding -D_XOPEN_SOURCE=600 causes a new problem:


/opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
-xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W 
-KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT 
-DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" 
-DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" 
-c -o crypto/bio/b_addr.o crypto/bio/b_addr.c

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: host

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: serv

c99: acomp failed for crypto/bio/b_addr.c
Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed


I also tried building with c99 instead of cc, without success.




Is there a handy source tarball somewhere so that I may also have a
look at this?  I have had good success in the past with both c99 and
with fairly restrictive CFLAGS so I would like to look into this
also.

Dennis



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

On 2/20/2018 5:43 AM, Michael Wojcik wrote:

Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris 
system) explain this in excruciating detail, but in short you need either 
-DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code) 
to compile with XPG6 (aka IEEE 1003.1-2001).
Thanks for the suggestions Michael.  Neither resolves the problem. In 
fact, adding -D_XOPEN_SOURCE=600 causes a new problem:


/opt/solarisstudio12.3/bin/c99  -I. -Icrypto/include -Iinclude -m64 
-xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W 
-KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT 
-DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" 
-DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" 
-c -o crypto/bio/b_addr.o crypto/bio/b_addr.c

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: host

"crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: variable length array can not be 
initialized: serv

c99: acomp failed for crypto/bio/b_addr.c
Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed


I also tried building with c99 instead of cc, without success.

Norm

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

Hi Viktor,

Your patch tests clean, however there is an easier way which avoids malloc:

Norm


Index: test/asn1_encode_test.c
===
--- test/asn1_encode_test.c (revision 43654)
+++ test/asn1_encode_test.c (working copy)
@@ -706,15 +706,16 @@
 return ret;
 }

 static int do_print_item(const TEST_PACKAGE *package)
 {
 #define DATA_BUF_SIZE 256
-    unsigned char buf[DATA_BUF_SIZE];
+    uint64_t _buf[DATA_BUF_SIZE / sizeof(uint64_t)];/* force 8-byte 
alignment */

+    unsigned char *buf = (unsigned char *) _buf;
 const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type);
-    ASN1_VALUE *o = (ASN1_VALUE *)
+    ASN1_VALUE *o = (ASN1_VALUE *)buf;
 int ret;

OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE);

 (void)RAND_bytes(buf, (int)package->encode_expectations_elem_size);
 ret = ASN1_item_print(bio_err, o, 0, i, NULL);




On 2/19/2018 9:00 PM, Viktor Dukhovni wrote:

On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote:


# ASN1_LONG_DATA:
#   success: TRUE
t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx at
line 155 in file "tasn_prn.c"
   155  || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) {

Perhaps aligning the item buffer (by using malloc) will help, does
the patch below address the problem?

diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c
index e9f459ad65..77fa9b5954 100644
--- a/test/asn1_encode_test.c
+++ b/test/asn1_encode_test.c
@@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input,
  static int do_print_item(const TEST_PACKAGE *package)
  {
  #define DATA_BUF_SIZE 256
-unsigned char buf[DATA_BUF_SIZE];
  const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type);
-ASN1_VALUE *o = (ASN1_VALUE *)
+ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE);
  int ret;
  
  OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE);
  
-(void)RAND_bytes(buf, (int)package->encode_expectations_elem_size);

+if (o == NULL)
+return 0;
+
+(void)RAND_bytes((unsigned char *)o,
+ (int)package->encode_expectations_elem_size);
  ret = ASN1_item_print(bio_err, o, 0, i, NULL);
+OPENSSL_free(o);
  
  return ret;

  }



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Norm Green
> Sent: Monday, February 19, 2018 17:02
> To: Benjamin Kaduk; openssl-users@openssl.org
> Subject: Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
> 
> For the failure in secmemtst, it appears that secure memory is not
> enabled per this code in ./crypto/mem_sec.c
> 
>   23 /* e_os.h includes unistd.h, which defines _POSIX_VERSION */
>   24 #if !defined(OPENSSL_NO_SECURE_MEMORY) &&
> defined(OPENSSL_SYS_UNIX) \
>   25 && defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L
>   26 # define IMPLEMENTED
>   27 # include 
>   28 # include 
>   29 # include 
>   30 # include 
>   31 # include 
>   32 # if defined(OPENSSL_SYS_LINUX)
>   33 #  include 
>   34 #  include 
>   35 #  include 
>   36 # endif
>   37 # include 
>   38 # include 
>   39 # include 
>   40 #endif
> 
> 
> 
> Solaris has this in sys/unistd.h
> 
> #ifndef _POSIX_VERSION
> #ifdef  _XPG6
> #define _POSIX_VERSION  200112L /* Supports IEEE Std 1003.1-2001 */
> #else
> #define _POSIX_VERSION  199506L /* Supports POSIX-1c DIS */
> #endif
> #endif /* _POSIX_VERSION */
> 
> I'm building with the native Oracle Solaris compiler which apparently
> does not define these macros.

Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris 
system) explain this in excruciating detail, but in short you need either 
-DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code) 
to compile with XPG6 (aka IEEE 1003.1-2001).

Solaris has always (well, since Solaris 2) been a bit cautious about making new 
standards the default, preferring backward compatibility as the default and 
requiring applications that want new features to set the appropriate feature 
macros. In this case, that's one of the two macros I listed above.

One of them should probably be added to the appropriate entries in Configure. I 
don't think it much matters which one; they ought to have the same effect, and 
neither is particularly clear to people who haven't had to dig into this stuff.

Disclaimer: I haven't tested this (in the OpenSSL case), just confirmed what 
feature_tests.h says.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

On Tue, Feb 20, 2018 at 01:26:02PM +, Salz, Rich via openssl-users wrote:
> Would making buf a union also avoid the problem?
> 
>   union { unsigned long dummy[2]; char buf[DATA_BUF_SIZE]; } d
> and then replace 'buf' with 'd.buf' in the code?

If alignment of "buf" is the issue, then yes, a suitable union
would be an alternative to using malloc.  We could make the union:

union {
unsigned long long dummyl;
ossl_uintmax_t dummym;
char  *dummyp;
char buf[DATA_BUF_SIZE];
} d;

just in case that's what it takes for the required alignment.  But,
OPENSSL_malloc() should do the job simply, without such hoop jumping.

Either way, the OP should confirm that aligning "buf" solves the
reported problem.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich via openssl-users]

Would making buf a union also avoid the problem?

union { unsigned long dummy[2]; char buf[DATA_BUF_SIZE]; } d
and then replace 'buf' with 'd.buf' in the code?


On 2/20/18, 12:00 AM, "Viktor Dukhovni"  wrote:

On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote:

> # ASN1_LONG_DATA:
> #   success: TRUE
> t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx at
> line 155 in file "tasn_prn.c"
>   155  || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) {

Perhaps aligning the item buffer (by using malloc) will help, does
the patch below address the problem?

diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c
index e9f459ad65..77fa9b5954 100644
--- a/test/asn1_encode_test.c
+++ b/test/asn1_encode_test.c
@@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input,
 static int do_print_item(const TEST_PACKAGE *package)
 {
 #define DATA_BUF_SIZE 256
-unsigned char buf[DATA_BUF_SIZE];
 const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type);
-ASN1_VALUE *o = (ASN1_VALUE *)
+ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE);
 int ret;
 
 OPENSSL_assert(package->encode_expectations_elem_size <= 
DATA_BUF_SIZE);
 
-(void)RAND_bytes(buf, (int)package->encode_expectations_elem_size);
+if (o == NULL)
+return 0;
+
+(void)RAND_bytes((unsigned char *)o,
+ (int)package->encode_expectations_elem_size);
 ret = ASN1_item_print(bio_err, o, 0, i, NULL);
+OPENSSL_free(o);
 
 return ret;
 }

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote:

> # ASN1_LONG_DATA:
> #   success: TRUE
> t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx at
> line 155 in file "tasn_prn.c"
>   155  || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) {

Perhaps aligning the item buffer (by using malloc) will help, does
the patch below address the problem?

diff --git a/test/asn1_encode_test.c b/test/asn1_encode_test.c
index e9f459ad65..77fa9b5954 100644
--- a/test/asn1_encode_test.c
+++ b/test/asn1_encode_test.c
@@ -709,15 +709,19 @@ static int do_encode_custom(EXPECTED *input,
 static int do_print_item(const TEST_PACKAGE *package)
 {
 #define DATA_BUF_SIZE 256
-unsigned char buf[DATA_BUF_SIZE];
 const ASN1_ITEM *i = ASN1_ITEM_ptr(package->asn1_type);
-ASN1_VALUE *o = (ASN1_VALUE *)
+ASN1_VALUE *o = OPENSSL_malloc(DATA_BUF_SIZE);
 int ret;
 
 OPENSSL_assert(package->encode_expectations_elem_size <= DATA_BUF_SIZE);
 
-(void)RAND_bytes(buf, (int)package->encode_expectations_elem_size);
+if (o == NULL)
+return 0;
+
+(void)RAND_bytes((unsigned char *)o,
+ (int)package->encode_expectations_elem_size);
 ret = ASN1_item_print(bio_err, o, 0, i, NULL);
+OPENSSL_free(o);
 
 return ret;
 }

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

For the failure in secmemtst, it appears that secure memory is not 
enabled per this code in ./crypto/mem_sec.c


 23 /* e_os.h includes unistd.h, which defines _POSIX_VERSION */
 24 #if !defined(OPENSSL_NO_SECURE_MEMORY) && defined(OPENSSL_SYS_UNIX) \
 25 && defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L
 26 # define IMPLEMENTED
 27 # include 
 28 # include 
 29 # include 
 30 # include 
 31 # include 
 32 # if defined(OPENSSL_SYS_LINUX)
 33 #  include 
 34 #  include 
 35 #  include 
 36 # endif
 37 # include 
 38 # include 
 39 # include 
 40 #endif



Solaris has this in sys/unistd.h

#ifndef _POSIX_VERSION
#ifdef  _XPG6
#define _POSIX_VERSION  200112L /* Supports IEEE Std 1003.1-2001 */
#else
#define _POSIX_VERSION  199506L /* Supports POSIX-1c DIS */
#endif
#endif /* _POSIX_VERSION */

I'm building with the native Oracle Solaris compiler which apparently 
does not define these macros.


Nornm


On 2/19/2018 1:20 PM, Norm Green wrote:

The output is not too long.



/export/localnew/sparc.Solaris/bin/gmake depend && 
/export/localnew/sparc.Solaris/bin/gmake _tests
gmake[1]: Entering directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
gmake[1]: Leaving directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
gmake[1]: Entering directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'

( cd test; \
  mkdir -p test-runs; \
  SRCTOP=../. \
  BLDTOP=../. \
  RESULT_D=test-runs \
  PERL="/opt/perl-5.24.0/bin/perl" \
  EXE_EXT= \
  OPENSSL_ENGINES=`cd .././engines; pwd` \
  OPENSSL_DEBUG_MEMORY=on \
    /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode 
test_secmem )

../test/recipes/04-test_asn1_encode.t ..
1..1
    # Subtest: ../../test/asn1_encode_test
    1..6
    ok 1 - test_long_32bit
    # ASN1_LONG_DATA:
    #   success: TRUE
../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138
not ok 1 - running asn1_encode_test

#   Failed test 'running asn1_encode_test'
#   at 
/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm 
line 77.

# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/90-test_secmem.t ...
1..1
    # Subtest: ../../test/secmemtest
    1..1
    # ERROR: (bool) 'CRYPTO_secure_malloc_init(4096, 32) == true' 
failed @ test/secmemtest.c:28

    # false
    not ok 1 - test_sec_mem
../../util/shlib_wrap.sh ../../test/secmemtest => 1
not ok 1 - running secmemtest

#   Failed test 'running secmemtest'
#   at 
/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm 
line 77.

# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

Test Summary Report
---
../test/recipes/04-test_asn1_encode.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=2, Tests=2,  2 wallclock secs ( 0.04 usr  0.01 sys + 0.38 cusr  
0.16 csys =  0.59 CPU)

Result: FAIL
Makefile:169: recipe for target '_tests' failed
gmake[1]: *** [_tests] Error 1
gmake[1]: Leaving directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'

Makefile:167: recipe for target 'tests' failed
gmake: *** [tests] Error 2
slow test failed



On 2/19/2018 12:50 PM, Benjamin Kaduk wrote:

On 02/19/2018 02:06 PM, Norm Green wrote:

Not sure if this is expected on this platform?

Test Summary Report
---
../test/recipes/04-test_asn1_encode.t    (Wstat: 256 Tests: 1
Failed: 1)
   Failed test:  1
   Non-zero exit status: 1
../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1
Failed: 1)
   Failed test:  1
   Non-zero exit status: 1
Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr  0.94 sys +
266.48 cusr 40.30 csys = 311.14 CPU)
Result: FAIL
Makefile:169: recipe for target '_tests' failed

I do not think it is expected.  Could you capture the output of 'make
V=1 TESTS="test_asn1_encode test_secmem"' and make it available?
(Probably via posting it on the web and linking; the output may be 
long.)


-Ben




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

You are correct, we are getting a SIGBUS.  Solaris SPARC does not allow 
unaligned data access:


(dbx) run
Running: asn1_encode_test
(process id 11159)
Reading libc_psr.so.1
Reading libscf.so.1
Reading libdoor.so.1
Reading libuutil.so.1
Reading libgen.so.1
Reading libmd.so.1
Reading libmp.so.2
1..6
ok 1 - test_long_32bit
# ASN1_LONG_DATA:
#   success: TRUE
t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx 
at line 155 in file "tasn_prn.c"

  155  || (it->utype != V_ASN1_BOOLEAN)) && *fld == NULL) {
(dbx) where
current thread: t@1
=>[1] asn1_item_print_ctx(out = 0x1001453c0, fld = 0x7fffd6dc, 
indent = 2, it = 0x7f3a29f0, fname = 0x100033ad8 "test_long", 
sname = (nil), nohdr = 0, pctx = 0x7f39e8f8), line 155 in 
"tasn_prn.c"
  [2] asn1_template_print_ctx(out = 0x1001453c0, fld = 
0x7fffd6dc, indent = 2, tt = 0x100137808, pctx = 
0x7f39e8f8), line 328 in "tasn_prn.c"
  [3] asn1_item_print_ctx(out = 0x1001453c0, fld = 0x7fffd5e0, 
indent = 0, it = 0x1001376c8, fname = (nil), sname = 0x100033af8 
"ASN1_LONG_DATA", nohdr = 0, pctx = 0x7f39e8f8), line 241 in 
"tasn_prn.c"
  [4] ASN1_item_print(out = 0x1001453c0, ifld = 0x7fffd6d4, 
indent = 0, it = 0x1001376c8, pctx = 0x7f39e8f8), line 131 in 
"tasn_prn.c"
  [5] do_print_item(package = 0x100135e68), line 720 in 
"asn1_encode_test.c"

  [6] test_intern(package = 0x100135e68), line 815 in "asn1_encode_test.c"
  [7] test_long_64bit(), line 832 in "asn1_encode_test.c"
  [8] run_tests(test_prog_name = 0x7fffef88 
"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/asn1_encode_test"), 
line 205 in "driver.c"

  [9] main(argc = 1, argv = 0x7fffec08), line 51 in "main.c"
(dbx)


On 2/19/2018 1:30 PM, Viktor Dukhovni wrote:



On Feb 19, 2018, at 4:20 PM, Norm Green  wrote:

/export/localnew/sparc.Solaris/bin/gmake depend && 
/export/localnew/sparc.Solaris/bin/gmake _tests
gmake[1]: Entering directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
gmake[1]: Leaving directory '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
gmake[1]: Entering directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
( cd test; \
   mkdir -p test-runs; \
   SRCTOP=../. \
   BLDTOP=../. \
   RESULT_D=test-runs \
   PERL="/opt/perl-5.24.0/bin/perl" \
   EXE_EXT= \
   OPENSSL_ENGINES=`cd .././engines; pwd` \
   OPENSSL_DEBUG_MEMORY=on \
 /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode 
test_secmem )
../test/recipes/04-test_asn1_encode.t ..
1..1
 # Subtest: ../../test/asn1_encode_test
 1..6
 ok 1 - test_long_32bit
 # ASN1_LONG_DATA:
 #   success: TRUE
../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138

On FreeBSD signal 10 (128 + 10 == 138) is SIGBUS, which could be a result of 
unaligned
data access (please report "kill -l" output to confirm the signal numbers).

Could you run this test under gdb, or enable core dumps, and report the stack 
trace?
You may need a build with debugging symbols.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Viktor Dukhovni]

> On Feb 19, 2018, at 4:20 PM, Norm Green  wrote:
> 
> /export/localnew/sparc.Solaris/bin/gmake depend && 
> /export/localnew/sparc.Solaris/bin/gmake _tests
> gmake[1]: Entering directory 
> '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
> gmake[1]: Leaving directory 
> '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
> gmake[1]: Entering directory 
> '/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
> ( cd test; \
>   mkdir -p test-runs; \
>   SRCTOP=../. \
>   BLDTOP=../. \
>   RESULT_D=test-runs \
>   PERL="/opt/perl-5.24.0/bin/perl" \
>   EXE_EXT= \
>   OPENSSL_ENGINES=`cd .././engines; pwd` \
>   OPENSSL_DEBUG_MEMORY=on \
> /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode 
> test_secmem )
> ../test/recipes/04-test_asn1_encode.t ..
> 1..1
> # Subtest: ../../test/asn1_encode_test
> 1..6
> ok 1 - test_long_32bit
> # ASN1_LONG_DATA:
> #   success: TRUE
> ../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138

On FreeBSD signal 10 (128 + 10 == 138) is SIGBUS, which could be a result of 
unaligned
data access (please report "kill -l" output to confirm the signal numbers).

Could you run this test under gdb, or enable core dumps, and report the stack 
trace?
You may need a build with debugging symbols.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Norm Green]

The output is not too long.



/export/localnew/sparc.Solaris/bin/gmake depend && 
/export/localnew/sparc.Solaris/bin/gmake _tests
gmake[1]: Entering directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
gmake[1]: Leaving directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'
gmake[1]: Entering directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'

( cd test; \
  mkdir -p test-runs; \
  SRCTOP=../. \
  BLDTOP=../. \
  RESULT_D=test-runs \
  PERL="/opt/perl-5.24.0/bin/perl" \
  EXE_EXT= \
  OPENSSL_ENGINES=`cd .././engines; pwd` \
  OPENSSL_DEBUG_MEMORY=on \
    /opt/perl-5.24.0/bin/perl .././test/run_tests.pl test_asn1_encode 
test_secmem )

../test/recipes/04-test_asn1_encode.t ..
1..1
    # Subtest: ../../test/asn1_encode_test
    1..6
    ok 1 - test_long_32bit
    # ASN1_LONG_DATA:
    #   success: TRUE
../../util/shlib_wrap.sh ../../test/asn1_encode_test => 138
not ok 1 - running asn1_encode_test

#   Failed test 'running asn1_encode_test'
#   at 
/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm 
line 77.

# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/90-test_secmem.t ...
1..1
    # Subtest: ../../test/secmemtest
    1..1
    # ERROR: (bool) 'CRYPTO_secure_malloc_init(4096, 32) == true' 
failed @ test/secmemtest.c:28

    # false
    not ok 1 - test_sec_mem
../../util/shlib_wrap.sh ../../test/secmemtest => 1
not ok 1 - running secmemtest

#   Failed test 'running secmemtest'
#   at 
/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/test/../util/perl/OpenSSL/Test/Simple.pm 
line 77.

# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

Test Summary Report
---
../test/recipes/04-test_asn1_encode.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=2, Tests=2,  2 wallclock secs ( 0.04 usr  0.01 sys + 0.38 cusr  
0.16 csys =  0.59 CPU)

Result: FAIL
Makefile:169: recipe for target '_tests' failed
gmake[1]: *** [_tests] Error 1
gmake[1]: Leaving directory 
'/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1'

Makefile:167: recipe for target 'tests' failed
gmake: *** [tests] Error 2
slow test failed



On 2/19/2018 12:50 PM, Benjamin Kaduk wrote:

On 02/19/2018 02:06 PM, Norm Green wrote:

Not sure if this is expected on this platform?

Test Summary Report
---
../test/recipes/04-test_asn1_encode.t    (Wstat: 256 Tests: 1
Failed: 1)
   Failed test:  1
   Non-zero exit status: 1
../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1
Failed: 1)
   Failed test:  1
   Non-zero exit status: 1
Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr  0.94 sys +
266.48 cusr 40.30 csys = 311.14 CPU)
Result: FAIL
Makefile:169: recipe for target '_tests' failed

I do not think it is expected.  Could you capture the output of 'make
V=1 TESTS="test_asn1_encode test_secmem"' and make it available?
(Probably via posting it on the web and linking; the output may be long.)

-Ben


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Benjamin Kaduk via openssl-users]

On 02/19/2018 02:06 PM, Norm Green wrote:
> Not sure if this is expected on this platform?
>
> Test Summary Report
> ---
> ../test/recipes/04-test_asn1_encode.t    (Wstat: 256 Tests: 1
> Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> ../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1
> Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr  0.94 sys +
> 266.48 cusr 40.30 csys = 311.14 CPU)
> Result: FAIL
> Makefile:169: recipe for target '_tests' failed

I do not think it is expected.  Could you capture the output of 'make
V=1 TESTS="test_asn1_encode test_secmem"' and make it available? 
(Probably via posting it on the web and linking; the output may be long.)

-Ben
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users