Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

[Andy Polyakov via RT]

> - GCC 6.1.0 is: KO, 64 & 32 bits:
> #   Failed test 'running evp_test evptests.txt'
> #   at ../test/recipes/30-test_evp.t line 18.
> # Looks like you failed 1 test of 1.
> ../test/recipes/30-test_evp.t ..
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/1 subtests

Phew! Mystery solved! Verify attached patch. Trouble was that vector
ChaCha subroutine relies on its alignment in memory. But on AIX it's
impossible to *control* alignment with desired granularity without
specifying higher alignment for .text segment itself. And .text
directive was missing in chacha-ppc module :-( So it's not exactly
optimizations of ppccap.o that mattered, but its changing size depending
on optimization options that was affecting chacha subroutine's
alignment. It actually *could* be vice versa, i.e. work with
optimizations on and fail without, it's all about a coincidence.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667
Please log in as guest with password guest if prompted

diff --git a/crypto/chacha/asm/chacha-ppc.pl b/crypto/chacha/asm/chacha-ppc.pl
index b978f58..8a54cba 100755
--- a/crypto/chacha/asm/chacha-ppc.pl
+++ b/crypto/chacha/asm/chacha-ppc.pl
@@ -133,6 +133,7 @@ my 
($a3,$b3,$c3,$d3)=map(($_&~3)+(($_+1)&3),($a2,$b2,$c2,$d2));
 
 $code.=<<___;
 .machine   "any"
+.text
 
 .globl .ChaCha20_ctr32_int
 .align 5
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

[Andy Polyakov via RT]

> Note that a 32-bit Perl can be compiled with or without support for 64-bit 
> integers.
> That fact hit me once doing OpenSSL builds, some 64-bit constants were not
> calculated correctly, however that showed up at build time so not likely
> to be the case here. However, it might be helpful checking if the 32-bit perl
> in question supports 64-bit or not.

Those problems were addressed and both configurations are known to work.
For example 32-bit perl I use by default on Linux is *not* compiled with
64-bit integers, while 32-bit perl I have on Solaris is. No problem with
either. It appears to me that problem is likely to occur at sign
extension when processing effective addresses. To demonstrate this with
one-liner:

perl -e 'use integer; printf "%d\n",0x<<32>>32'

It should print -1 in either combination of bitnesses.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

[Andy Polyakov via RT]

> I'm sorry to be late.
> I was too busy and had to prepare 64 bit gdb (& 64 bit perl).
> 
> It seems to be 32 bit perl (perl-5.24.0) problem.
> (Generating 64 bit code with  32 bit perl.)

For reference, I'm using 32-bit perl version 5.10.1, minimally supported
version, by default, i.e. *all* the time. Well, not on Solaris, on
Linux, but I do use it with 64-bit builds. As well with cross-compile
builds for a handful qemu-based environments, 32- and 64-bit ones, and
with mingw/wine. As for Solaris, I can say that 32-bit perl version
5.12.5 works for me. Bottom line is that perl's 32-bitness doesn't seem
to be the problem, on the contrary, it's actually *known* to be capable
of generating 64-bit assembly code, and failure to do so will be caught
swiftly.

> Tested with openssl-1.1.0 instead of pre-6,
> and on pure Solaris 10, without any VM.
> 
> 
> (1) with 32 bit perl
> Did test/hmactest under gdb, break,
> confirmed it was in OPENSSL_cleanse,
> "leaq -0(%rsi),%rsi" (not "lea 0(%rdi),%rdi")
> and making a short loop.
> 
> (2) with 64 bit perl
> make test passed both with gcc 5.4.0 & developerstudio12.5.

In other words it's effectively confirmed that it's not really OpenSSL
problem, but likely to be a problem with specific Solaris perl binary. I
wonder if you could find opportunity to post broken crypto/x86_64cpuid.s
generated by this broken perl, please?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

[Andy Polyakov via RT]

> About openssl built/tested on AIX 7.1 , I have an AIX 7.1 machine.
> Would you mind saying me which compiler was used ? GCC I guess. Which version 
> ?

The reason for why I said "I'll look at it a bit later today" is that
accessing that system is problematic for me for this very moment. And
since I don't keep version in mind, I can't tell :-) Sorry...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

[Andy Polyakov via RT]

> About the possible "linker quirk", the same linker is used also for version 
> 1.0.2h which runs perferctly.

Yes, but 1.0.2 and 1.1 ppccap's are different.

> Also, that does not explain why simply compiling ppccap.c only with -O0 makes 
> the issue to dispappear.

Bugs seldom make sense. If they did, we would spot them prior they
manifest themselves, so there would be no bugs :-)

> I also tried to repeat the failing test several times: failure is consistent.
> 
> 
> Here below are the details you asked.

Thanks! I've have closer look at it a bit later today. Just in case,
1.1. was tested on AIX 7.x...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

[Andy Polyakov via RT]

> Results:
> 
> 
> In short:
>  - no issue with v1.0.2h on both machines
>  - issue appears with:
>   - XLC -O but only for 64bits
>   - GCC -O for both 64bits and 32bits
>  - issue disappears when building ppccap.c with -O0 .
> 
> So, I think that the probability that both XLC and GCC have an issue when 
> optimizing ppccap.c is very low.

What they have in common is that they both use same linker, so they both
can trigger some linker quirk...

> So, I guess that ppccap.c has something special.

Could you tell which test does it fail? In order to do that run 'make
test TESTS=test_evp VERBOSE=1' and note which line[s] it fails.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS

[Andy Polyakov via RT]

> With the current build system, user-defined CFLAGS are accepted as any
> unrecognized command line argument passed to Configure. This seems a
> little dangerous to me since it means a simple typo could end up
> getting passed to the C compiler.

Is it more dangerous than interactive access? But on serious note I
don't quite grasp the problem. How do you pass CFLAGS? Or rather how is
it specific to OpenSSL? I mean you either set CFLAGS environment
variable and call 'make -e' or call 'make CFLAGS=something', right? But
this is the way *make* is. Or is suggestion that we should implement own
internal .ext1.ext2 rules independent on CFLAGS?

> As well, the current build system forcibly enables optimization (-O3)
> or debug symbols (-g) depending on the build type (--release or
> --debug).

Could you elaborate on the problem? If you need release build with debug
symbols you can simply add -g when configuring...

> There does not appear to be any method for the user to pass additional
> LDFLAGS to the build system.

You can pass them as arguments to ./Configure script. It recognizes -L,
-l and -Wl,.

> I would like to propose the following changes:
> 
> 1. Read CFLAGS and LDFLAGS from the environment within the Configure script.
> 2. Allow the user to opt-out of the default release or debug cflags,
> perhaps by adding a third build type (neither release nor debug).
> 
> These changes would my job as a distro maintainer on Gentoo Linux just
> a little bit easier.

Or maybe ("maybe" is reference to "I don't quite grasp" above) what we
are talking about is Configure reading CFLAGS and LDFLAGS and *adding*
them to generated Makefile. I mean we are not talking about passing them
to 'make', but "freezing" them to their values at configure time. Could
you clarify?



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Andy Polyakov via RT]

There are two commits, one that addresses bio_enc problems and one
adding test. Please double-check.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4647] bug report: OpenSSL 1.0.2h: Segment fault on AIX Power8 using optimization code

[Andy Polyakov via RT]

Hi,

> We are using libcurl for REST programming, which internally uses openssl
> and libcrypto.
> curl suggested to implement few callbacks related to locking, which would
> be needed for openssl below 1.1 version(which is still in beta).
> 
> The following callbacks were implemented:
> 
> https://curl.haxx.se/libcurl/c/threaded-ssl.html
> 
> lock_callback, thread_id, init_locks, kill_locks
> 
> With these modifications we are facing a crash in openssl library when used
> on a Power8 Hardware (with optimizations).

The fact that it's affected by optimizations is likely to be
circumstantial. I'm not convinced that it's not MT problem with your
application, and whether or not crash is triggered is question of
delicate yet unfortunate timing. And that's what is affected by
optimizations, timing. Questions are. You say you implement the
callbacks, but are they actually engaged? Is your openssl actually
compiled with threads support? Which configuration target/config line
was used to compile it?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4647
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4648] openssl doesn't work on mingw

[Andy Polyakov via RT]

> If goal actually is to execute openssl at msys command prompt, then
> openssl should be compiled *for* msys, but we don't actually support
> this configuration.

On related note it appears that reason for why the question about msys
support wasn't risen so far is because prior Windows 10, prompting from
plain Windows console applications such as openssl.exe was working in
msys window. In Windows 10 it apparently doesn't anymore, with symptoms
similar to ones reported here. The problem is not specific to master
branch (where prompting was modified to handle non-ASCII characters),
1.0.2 suffers from same problem too.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4648
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4654] Failed OpenSSL 1.0.2 compile on Debian 8 with shared config option

[Andy Polyakov via RT]

> I'm working from the 1.0.2h tarball. The platform is Debian 8 (booted
> with syscall.x32=y, but the X32 chroot was not entered). GCC is 5.2.1.
> 
> '-fPIC' was manually added after 'shared' caused the initial
> "relocation R_X86_64_32 ..." error. Omitting 'shared' does not witness
> an error.

32 in R_X86_64_32 is not reference to X32. 64-bit objects use this kind
of relocation fluently. Though in PIC context it should be R_X86_64_PC32.

> $ reset && ./config shared -fPIC no-ssl2 no-ssl3 no-comp
> -Wl,-rpath=/usr/local/ssl/lib --prefix=/usr/local/ssl
> CC=gcc
> CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -Wa,--noexecstack -m64 -DL_ENDIAN -O3
> -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM

Note that now you have two -fPIC options on compiler command line. I'm
not saying that two option would be harmful, only that you seem to be
looking in wrong place, lack of -fPIC option is not the problem. At the
same time I'm not saying that I know what would be the right place to
look in, as I don't. Can you actually confirm that if you 'rm
crypto/bn/rsaz_exp.o' and re-run 'make' still fails? On the other hand
even if you can, rsaz_exp is a C module and if it being compiled with
-fPIC doesn't come out right, there is nothing we can do about it. As we
already did our part, passed -fPIC...

> /usr/bin/ld: libcrypto.a(rsaz_exp.o): relocation R_X86_64_32 against
> `.rodata' can not be used when making a shared object; recompile with
> -fPIC
> libcrypto.a(rsaz_exp.o): error adding symbols: Bad value
> collect2: error: ld returned 1 exit status


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4654
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4636] Re: [openssl.org #4625] Re: Are the point-at-infinity checks in ecp_nistz256 correct?

[Andy Polyakov via RT]

Consider attached diff.

> The issue is particularly clear when we multiply the generator by
> zero. Note that in general, an application shouldn't multiply the
> generator by zero since there's no useful cryptographic purpose for
> doing so. But, this is a convenient example.
> 
> In the code we have,
> 
> ecp_nistz256_gather_w7(, preComputedTable[0], wvalue >> 1);
> ecp_nistz256_neg(p.p.Z, p.p.Y);
> copy_conditional(p.p.Y, p.p.Z, wvalue & 1);
> memcpy(p.p.Z, ONE, sizeof(ONE));
> 
> The generator is all zeros, so we'll start off with the point (0, 0,
> 1). Then we add the point at infinity over and over again, leaving
> that point unchanged each time. Thus, we'll end with (0, 0, 1). Then:
> 
> r->Z_is_one = is_one(p.p.Z) & 1;
> 
> Thus, the resulting point will be (0, 0, 1).
> 
> After the memcpy quoted above, we need to do a copy_conditional(p.p.Z,
> is_infinity, ZERO) or equivalent, where ZERO is all-zeros and where
> is_infinity is the result of checking if (x, y) == (0, 0).
> 
> This is just one example of an edge case that is handled in a
> surprising way. I think there are more, as described in the quoted
> message below.
> 
> Cheers,
> Brian
> 
> 
> Brian Smith  wrote:
>>
>> Brian Smith  wrote:
>>>
>>> When doing math on short Weierstrass curves like P-256, we have to
>>> special case points at infinity. In Jacobian coordinates (X, Y, Z),
>>> points at infinity have Z == 0. However, instead of checking for Z ==
>>> 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it
>>> does, in some sense, the opposite of what I expect it to do.
>>
>>
>> I exchanged email with both of the original authors of the code, Shay and 
>> Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent 
>> the point at infinity as (0, 0) and it is expected (but I did not verify) 
>> that those functions should work when the point at infinity is encoded as 
>> (0, 0, _).
>>
>>> The authors
>>> instead decided to encode the point at infinity as (0, 0), since the
>>> affine point (0, 0) isn't on the P-256 curve. It isn't clear why the
>>> authors chose to do that though, since the point at infinity doesn't
>>> (can't, logically) appear in the table of precomputed multiples of G
>>> anyway.
>>
>>
>> Actually, as the code says, the point at infinity implicitly occurs in the 
>> table implicitly. Obviously the accumulator point will be at infinity until 
>> at least a one bit is found in the scalar.
>>
>>>
>>> But, it seems like the functions that do the computations, like
>>>
>>> ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the
>>> point at infinity as (_, _, 0), not necessarily (0, 0, _). Also,
>>> ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and
>>> ec_GFp_simple_point_set_to_infinity, which represent the point at
>>> infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine
>>> uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0.
>>> This inconsistency is confusing, if not wrong. Given this, it seems
>>> like the point-at-infinity checks in the ecp_nistz256_point_add and
>>> ecp_nistz256_point_add_affine code should also be checking that z == 0
>>> instead of (x, y) == (0, 0).
>>
>>
>> Instead, when we convert a point from EC_POINT to P256_POINT or 
>> P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0, 0) 
>> form. And/or reject points at infinity as inputs to the function. Similarly, 
>> when we convert the resultant P256_POINT to an EC_POINT, we chould translate 
>> the (0, 0) encoding of the point at infinity to the (0, 0, 0) form or at 
>> least the (_, _, 0) form.
>>
>> In particular, consider the case where you have an EC_POINT that isn't at 
>> infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it. Then 
>> it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even though 
>> you shouldn't.
>>
>> Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the 
>> input points are at infinity, in which case it doesn't matter. (But if so, 
>> maybe these functions should do a point-at-infinity check.) But if it is 
>> allowed to pass in the point at infinity, then the ecp_nistz256 code should 
>> translate the input point from (_, _, 0) form to (0, 0, _) form before doing 
>> the computation. It can use is_zero and copy_conditional and friends to do 
>> this.
>>
>> Similarly, after the computation, it should translate the (0, 0, _) form to 
>> (_, _, 0) form. In particular, it should do such a translation before the 
>> code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the 
>> form (0, 0, 0) instead of (0, 0, _) in which case this translation might not 
>> be necessary.
>>
>> Regardless, it would be useful to write tests for these cases:
>> 1. Verify that the result is correct when any of the input points are (0, 0, 
>> 0)
>> 2. Verify that the result is correct when any of the input 

Re: [openssl-dev] [openssl.org #4648] openssl doesn't work on mingw

[Andy Polyakov via RT]

> I tested the following command on fedora 24 and mingw64 (mingw64 installed 
> via git for windows):
> 
> openssl genrsa -des3 -out server.key 1024
> 
> On fedora, it's instantaneous.
> On mingw64, it's stuck before asking the key:
> 
> Generating RSA private key, 1024 bit long modulus
> ..++
> ++

There is certain ambiguity in problem description... I mean I don't
quite grasp what exactly was attempted. Thing is that it's possible to
cross-compile openssl with mingw compiler on Linux, and it's even
possible to execute Windows binaries on Linux transparently, i.e.
directly at Linux command prompt as if it was normal Linux command,
under wine. This is actually what is regularly tested and if this is
your case, then I can't say that I can reproduce the problem. But at the
same time that's what is likely to make me fail to grasp the problem
description:-) Anyway. What I can imagine to be problematic is that you
run windows binary in msys shell window. Thing is that even though you'd
use msys shell to compile openssl binary, resulting binary is plain
windows one, and it's not given that it can inter-operate with msys
shell window. Rather contrary actually. To verify if this is the case,
just start plain cmd session and attempt the command in question there.
If goal actually is to execute openssl at msys command prompt, then
openssl should be compiled *for* msys, but we don't actually support
this configuration. In either case, question is if you could elaborate
more on conditions under which this happens. And what openssl version is
it? Reference to "installed via git for windows" suggests that it's
development master branch, but you'd need to be more specific.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4648
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

[Andy Polyakov via RT]

Hi,

> I have no time to check with debugger now,

Then no progress will be made. Problem needs to be identified first, and
since similar problem was identified earlier, I'd have to insist on
confirmation whether or not it's the same.

> but I do not think it is caused by assembler,
> because,
> - gcc-5.4.0 with gas (GNU Binutils) 2.27
> - cc (Solaris developerstudio12.5) with /usr/ccs/bin/as
> have the same result (see openssl.org #4642 also).
> 
> perl version which I use is v5.24.0.

Well, (assuming for a moment it's the same problem) there is *less*
reason to believe that x86_64cpuid.pl is broken. Because it's used with
a *number* of other toolchains, Linux, BSD, mingw, MSVC, without any
problem. Nor can I reproduce the problem on my Solaris VM. It's not as
fancy as yours, apparently, but it also kind of speak in favour of
suggestion that it's not an OpenSSL problem...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4584] Self test failures under X32

[Andy Polyakov via RT]

> ( cd test; \
>   SRCTOP=../. \
>   BLDTOP=../. \
>   PERL="perl" \
>   EXE_EXT= \
>   OPENSSL_ENGINES=.././engines \
> perl .././test/run_tests.pl test_afalg )
> ../test/recipes/30-test_afalg.t ..
> 1..1
> ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address
> test_afalg_aes_128_cbc() failed encryption
> ../util/shlib_wrap.sh ./afalgtest => 1
> not ok 1 - running afalgtest
> 
> #   Failed test 'running afalgtest'
> #   at ../test/recipes/30-test_afalg.t line 23.
> # Looks like you failed 1 test of 1.
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/1 subtests

For reference, problem is not specific to x32, real x86 32-bit build
fails in same manner as well. [As well as executed under qemu-user, but
we are probably not in position to expect *that* work.] What's common
between x32 and x86 is that system calls pass an "emulation" layer where
32-bit arguments are adjusted for 64-bit kernel and return values back
for 32-bit application...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

[Andy Polyakov via RT]

Hi,

> make test stops on Solaris10 x64.
> 
> 
> % ./Configure solaris64-x86_64-gcc
> 
> % make
> % make test
>:
> ../test/recipes/01-test_abort.t  ok   
> ../test/recipes/01-test_sanity.t ... ok   
> ../test/recipes/01-test_symbol_presence.t .. ok   
> ../test/recipes/02-test_ordinals.t . ok   
> ../test/recipes/05-test_bf.t ... ok   
> ../test/recipes/05-test_cast.t . ok   
> ../test/recipes/05-test_des.t .. ok   
> ../test/recipes/05-test_fuzz.t . ok 
> ../test/recipes/05-test_hmac.t . 

There was private report about similar problem. I mean if you can
confirm that it's stuck in OPENSSL_cleanse, then it's same problem(*).
Trouble is that it doesn't seem to be OpenSSL problem, because generated
code appears to be mis-compiled. When single-stepping with 'stepi' you
are likely to observe "lea 0(%rdi),%rdi" instruction, and it should be
"lea 1(%rdi),%rdi". I mean it *is* "lea 1(%rdi),%rdi" in source file,
crypto/x86_64cpuid.pl, and that's where our responsibility ends. In
sense that we are responsible for providing source, and you are
effectively responsible for providing working compiler environment. I
don't know which components were involved in first report, I mean things
like perl version, which assembler and its version, so I can't give any
advice about updates that might be required...

(*) To confirm run test/hmactest under debugger, break, see if it's in
OPENSSL_cleanse, issue 'stepi' command few times to see if it's going
"in circles".


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4530] [BUG] OpenSSL crash on Windows 10

[Andy Polyakov via RT]

Hi,

> Hi, our team have been experiencing a crash in some production
> machines (which I cannot reproduce in development machines) caused by
> the libeay32 module in 64 bits Windows 10 machines.
> 
> I was able to create a simple "crash application" and was able to get
> the dump of the crash along with PDB files for both the libeay32.dll
> and the sample application.
> 
> The exception code being thrown is 0xC005 (invalid memory access)
> and occurs inside sha1_block_data_order_shaext(), sha1-x86_64.asm,
> line 1435. The version used was 1.0.2g (but older versions also crash
> - the latest dev version from github crash as well).

Oh! Your machines don't seem like something everybody has :-) I mean
SHAEXT-capable CPUs are rare... Anyway, please verify attached patch.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4530
Please log in as guest with password guest if prompted

diff --git a/crypto/sha/asm/sha1-x86_64.pl b/crypto/sha/asm/sha1-x86_64.pl
index e8f61ab..97baae3 100755
--- a/crypto/sha/asm/sha1-x86_64.pl
+++ b/crypto/sha/asm/sha1-x86_64.pl
@@ -380,9 +380,9 @@ $code.=<<___;
 .align 16
 .Loop_shaext:
dec $num
-   lea 0x40($inp),%rax # next input block
+   lea 0x40($inp),%r8  # next input block
paddd   @MSG[0],$E
-   cmovne  %rax,$inp
+   cmovne  %r8,$inp
movdqa  $ABCD,$ABCD_SAVE# offload $ABCD
 ___
 for($i=0;$i<20-4;$i+=2) {
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Andy Polyakov via RT]

> Does current master work? I think Andy checked in a fix.

Rich was few minutes ahead. Now it's committed. Provided test case was
verified to work. Thanks for report.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4046] Fix xmm6 register clobbering in crypto/bn/asm/x86_64-mont5.pl:bn_power5() under Win64

[Andy Polyakov via RT]

Hi,

> i had some problems on Win64 using BIO_do_handshake/BIO_should_retry in a 
> loop. The compiler optimizer placed a local variable value in the xmm6 
> register.
> The content of this register was destroyed after calling BIO_do_handshake. I 
> debugged this and found that the xmm6/xmm7 registers were not restored.
> I fixed this with following diff for openssl-1.0.2d / x86_64-mont5.pl 
> (bn_power5 and bn_from_mont8x):
> 
> 1013a1014,1020
>> ___
>> $code.=<<___ if ($win64);
>> movaps   -88(%rsi),%xmm6
>> movaps   -72(%rsi),%xmm7
>> ___
>> $code.=<<___;
>>
> 2005a2013,2019
>> ___
>> $code.=<<___ if ($win64);
>> movaps   -88(%rsi),%xmm6
>> movaps   -72(%rsi),%xmm7
>> ___
>> $code.=<<___;
>>
> 
> The fix in bn_from_mont8x was not necessary for me but i think the lines are 
> also missing there.

This resolved itself it the course of fixing other problems. Thanks for
report!



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4046
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4569] Enhancement request: Macros for x86 capability bits

[Andy Polyakov via RT]

> For x86, define macros for capability bits (like for arm and pcc), according 
> to https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html:

As discussed in RT#4568 and RT#4570, these are internal interfaces and
there is no intention to expose it to user, except through setting
environment variable. Even that is recommended for specific test and
debugging scenarios rather than for production use. And since macros are
of no help when setting environment variable, suggestion is declined.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4569
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

>>> (gdb) r test/evptests.txt
>>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library 
>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>>
>>> Program received signal SIGBUS, Bus error.
>>> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
>>> inp=inp@entry=0x33649
>>> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>>> out=,
>>> out@entry=0x335d8
>>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>>> len=len@entry=0x20) at crypto/modes/ccm128.c:253
>>> 253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>>> (gdb)
>>
>> This line is within #if defined(STRICT_ALIGNMENT), which means that
>> compiler is responsible for aligning data, and SIGBUS means that it
>> failed. And indeed, looking at disassembler output it crashes in vld1.64
>> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
>> compiler generated the instruction, but didn't care to ensure the
>> alignment. There is no other conclusion one can draw but that is indeed
>> a compiler bug. Besides, default ./config works just fine and (once
>> again) I see no compelling reason for not using it.
> 
> I think these are the lines:
> 
> #if defined(STRICT_ALIGNMENT)
> union {
> u64 u[2];
> u8 c[16];
> } temp;
> #endif
> 
> ...
> 
> #if defined(STRICT_ALIGNMENT)
> memcpy(temp.c, inp, 16);
> ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
> ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
> ...
> #endif
> 
> I *thought* accessing a union member through its inactive member is
> undefined behavior.

Really? It says "When a value is stored in a member of an object of
union type, the bytes of the object representation that do not
correspond to that member but do correspond to other members take
unspecified values." Referred members fully overlap and there are no
bytes that correspond to one and not another.

> Once 'scratch.c' and 'temp.c' were used, using
> 'temp.c' and 'temp.u' leads to the UB.

But either way union with u64 member has to be aligned, so references to
.u should not cause SIGBUS.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

On 7/30/2016 8:18 PM, Andy Polyakov via RT wrote:
>>> (gdb) bt full
>>> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #3  0x000149cc in cipher_test_run ()
>>> No symbol table info available.
>>> #4  0x0001408c in setup_test ()
>>> No symbol table info available.
>>> #5  0x00011a48 in main ()
>>> No symbol table info available.
>>
>> OK, -O1 failed to reproduce it; but -O2 reproduced it:
> 
> Well, what can I say? This is first indication that it's a compiler bug...
> 
>> (gdb) r test/evptests.txt
>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>
>> Program received signal SIGBUS, Bus error.
>> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
>> inp=inp@entry=0x33649
>> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> out=,
>> out@entry=0x335d8
>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> len=len@entry=0x20) at crypto/modes/ccm128.c:253
>> 253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>> (gdb)
> 
> This line is within #if defined(STRICT_ALIGNMENT), which means that
> compiler is responsible for aligning data, and SIGBUS means that it
> failed. And indeed, looking at disassembler output it crashes in vld1.64
> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
> compiler generated the instruction, but didn't care to ensure the
> alignment. There is no other conclusion one can draw but that is indeed
> a compiler bug.

Problematic option seems to be -mfpu=crypto-neon-fp-armv8.

> Besides, default ./config works just fine and (once
> again) I see no compelling reason for not using it.

For reference, specifying -mfpu doesn't really give you an advantage in
OpenSSL. There are no floating-point calculations on
performance-critical paths. And performance-critical cases when NEON is
used for crypto operations, it's done irregardless -mfpu flag. I mean it
will use NEON even if you don't pass -mfpu. In other words, stick to
default configuration...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

>> (gdb) bt full
>> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #3  0x000149cc in cipher_test_run ()
>> No symbol table info available.
>> #4  0x0001408c in setup_test ()
>> No symbol table info available.
>> #5  0x00011a48 in main ()
>> No symbol table info available.
> 
> OK, -O1 failed to reproduce it; but -O2 reproduced it:

Well, what can I say? This is first indication that it's a compiler bug...

> (gdb) r test/evptests.txt
> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> 
> Program received signal SIGBUS, Bus error.
> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
> inp=inp@entry=0x33649
> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
> out=,
> out@entry=0x335d8
> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
> len=len@entry=0x20) at crypto/modes/ccm128.c:253
> 253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
> (gdb)

This line is within #if defined(STRICT_ALIGNMENT), which means that
compiler is responsible for aligning data, and SIGBUS means that it
failed. And indeed, looking at disassembler output it crashes in vld1.64
{d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
compiler generated the instruction, but didn't care to ensure the
alignment. There is no other conclusion one can draw but that is indeed
a compiler bug. Besides, default ./config works just fine and (once
again) I see no compelling reason for not using it.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4630] Fatal error U1077: 'ias' : return code '0x1' on Skylake processor

[Andy Polyakov via RT]

Hi,

> I'm trying to set up OpenSSL on Windows 10 64-bit (i7 Skylake), having
> followed the instructions so far, after installing Visual Studio I
> attempted to nmake in the openssl directory using Visual c++ 2008 command
> prompt to get the following error:
> 
>  "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
>  "-omakefile" "crypto\include\internal\bn_conf.h.in" >
> crypto\include\internal\bn_conf.h
> "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\
> dofile.pl"  "-omakefile" "crypto\include\internal\dso_conf.h.in" >
> crypto\include\internal\dso_conf.h
> "C:\Strawberry\perl\bin\perl.exe" "-I." -Mconfigdata "util\
> dofile.pl"  "-omakefile" "include\openssl\opensslconf.h.in" >
> include\openssl\opensslconf.h
> ias -d debug -ocrypto\aes\aes-ia64.obj "crypto\aes\aes-ia64.asm"
> 'ias' is not recognized as an internal or external command,
> operable program or batch file.
> NMAKE : fatal error U1077: 'ias' : return code '0x1'
> Stop.

You've chosen wrong platform target at ./Configure command. You've
passed VC-WIN64I, when you should have passed VC-WIN64A. For reference,
originally "I" stood for "Intel" and "A" stood for "AMD". Now we pretend
that "I" stands for "Itanium" and "A" still stands for whatever your
imagination takes you...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4630
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8).

??? If you're referring to polynomial multiplication, then it's p8, not
u8. But even if you are implying that it implements p64, then I'd ask
where does this information come from? And how would it align with
Cortex-A53 reference manual which says that AES extension and PMULL
availability is denoted by one and same flag? I mean according to
reference there shouldn't be PMULL-capable processor, which is not also
AES-capable...

> The gadget also runs Raspian, which is a 32-bit OS
> with hard floats.
> 
> $ make test V=1
> 
> ok 1 - running enginetest
> ../util/shlib_wrap.sh ./enginetest => 0
> ok
> ../test/recipes/30-test_evp.t ..
> 1..1
> not ok 1 - running evp_test evptests.txt
> ../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
> 
> #   Failed test 'running evp_test evptests.txt'
> #   at ../test/recipes/30-test_evp.t line 18.
> # Looks like you failed 1 test of 1.

Could you execute it manually and tell with line in evptests.txt it fails?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4632] AutoReply: Configure does not honor ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

> Attached is a patch that adds two Configure targets: linux-aarch32 and
> linux-aarch32hf. It might make a good starting point for Aarch32
> support.
> 
> The patch enables CRC and Crypto extensions by default.

Code that utilizes crypto extensions is compiled with -march=armv7-a by
default. Or maybe "assembled" is more accurate term.

> It allows the
> library and users with custom engines to use the instructions to
> offload to hardware.

If some custom engine requires such command line option, it can be used
when compiling the engine. OpenSSL doesn't have to be.

> Users will have to add their preference for -mtune.

See commentary in linux-armv4 section just few lines above. In your case
default configuration with ./config produces perfectly adequate output,
also modulo -mtune argument. Suggested modifications hardly add any value...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4632
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4632] Configure does not honor ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8). The gadget also runs Raspian, which is a 32-bit OS
> with hard floats.
> 
> After Configure completes, the library's -march=armv7 takes precedence
> over the user's -march=armv8-a{+crc}.
> 
> $ ./config -march=armv8-a+crc -mtune=cortex-a53
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard

-mtune -mfloat-abi are more than sufficient in this case. Well, I
wouldn't be surprised if -mfloat-abi is actually redundant, because it
might be the default... And -march suggested by ./config is fine in this
case. For reference, it would be fine even if processor in question had
crypto extensions, because ARMv8 code is compiled even with -march=armv7-a.

> **
> 
> $ ./Configure linux-arm64ilp32 -march=armv8-a+crc -mtune=cortex-a53
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard

linux-arm64ilp32 won't do. linux-arm64ilp32 is equivalent of x32 in
x86_64 world. It takes 64-bit[!] kernel and dedicated run-time that
adheres to 64-bit calling convention. Judging from ./config output you
have 32-bit[!] kernel.

For reference, note that you can run even linux-armv4 binaries under
64-bit kernel, and it's not same as ilp32. Just like on x86_64 you can
run x86_64, x32 and x86 binaries, you can run "aarch64", "arm64ilp32"
and 32-bit (hf or not) binaries under aarch64 kernel. Well, provided
that you have corresponding libcs or linked statically...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4632
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold

[Andy Polyakov via RT]

>> I don't know what you expect us to do.  We don't use the LD variable.
> 
> Right. I'm just pointing out gaps.
> 
> It only gets worse for users. What happens when someone tries a
> cross-compile by setting CC, AR, RANLIB, LD and a CFLAGS with
> --sysroot? As far as I know, there is no RTFM for cross-compiles.

Can there be one? Do we know that *all* cross-compile environments are
so similar that one can actually formulate universal TFM? Well, I'm not
saying that it's impossible to be more "eloquent" than to mention
--cross-compile-prefix and CROSS_COMPILE variable in ./INSTALL and
discuss them more specifically in Configurations/10-main.cf for Android
and iOS, I only question how "F" a "TFM" can really get. You say "it
only gets worse for users." Well, what users? For example today Debian
users can have it really simple by installing prepackaged cross
compilers along with cross-dev packages and just specify
--cross-compile-prefix alone, no need to bother with --sysroot or
anything. Moreover, if you are creative enough you can even note that if
you install qemu-user, arrange binfmt and set some variables (or create
some symbolic links) you'll be able to execute resulting alien Linux
binaries as if they were native directly from your shell prompt...
Bottom line is that there are so many variables that apparent gaps are
kind of inevitable...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

 A quick question about this configuration... Should Linux-x32 enable
 ec_nistp_64_gcc_128 by default? Does anything prohibit
 ec_nistp_64_gcc_128 in this configuration?

 # ./Configure linux-x32
 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
 no-asan [default]  OPENSSL_NO_ASAN (skip dir)
 ...
 no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip 
 dir)
 ...

 I believe it meets the three criteria for ec_nistp_64_gcc_128.
>>>
>>   * Little endian CPU
>>   * CPU allows unaligned data access
>>   * Compiler supports  __uint128_t
> 
> Correct. But there still might be nuances. ...
> ... there *might* as well be some so-far-unverbalized assumption,
> for example sizeof(long) being 8. Note "might", as I'm not actually
> saying that there is. All I'm saying is that I don't know [at this point].

It should work with linux-x32 and apparently does based on your report
in RT#4584.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

> ... What one can discuss is to have
> ./config (not ./Configure) detect x32 environment and pass alternative
> config line to ./Configure. That's how it worked so far and I see no
> reason to change it by moving platform detection logic to ./Configure.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

diff --git a/config b/config
index 2e02ae3..1fef03e 100755
--- a/config
+++ b/config
@@ -640,7 +640,12 @@ case "$GUESSOS" in
 	#fi
 	OUT="linux64-s390x"
 	;;
-  x86_64-*-linux?) OUT="linux-x86_64" ;;
+  x86_64-*-linux?)
+	if $CC -dM -E -x c /dev/null 2>&1 | grep -q ILP32 > /dev/null; then
+	OUT="linux-x32"
+	else
+	OUT="linux-x86_64"
+	fi ;;
   *86-*-linux2) OUT="linux-elf"
 	if [ "$GCCVER" -gt 28 ]; then
   if grep '^model.*Pentium' /proc/cpuinfo >/dev/null ; then
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

>>> # ./config -mx32
>>> Operating system: x86_64-whatever-linux2
>>> Configuring for linux-x86_64
>>>
>>> Perhaps the second case should fail at configure just like the first
>>> case. Upon failure, it would be nice to tell the user what to do:
>>> "Please configure with ./Configure linux-x32"
>>
>> Well, there is a trade-off. Special cases are too numerous to cover them
>> all, so question would be if this would be common and grave enough to
>> guard against. For example you can actually run ./Configure
>> tru64-alpha-cc on your Linux computer. Running make would fail
>> miserably, but would it give you right to say "you're not allowed to
>> break the compile"?
> 
> Kinda agree. I image there could be many cases like you describe.

One word in the context, cross-compile.

> In this case, there's not "too many" or "too numerous". There's only
> one item of interest: -mx32.

And it might be one too many :-)

> When Configure ignores it,

But it doesn't, it does pass it down as additional flag to compiler...

> it results in a failed compile.

Well, Configure is deliberately liberal to allow all kinds of local
adaptations. Yes, you can screw things up [easily], but you've got to
appreciate the flexibility it provides. Suggestion seems to be to
classify flags as generic adaptations and ones that might affect choice
of platform. I'd say "no" to that. What one can discuss is to have
./config (not ./Configure) detect x32 environment and pass alternative
config line to ./Configure. That's how it worked so far and I see no
reason to change it by moving platform detection logic to ./Configure.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

> Fair enough, agreed.
> 
> But Configure ignored my instructions:
> 
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32)

Well, I don't think that you can complain about this one. Basically you
can't assume that ./config will [gracefully] handle whatever you might
think of. You probably meant to run 'CFLAGS=-mx32 ./config' and computer
didn't get what you wanted. But they never do, don't they? Computers
getting what you meant to do that is...

> And:
> 
> # ./config -mx32
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> 
> Perhaps the second case should fail at configure just like the first
> case. Upon failure, it would be nice to tell the user what to do:
> "Please configure with ./Configure linux-x32"

Well, there is a trade-off. Special cases are too numerous to cover them
all, so question would be if this would be common and grave enough to
guard against. For example you can actually run ./Configure
tru64-alpha-cc on your Linux computer. Running make would fail
miserably, but would it give you right to say "you're not allowed to
break the compile"?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

>>> A quick question about this configuration... Should Linux-x32 enable
>>> ec_nistp_64_gcc_128 by default? Does anything prohibit
>>> ec_nistp_64_gcc_128 in this configuration?
>>>
>>> # ./Configure linux-x32
>>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>>> no-asan [default]  OPENSSL_NO_ASAN (skip dir)
>>> ...
>>> no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip 
>>> dir)
>>> ...
>>>
>>> I believe it meets the three criteria for ec_nistp_64_gcc_128.
>>
>> What are "the three criteria"? I mean I'm not really sure. Nor am I sure
>> that they are perfect. I mean maybe they need some adjustment in x32
>> context. To either allow or prevent erroneous compilation. Bottom line
>> is that I don't actually know at this point...
> 
> My bad... According to my notes, one can use ec_nistp_64_gcc_128 when
> these three conditions are met:
> 
>   * Little endian CPU
>   * CPU allows unaligned data access
>   * Compiler supports  __uint128_t

Correct. But there still might be nuances. For example first two
criteria were not actually formulated originally. Upon code submission
only __uint128_t requirement was explicitly formulated along with
statement that code was developed on x86_64 and therefore tested only on
x86_64. The first two criteria were kind of epiphany as result of
looking at a compiler warning and realizing that the piece of code in
question can possibly work only on little-endian system that tolerates
unaligned access. I.e. code was written under this assumption, but it
was not explicitly verbalized or maybe even recognized, presumably
because it appeared too obvious to original developer. Same in this
case, i.e. there *might* as well be some so-far-unverbalized assumption,
for example sizeof(long) being 8. Note "might", as I'm not actually
saying that there is. All I'm saying is that I don't know [at this point].


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

> A quick question about this configuration... Should Linux-x32 enable
> ec_nistp_64_gcc_128 by default? Does anything prohibit
> ec_nistp_64_gcc_128 in this configuration?
> 
> # ./Configure linux-x32
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> no-asan [default]  OPENSSL_NO_ASAN (skip dir)
> ...
> no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip 
> dir)
> ...
> 
> I believe it meets the three criteria for ec_nistp_64_gcc_128.

What are "the three criteria"? I mean I'm not really sure. Nor am I sure
that they are perfect. I mean maybe they need some adjustment in x32
context. To either allow or prevent erroneous compilation. Bottom line
is that I don't actually know at this point...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

> you're not allowed to break the compile, regardless of whether there's
> a proper "X32" kernel.

I don't understand what do you mean by "break the compile". I'd say it's
the kind of thing that lies on both parties. We are responsible for
providing code and config lines, but you have responsibilities too, you
are responsible for providing sane compiler environment. For example if
there is a system header file missing on target system [or another
standard header file attempts to include non-existing system header
file], there is nothing we can do. There either is a package missing,
not installed, or vendor screwed up packaging...

As suggested, start by ./Configure linux-x32...




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

>> Here's a couple more ways things don't work as expected:
>>
>> # ./config CFLAGS="-mx32"
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32)
>>
>> # ./config -mx32
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> ...
> 
> There is linux-x32 config line, use that instead.

It naturally means that using linux-x86_64 config with -mx32 option is
not supported. Or in other words if there are problems with that,
questions won't be answered. I.e. *do* use linux-x32 for x32 build.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

[Andy Polyakov via RT]

> Here's a couple more ways things don't work as expected:
> 
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32)
> 
> # ./config -mx32
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> ...

There is linux-x32 config line, use that instead. The only question is
*if* x32 should be auto-detected and in such case how. You mentioned
that uname returns x86_64. Of course it does, there is no x32 kernel,
x32 is pure user-land thing. Well, "pure" is overstatement because it
does require certain kernel support, but it's an add-on support for
plain 64-bit kernel. Most 64-bit Linux installations can execute x32
binaries (statically linked if there are no corresponding dynamic
libraries) and x32 installations can execute 64-bit binaries (statically
linked if there are no corresponding dynamic libraries).



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test

[Andy Polyakov via RT]

>>> ../test/recipes/30-test_evp.t ..
>>> 1..1
>>> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH
>>> Expected: 
>>> 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1
>>> Got:  
>>> 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8FB1F82828C56DDBB8261932DB4DA50A020EE8
>>> 499 tests completed with 1 errors, 0 skipped
>>
>> Please double-check attached patches. Only first one is required to fix
>> the problem, second is kind of clean-up thing...
> 
> I applied both patches at once (i.e., did not test separately).
> 
> test_evp tested OK:
> 
> ../test/recipes/30-test_engine.t ... ok
> ../test/recipes/30-test_evp.t .. ok
> ../test/recipes/30-test_evp_extra.t  ok

Thank you. Case is being closed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4578
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test

[Andy Polyakov via RT]

> The following is from a CubieBoard. I verified I performed a 'make
> clean' and 'git pull'.
> 
> $ git rev-parse HEAD
> 13c03c8d6da334bb1cde6ce4133e7c75b3b76947
> 
> **
> 
> using V=1:
> 
> ../test/recipes/30-test_evp.t ..
> 1..1
> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH
> Expected: 
> 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1
> Got:  
> 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8FB1F82828C56DDBB8261932DB4DA50A020EE8
> 499 tests completed with 1 errors, 0 skipped

Please double-check attached patches. Only first one is required to fix
the problem, second is kind of clean-up thing...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4578
Please log in as guest with password guest if prompted

>From 3cac6b6d06c4c0c4d0d5b902ca977ecaf1da7dc7 Mon Sep 17 00:00:00 2001
From: Andy Polyakov 
Date: Sat, 18 Jun 2016 15:37:25 +0200
Subject: [PATCH 1/2] aes/asm/bsaes-armv7.pl: fix XTS decrypt test failure.

RT#4578
---
 crypto/aes/asm/bsaes-armv7.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/aes/asm/bsaes-armv7.pl b/crypto/aes/asm/bsaes-armv7.pl
index 4ccdc82..9b9ba33 100644
--- a/crypto/aes/asm/bsaes-armv7.pl
+++ b/crypto/aes/asm/bsaes-armv7.pl
@@ -2405,9 +2405,9 @@ $code.=<<___;
 	veor		@XMM[0], @XMM[8]
 	mov		r1, sp
 	vst1.8		{@XMM[0]}, [sp,:128]
+	mov		r5, $magic			@ preserve magic
 	mov		r2, $key
 	mov		r4, $fp@ preserve fp
-	mov		r5, $magic			@ preserve magic
 
 	bl		AES_decrypt
 
-- 
2.7.4

>From 82d0865cf4fc7cdab80f9de0bfc6bd3035c216b5 Mon Sep 17 00:00:00 2001
From: Andy Polyakov 
Date: Sat, 18 Jun 2016 15:49:57 +0200
Subject: [PATCH 2/2] aes/asm/bsaes-armv7.pl: omit redundant stores in XTS
 subroutines.

---
 crypto/aes/asm/bsaes-armv7.pl | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/crypto/aes/asm/bsaes-armv7.pl b/crypto/aes/asm/bsaes-armv7.pl
index 9b9ba33..12091ef 100644
--- a/crypto/aes/asm/bsaes-armv7.pl
+++ b/crypto/aes/asm/bsaes-armv7.pl
@@ -1839,8 +1839,6 @@ $code.=<<___;
 	b		.Lxts_enc_done
 .align	4
 .Lxts_enc_6:
-	vst1.64		{@XMM[14]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[4], @XMM[4], @XMM[12]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -1876,8 +1874,6 @@ $code.=<<___;
 
 .align	5
 .Lxts_enc_5:
-	vst1.64		{@XMM[13]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[3], @XMM[3], @XMM[11]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -1906,8 +1902,6 @@ $code.=<<___;
 	b		.Lxts_enc_done
 .align	4
 .Lxts_enc_4:
-	vst1.64		{@XMM[12]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[2], @XMM[2], @XMM[10]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -1933,8 +1927,6 @@ $code.=<<___;
 	b		.Lxts_enc_done
 .align	4
 .Lxts_enc_3:
-	vst1.64		{@XMM[11]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[1], @XMM[1], @XMM[9]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -1959,8 +1951,6 @@ $code.=<<___;
 	b		.Lxts_enc_done
 .align	4
 .Lxts_enc_2:
-	vst1.64		{@XMM[10]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[0], @XMM[0], @XMM[8]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -1983,7 +1973,7 @@ $code.=<<___;
 .align	4
 .Lxts_enc_1:
 	mov		r0, sp
-	veor		@XMM[0], @XMM[8]
+	veor		@XMM[0], @XMM[0], @XMM[8]
 	mov		r1, sp
 	vst1.8		{@XMM[0]}, [sp,:128]
 	mov		r2, $key
@@ -2295,8 +2285,6 @@ $code.=<<___;
 	b		.Lxts_dec_done
 .align	4
 .Lxts_dec_5:
-	vst1.64		{@XMM[13]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[3], @XMM[3], @XMM[11]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -2325,8 +2313,6 @@ $code.=<<___;
 	b		.Lxts_dec_done
 .align	4
 .Lxts_dec_4:
-	vst1.64		{@XMM[12]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[2], @XMM[2], @XMM[10]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -2352,8 +2338,6 @@ $code.=<<___;
 	b		.Lxts_dec_done
 .align	4
 .Lxts_dec_3:
-	vst1.64		{@XMM[11]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[1], @XMM[1], @XMM[9]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -2378,8 +2362,6 @@ $code.=<<___;
 	b		.Lxts_dec_done
 .align	4
 .Lxts_dec_2:
-	vst1.64		{@XMM[10]}, [r0,:128]		@ next round tweak
-
 	veor		@XMM[0], @XMM[0], @XMM[8]
 #ifndef	BSAES_ASM_EXTENDED_KEY
 	add		r4, sp, #0x90			@ pass key schedule
@@ -2402,7 +2384,7 @@ $code.=<<___;

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Andy Polyakov via RT]

> 1) Openssl works correctly (no crash, correct detection), as far as I
> can judge. By error-prone I mean, very defensively, that I (or
> others) could make a mistake, or that future versions of openssl
> could not work exactly the same way.

Well, this is effectively argument in favour of denying the control over
capability vector[s]. I mean following this logic you should have no way
to affect the outcome, not programmatically nor through environment
variable. Because user can screw it up :-)

> 2) I would agree with your argumentation. But some customers want
> this anti-feature (no aes-ni), arguing that exactly those instruction
> are not trustworthy. And the customer is always right.

And following this logic no instruction is trustworthy, be it aesenc or
any other, say pshufb used in bsaes, or even better example
multiplication used in e.g. RSA. There is exactly as much proof of
correctness of either. If you are concerned about using any specific
instruction you should have bigger concern about using that processor at
all. Or in other words if trusting a processor manufacturer is
problematic, then you should manufacture own processor, with or without
AES-NI, which OpenSSL will dutifully detect and abstain from calling
procedures that would crash...

I'd argue that even this ticket can be closed with "use no-asm" resolution.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

[Andy Polyakov via RT]

> Thanks for the explanations.
> 
> In the code I am working with, I see:
> $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c
> unsigned long *OPENSSL_ia32cap_loc(void)
> 
> You may want to verify it.

Right! Sorry about confusion, my bad! It was long in 1.0.x and in became
int in master. Anyway, point that it can't be changed in last-digit
release remains, as well as reason for zeroing of most significant
word[s] upon reference to OPENSSL_ia32cap_loc in 1.0.x. Yes, it's a bug
in 1.0.2 OPENSSL_ia32cap.pod.

> I happen to be using features introduced for testing and debugging,
> without knowing it. For debatable reasons, but it is my assignment to
> avoid aes-ni instructions. Maybe I will have to adapt openssl
> slightly, for instance making the capability vectors global (instead
> of hidden); or not to use the EVP interfaces.

I suppose reply in RT#4570 applies even here.

And just to clarify, "meant to be used for overly specific testing and
debugging [hence doesn't have to be pretty]" naturally applies to all
platforms with run-time switches.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

[Andy Polyakov via RT]

> Two more observations.
> 
> OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not 
> fitting into the expected integer size being zeroed. I do not know if it is 
> practically relevant, but it is strange that a read has side effects. It 
> would be a good reason for dedicated, architecture independent setters and 
> getters.
> 
> The documentation 
> (https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap.html)
>  says:
> unsigned int *OPENSSL_ia32cap_loc(void)
> it should say:
> unsigned long *OPENSSL_ia32cap_loc(void)
> like in openssl-1.0.2h/crypto/crypto.h

No. It was 'int' upon initial release of 1.0.0 and has to remain same
throughout all 1.0.x releases. Mentioned zeroing also has everything to
do with it, i.e. with maintaining backward compatible behaviour within
line of binary compatible releases. Rationale is that application should
be given same control throughout *all* 1.0.x releases. Or in other words
*if* application chooses to manipulate capability vector it will have
same granularity as in 1.0.0.

Note that in master branch words beyond 1st are not zeroed, don't have
to. One can argue that it could be re-declared as long in master. Well,
that declaration is shared between 32- and 64-bit builds, and having
long would introduce ambiguity. Yes, one can argue that it's already
ambiguous since OPENSSL_ia32cap.pod effectively describes 64-bit values.
One has to recognize that original reason for exposing
OPENSS_ia32cap_loc() was that binary *could* end up in situation when
processor capability vector doesn't match OS capability. More
specifically cpuid could say "this is SSE2-capable processor" but
attempt to perform SSE2 operation on %xmm register could trigger invalid
instruction exception nevertheless. Note that this can't happen with
later register extensions like %ymm and %zmm, because one can detect
even OS support. But back to OPENSSL_ia32cap_loc in master context.
Actually one can as well proclaim that such old systems are no longer
supported and omit OPENSSL_ia32cap_loc altogether. Naturally leaving
setting environment variable alone as the only way to affect result of
capability detection. This is really meant to be used for overly
specific testing and debugging. And for this reason it doesn't really
have to be pretty...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Andy Polyakov via RT]

> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is
> hidden, I still have to try over environment variables, which are not
> as flexible for arm as for x86).
> 
> 
> Anyway, it would be helpful to exclude hardware aes instructions at
> compile-time:
> 
> 1) Runtime checking is error prone (openssl and code using openssl
> evolve)

How is it error-prone? Or more specifically have you ever ran into
situation when it was *detected* incorrectly so that it resulted in
application *crash*?

> 2) Proving to a customer (or convincing myself) that no such
> instructions will ever be used is much easier if such instructions
> are not even compiled

Then why just aes instructions? There is a number of code-paths that are
selected at run-time that are dependent on processor capability
detection. If aes instructions are considered "too fancy", there is no
reason to consider *any* alternative code path as less "fancy".

> I guess that some of the already existing no-xxx configuration
> options have been introduced for similar reasons.

no-asm.

I'd argue that this ticket can be closed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #3699] openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2

[Andy Polyakov via RT]

> It will be in 1.0.2 shortly.

Applied to 1.0.2.

> It's not relevant for 1.1 which doesn't support FIPS.

Because current 2.x version of FIPS module won't be supported with 1.1,
so that solution in 1.1 would have to be different.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3699
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3100] [patch] remove some useless code in BN_uadd

[Andy Polyakov via RT]

bn_add.c was modernized in
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7d6284057b66458f6c99bd65ba67377d63411090
and suggested modifications were "accumulated". Case is being dismissed.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3100
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr

[Andy Polyakov via RT]

> Looking over your logs, you appear to be configuring with no-asm,

"no-asm" is the culprit here, but problem is not reporter's but mine.
mem_clr.c was updated, but build was not tested with no-asm. Fix is
upcoming.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4548] s390x build problem

[Andy Polyakov via RT]

>> In other words
>> could you double-check attached patch instead?
> 
> Thanks. Just tested and it compiles and the testsuite passes.

Committed. Thanks. Case is being dismissed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4512] ChaCha20_ctr32 function increments 64 bit counter?

[Andy Polyakov via RT]

Hi,

> I'm aware it doesn't affect anything because the caller shouldn't process
> more than 2^32 * 64 bytes per key/nonce setup anyway.
> 
> I was just wondering because it differs from the s390 asm implementation
> (and whether there is a particular reason to do so).

Implementation is harmonized with subroutine name now, case is being
dismissed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4512
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4548] s390x build problem

[Andy Polyakov via RT]

>>> I'm getting:
>>> crypto/chacha/chacha-s390x.S: Assembler messages:
>>> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
>>>
>>>
>>> A full build log is available on:
>>> https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754
>>
>> It's overly easy to get carried away if you have access to single
>> system. Double-check attached.
> 
> I made this while I did not notice this earlier:
>   https://github.com/openssl/openssl/pull/1146
> 
> It fixes the chacha thing + memcpy.

Thanks!!! There is couple of problems with suggested modifications
though. First general comment. While 31-bit is arguably not very
fashionable, bugs are still reported at occasions. Important to keep in
mind that 31-bit build still requires z/Arch processor *and* highgprs
kernel feature, i.e. target is not s390 systems (note lack of x), but
64-bit processor running 64-bit OS, just running legacy *process*. Goal
also is to minimize deviations and "parametrize", so that most of the
code is constantly "exposed" to assembler. That's what are those ${g}
things are and that's why #if clauses are limited to clearing most
significant 32 bits of registers. This means that suggestion to
introduce big #if in CRYPTO_memcmp is not considered favourable.
Adhering to non-extension instructions is. Another problem is with
suggested ltgr in chacha-s390x. It has to be "parametrized", i.e. look
as lt${g}r. Because in 31-bit build there is no guarantee that most
significant 32-bit of $len register are actually zero-ed. In other words
could you double-check attached patch instead?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548
Please log in as guest with password guest if prompted

commit d11ca41a907ce6465e688cbfe548e21c0db94311
Author: Andy Polyakov 
Date:   Mon May 30 22:16:31 2016 +0200

s390x assembly pack: improve portability.

Some of the instructions used in latest additions are extension
ones. There is no real reason to limit ourselves to specific
processors, so [re-]adhere to base ISA set.

diff --git a/crypto/chacha/asm/chacha-s390x.pl b/crypto/chacha/asm/chacha-s390x.pl
index c7a2692..c315264 100755
--- a/crypto/chacha/asm/chacha-s390x.pl
+++ b/crypto/chacha/asm/chacha-s390x.pl
@@ -147,7 +147,8 @@ $code.=<<___;
 .type	ChaCha20_ctr32,\@function
 .align	32
 ChaCha20_ctr32:
-	cl${g}ije	$len,0,.Lno_data	# $len==0?
+	lt${g}r	$len,$len			# $len==0?
+	bzr	%r14
 	a${g}hi	$len,-64
 	l${g}hi	%r1,-$frame
 	stm${g}	%r6,%r15,`6*$SIZE_T`($sp)
@@ -279,7 +280,6 @@ $code.=<<___;
 	stmg	%r0,%r3,$stdframe+4*12($sp)
 
 	lm${g}	%r6,%r15,`$frame+6*$SIZE_T`($sp)
-.Lno_data:
 	br	%r14
 
 .align	16
diff --git a/crypto/s390xcpuid.S b/crypto/s390xcpuid.S
index df7b35a..a292d10 100644
--- a/crypto/s390xcpuid.S
+++ b/crypto/s390xcpuid.S
@@ -137,9 +137,9 @@ CRYPTO_memcmp:
 	je	.Lno_data
 
 .Loop_cmp:
-	llc	%r0,0(%r2)
+	llgc	%r0,0(%r2)
 	la	%r2,1(%r2)
-	llc	%r1,0(%r3)
+	llgc	%r1,0(%r3)
 	la	%r3,1(%r3)
 	xr	%r1,%r0
 	or	%r5,%r1
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols

[Andy Polyakov via RT]

> I'm seeing this on powerpc:
> ../test/recipes/01-test_ordinals.t . ok
> 
> #   Failed test 'check that there are no missing symbols in libcrypto.so'
> #   at ../test/recipes/01-test_symbol_presence.t line 112.
> # Looks like you failed 1 test of 4.
> ../test/recipes/01-test_symbol_presence.t .. 
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/4 subtests 
> 
> I a full log is at:
> https://buildd.debian.org/status/fetch.php?pkg=openssl=powerpc=1.1.0~pre5-1=1464595346
> 
> If I find time I'll try to look in the the real cause.

For what it's worth I can't reproduce problem on Fedora or RedHat.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4549
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

[Andy Polyakov via RT]

> I'm getting assembler errors on hppa that look like:
> crypto/aes/aes-parisc.s: Assembler messages:
> crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> 
> I'm guessing I'm doing something wrong, but hppa never had
> assembler enabled in Debian before.
> 
> The configuration I use is:
> my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get 
> CPPFLAGS` . "-Wa,--noexecstack -Wall";
> $debian_cflags =~ s/\n/ /g;
> my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> $debian_ldflags =~ s/\n/ /g;
> 
> 
> %targets = (
>"debian" => {
>cflags => $debian_cflags,
>lflags => add($debian_ldflags, "-pthread"),
>},
> [...]
>"debian-hppa" => {
>inherit_from => [ "linux-generic32", "debian", 
> asm("parisc11_asm") ],
>},
> 
> Is that assembler supposed to work?  Is it the right assembler that
> I'm using?

PA-RISC assembly modules were tested *only* on HP-UX. While it works
with GNU assembler, it's still one for HP-UX. Special thing about it is
that run-time format is not ELF, and supposedly that's what those
failing directives are about. I mean they are meant to make sense to
specifically HP-UX assemblers. I suppose it means that Linux support
would require extra work, adapting all modules to recognize additional
"perlasm flavour". It's not unlike that it's not about simple
decorations, ABI-specific adjustments might be required too... I don't
think I've actually seen PA-RISC ELF calling convention...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4550
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4548] s390x build problem

[Andy Polyakov via RT]

> I'm getting:
> crypto/chacha/chacha-s390x.S: Assembler messages:
> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
> 
> 
> A full build log is available on:
> https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754

It's overly easy to get carried away if you have access to single
system. Double-check attached.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548
Please log in as guest with password guest if prompted

commit fbaecaa94021294f4dd3f399338d076af284f787
Author: Andy Polyakov 
Date:   Mon May 30 22:16:31 2016 +0200

chacha/asm/chacha-s390x.pl: improve portability.

cl[g]ije is an extension instruction, there is no real reason to
limit ourselves to specific processors.

diff --git a/crypto/chacha/asm/chacha-s390x.pl 
b/crypto/chacha/asm/chacha-s390x.pl
index c7a2692..867594f 100755
--- a/crypto/chacha/asm/chacha-s390x.pl
+++ b/crypto/chacha/asm/chacha-s390x.pl
@@ -147,7 +147,8 @@ $code.=<<___;
 .type  ChaCha20_ctr32,\@function
 .align 32
 ChaCha20_ctr32:
-   cl${g}ije   $len,0,.Lno_data# $len==0?
+   cl${g}fi$len,0
+   je  .Lno_data   # $len==0?
a${g}hi $len,-64
l${g}hi %r1,-$frame
stm${g} %r6,%r15,`6*$SIZE_T`($sp)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4491] [PATCH] VMX-crypto: Add XTS support

[Andy Polyakov via RT]

> Author: Leonidas Da Silva Barbosa 
> ASM implementation
> 
> Signed-off-by: Paulo Flabiano Smorigo 
> Signed-off-by: Leonidas Da Silva Barbosa 
> ---
> +my ($inp,$out,$len,$key,$tweak,$enc,$rounds,$idx)=map("r$_",(3..10));

There seem to be misunderstanding. EVP layer expects XTS "stream"
subroutine to accept clear-text initial tweak (for this both keys are
passed) and to handle lengths not divisible by 16. Suggested code does
neither. I fail to follow tweak caclucations, it seems more complicated
than necessary. I managed to do in 5 instructions:

vsrab   $tmp,$tweak,$seven
vaddubm $tweak,$tweak,$tweak
vsldoi  $tmp,$tmp,$tmp,15
vand$tmp,$tmp,$eighty7
vxor$tweak,$tweak,$tmp

Please review attached code. Even though it's almost 4x faster, it will
be improved even further shortly.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4491
Please log in as guest with password guest if prompted

diff --git a/crypto/aes/asm/aesp8-ppc.pl b/crypto/aes/asm/aesp8-ppc.pl
index a1891cc..8ea52cd 100755
--- a/crypto/aes/asm/aesp8-ppc.pl
+++ b/crypto/aes/asm/aesp8-ppc.pl
@@ -1887,6 +1887,415 @@ Lctr32_enc8x_done:
 ___
 }} }}}
 
+#
+{{{# XTS procedure[s]  #
+my ($inp,$out,$len,$key1,$key2,$ivp,$rounds,$idx) =map("r$_",(3..10));
+my ($rndkey0,$rndkey1,$inout,$tmp) =   map("v$_",(0..3));
+my ($inptail,$inpperm,$output,$leperm,$keyperm) =  map("v$_",(4..8));
+my ($tweak,$seven,$eighty7,$tweak1) =  map("v$_",(9..12));
+
+   ($inp,$idx) = ($idx,$inp);  # reassign
+
+$code.=<<___;
+.globl .${prefix}_xts_encrypt
+.align 5
+.${prefix}_xts_encrypt:
+   mr  $inp,r3 # reassign
+   li  r3,-1
+   ${UCMP}i$len,16
+   bltlr-
+
+   lis r0,0xfff0
+   mfspr   r12,256 # save vrsave
+   li  r11,0
+   mtspr   256,r0
+
+   vspltisb$seven,0x07 # 0x070707..07
+   le?lvsl $leperm,r11,r11
+   le?vspltisb $tmp,0x0f
+   le?vxor $leperm,$leperm,$seven
+
+   li  $idx,15
+   lvx $tweak,0,$ivp   # load [unaligned] iv
+   lvsl$inpperm,0,$ivp
+   lvx $inptail,$idx,$ivp
+   le?vxor $inpperm,$inpperm,$tmp
+   vperm   $tweak,$tweak,$inptail,$inpperm
+
+   ?lvsl   $keyperm,0,$key2# prepare for unaligned 
key
+   lwz $rounds,240($key2)
+   srwi$rounds,$rounds,1
+   subi$rounds,$rounds,1
+   li  $idx,16
+
+   neg r11,$inp
+   lvsr$inpperm,0,r11  # prepare for unaligned 
load
+   lvx $inout,0,$inp
+   addi$inp,$inp,15# 15 is not typo
+   le?vxor $inpperm,$inpperm,$tmp
+
+   lvx $rndkey0,0,$key2
+   lvx $rndkey1,$idx,$key2
+   addi$idx,$idx,16
+   ?vperm  $rndkey0,$rndkey0,$rndkey1,$keyperm
+   vxor$tweak,$tweak,$rndkey0
+   lvx $rndkey0,$idx,$key2
+   addi$idx,$idx,16
+   mtctr   $rounds
+
+Ltweak_xts_enc:
+   ?vperm  $rndkey1,$rndkey1,$rndkey0,$keyperm
+   vcipher $tweak,$tweak,$rndkey1
+   lvx $rndkey1,$idx,$key2
+   addi$idx,$idx,16
+   ?vperm  $rndkey0,$rndkey0,$rndkey1,$keyperm
+   vcipher $tweak,$tweak,$rndkey0
+   lvx $rndkey0,$idx,$key2
+   addi$idx,$idx,16
+   bdnzLtweak_xts_enc
+
+   ?vperm  $rndkey1,$rndkey1,$rndkey0,$keyperm
+   vcipher $tweak,$tweak,$rndkey1
+   lvx $rndkey1,$idx,$key2
+   li  $idx,16
+   ?vperm  $rndkey0,$rndkey0,$rndkey1,$keyperm
+   vcipherlast $tweak,$tweak,$rndkey0
+
+   lvx $inptail,0,$inp
+   addi$inp,$inp,16
+
+   ?lvsl   $keyperm,0,$key1# prepare for unaligned 
key
+   lwz $rounds,240($key1)
+   srwi$rounds,$rounds,1
+   subi$rounds,$rounds,1
+   li  $idx,16
+
+   vslb$eighty7,$seven,$seven  # 0x808080..80
+   vor $eighty7,$eighty7,$seven# 0x878787..87
+   vspltisb$tmp,1  # 0x010101..01
+   vsldoi  $eighty7,$eighty7,$tmp,15   # 0x870101..01
+
+   lvx $rndkey0,0,$key1
+   lvx 

Re: [openssl-dev] [openssl.org #4523] Failure - make test

[Andy Polyakov via RT]

Hi,

> I got an failure at "make test" sea end of Mail

Well, at the end of the mail it says that it failed to link. It's rather
indication of something going wrong with *your* compiler setup. We more
or less stand for correctness of code and you stand for providing sane
compiler environment it can be compiled in. In other words this is
likely to be non-OpenSSL problem. Judging from presented output it
indeed didn't attempt to build libssl, but why is that it's virtually
impossible to tell. Maybe there was a malformed leftover file left from
previous unsuccessful build attempt... Or in other words this particular
problem is likely for you to solve.

However! I want to point out that formally in this case we can't be held
responsible even for code correctness, because ...

> Target (default): linux-x86_64
> Target:   linux-generic32
> Compiler: Using built-in specs.
> Target: x86_64-suse-linux
> Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
> --mandir=/
> usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 
> --enable-languages=c,c
> ++,objc,fortran,obj-c++,java,ada --enable-checking=release 
> --with-gxx-include-di
> r=/usr/include/c++/4.3 --enable-ssp --disable-libssp 
> --with-bugurl=http://bugs.o
> pensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj 
> --disable-libmudfla
> p --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit 
> --enable-libstd
> cxx-allocator=new --disable-libstdcxx-pch 
> --enable-version-specific-runtime-libs
> --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind 
> --with-cp
> u=generic --build=x86_64-suse-linux

... your compiler appears to be 64-bit one, but you configure for
linux-generic32. For 64-bit cases there is linux-generic64 and that's
what we support. The fact that linux-generic32 actually worked is
nothing but a fun fact, as we won't accept bug reports if it didn't. One
should also keep in mind that linux-generic* targets are for targets
that don't have explicit platform support. In the context it means that
while we won't refuse to answer the questions about linux-generic64 on
x86_64, we would still keep recommending to adhere to linux-x86_64
configuration on x86_64 Linux system, because that's what is explicitly
tested.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4523
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4333] openssl-1.1.0pre3 on IRIX: make test: Unrecognized escape \R passed through

[Andy Polyakov via RT]

> make test fails on IRIX 6.5 with perl 5.8.9 when building for irix-mips3-cc 
> and irix64-mips4-cc (the only platforms I've tried so far).

Just like with RT#4332 you've got to have at least Perl 5.10. Case is
being dismissed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4333
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4332] openssl-1.1.0pre3 on IRIX: "Something wrong with" config --unified

[Andy Polyakov via RT]

> I'm trying to build openssl 1.1.0pre3 on IRIX 6.5 with the new unified
> building system using perl 5.8.9. This fails with the error message 
> below. Building without --unified works as expected. Any hints
> how to debug this or extract better logs would be appreciated.

There is minimal requirement of Perl 5.10. There is no other option, but
to update your perl. Case is being dismissed.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4332
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4463] Undefined behavior in cast/c_enc.c

[Andy Polyakov via RT]

> $ ./config -fsanitize=undefined

Sanitized builds might have to be complemented with -DPEDANTIC. Quoting
Configure:

# ... Incidentally -DPEDANTIC has
# to be used even in sanitized builds, because sanitizer too is
# supposed to and does take notice of non-standard behaviour.

Similar rule applies to cases when you try to pass harder standard
compliance flags like you discussed in other RTs. Bottom line is that
while it's possible to pass additional compiler flags to ./config, it
doesn't mean that arbitrary combination is guaranteed to work. Sanitized
builds are exercised through travis-ci.org and you can find find the
flags in .travis.yml.

> ...
> $ make test HARNESS_VERBOSE=yes
> ...
> 
> ../test/recipes/05-test_cast.t 
> 1..1
> crypto/cast/c_enc.c:78:5: runtime error: shift exponent 32 is too
> large for 32-bit type 'unsigned int'

Though this particular code was modified to pass sanitized independent
on -DPEDANTIC.

I'm closing this ticket.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4463
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4483] Wrong results with Poly1305 functions

[Andy Polyakov via RT]

>> Right. What I meant is that a fully reduced h has $h2 < 4. Is it possible
>> that $h2, after that adc, ends up at 4, exceeding that bound? If it were,
>> that would require one more reduction.
>>
>> In the non-SIMD paths, I believe this is fine because $r0's and $r1's
>> cleared high bits mean we should have plenty of slack to leave that
>> unreduced. (And indeed its normally not reduced on input from the
>> addition.) Then poly1305_emit's reduction after adding s will resolve
>> things before output. But, in the SIMD paths, __poly1305_blocks is called
>> and then bits are shifted without any reduction. Wouldn't that cause a
>> problem? Or is this situation impossible?
>>
> 
> Pondering this some more, I missed that the base 2^26 representation still
> has six bits extra, so we shouldn't immediately lose that bit. How tolerant
> is the SIMD code to a partially-reduced h? (I haven't puzzled out how it
> works yet.) Is this within its bounds?

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=dc3c5067cd90f3f2159e5d53c57b92730c687d7e
provides background information (and ensures paper-n-pencil boundary
condition on ARM and x86). Ticket is being closed.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4508] BUG in openssl-1.1.0-pre4 (and current GIT master)

[Andy Polyakov via RT]

> Openssl-1.1.0-pre4 can't be built for linux-ppc with options no-chacha or 
> no-poly1305 since crypto/ppccap.c doesn't use OPENSSL_NO_CHACHA and 
> OPENSSL_NO_POLY1305.

This was fixed. Closing ticket.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4508
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4509] ECC key generation under valgrind reports: impossible has happened

[Andy Polyakov via RT]

> Valgrind does not necessarily support all instructions, if
> there’s
> any optimized assembly, you might run into problems.
> Are you able to compile a non-assembly version of the OpenSSL
> library?
> Are you able to update to a newer Valgrind?
 Or at least tell valgrind version, because I can't reproduce the
 problem
 with 3.10.1. At any event you can also see if it's problem with
 unsupported instructions, unsupported by [your version of]
 valgrind
 that
 is, by manipulating OPENSSL_ia32cap environment variable. You can
 disable AVX2 code paths by setting it to :~0x20 or simply :0 if
 it
 runs into more "too-new-to-be-possible" instructions.
>>> I tried with valgrind-3.11.0.
>> Tough break... One can actually wonder if valgrind tampers with
>> processor capability vector... And it totally does! I.e. even though
>> my
>> processor is AVX2-capable, when executed under my valgrind openssl
>> doesn't see it as AVX2-capable. I suppose your valgrind passed AVX2
>> flag, but failed to recognize all the instructions it should have...
> 
> I believe that's the case too. The same tests succeed without valgrind
> on the same CPU.

In other words it doesn't sound like OpenSSL problem. I suppose ticket
can be closed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4509
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Andy Polyakov via RT]

> There is a bug in Hercules 3.12 and below as well as Hyperion.

In other words, not OpenSSL problem, cases are being dismissed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Andy Polyakov via RT]

> Hi Paul,

It doesn't seem unlike that OP is not subscribed, so he won't see
responses send to  alone. To ensure delivery and or reply
to .

> I have not checked the code for the test, but I do get the expected
> values with my little test program.

But what is your host, Massimiliano? Is it also Hercules, and if so
which version? As Paul indicated later, it might be Hercules bug, and it
would be helpful if you can tell what's your version. One has to keep in
mind that not all version implement XTS support...

> Here's the dump (key and iv set to 0
> - block size is 32 bytes (i.e. 2 * 128bit units)):
> 
> AES XTS Encrypt:
> 
> 
> Plaintext (32):
> 0020 - 
> 
> Ciphertext 32:
>  - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92  
> .|...h..
> 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e  
> .C.e/...
> 
> AES XTS Decrypt:
> 
> 
> Encrypted Data:
>  - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92  
> .|...h..
> 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e  
> .C.e/...
> 
> Decrypt Offset: 0
> Original Start: 0
> Throw Away: 0
> 
> Clear Text 32:
> 0020 - 
> 
> My guess is that the second part of the key is not all zeros - this
> would cause you to get the first part of the message encrypted correctly
> and the second part not having the good values... this is just my guess,
> of course.
> 
> Cheers,
> Max


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4509] ECC key generation under valgrind reports: impossible has happened

[Andy Polyakov via RT]

>>> Valgrind does not necessarily support all instructions, if there’s
>>> any optimized assembly, you might run into problems.
>>> Are you able to compile a non-assembly version of the OpenSSL
>>> library?
>>> Are you able to update to a newer Valgrind?
>> Or at least tell valgrind version, because I can't reproduce the
>> problem
>> with 3.10.1. At any event you can also see if it's problem with
>> unsupported instructions, unsupported by [your version of] valgrind
>> that
>> is, by manipulating OPENSSL_ia32cap environment variable. You can
>> disable AVX2 code paths by setting it to :~0x20 or simply :0 if it
>> runs into more "too-new-to-be-possible" instructions.
> 
> I tried with valgrind-3.11.0.

Tough break... One can actually wonder if valgrind tampers with
processor capability vector... And it totally does! I.e. even though my
processor is AVX2-capable, when executed under my valgrind openssl
doesn't see it as AVX2-capable. I suppose your valgrind passed AVX2
flag, but failed to recognize all the instructions it should have...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4509
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4509] ECC key generation under valgrind reports: impossible has happened

[Andy Polyakov via RT]

> Valgrind does not necessarily support all instructions, if there’s any 
> optimized assembly, you might run into problems.
> Are you able to compile a non-assembly version of the OpenSSL library?
> Are you able to update to a newer Valgrind?

Or at least tell valgrind version, because I can't reproduce the problem
with 3.10.1. At any event you can also see if it's problem with
unsupported instructions, unsupported by [your version of] valgrind that
is, by manipulating OPENSSL_ia32cap environment variable. You can
disable AVX2 code paths by setting it to :~0x20 or simply :0 if it runs
into more "too-new-to-be-possible" instructions.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4509
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4512] ChaCha20_ctr32 function increments 64 bit counter?

[Andy Polyakov via RT]

Hi,

> The following code in the ChaCha20_ctr32 function in
> crypto/chacha/chacha_enc.c looks like you are actually using an IV=[64bit
> counter||64 bit nonce] as specified in the "original Bernstein ChaCha"
> instead of IV=[32bit counter||96bit nonce] as specified in RFC7539.

Correct. While it's indeed confusing, it doesn't affect RFC7539
compliant operation, because subroutine in question takes in full-length
128-bit counter value and is essentially is agnostic to where nonce
starts. So that caller has control over effective length of the nonce,
as well as indirectly width of the counter. Latter can be achieved by
limiting the amount of processed data. I mean if caller passes 0XYZ
counter value (every digit/letter representing 32-bit value and XYZ
being nonce) but never asks to process more than 2^38 bytes, that
counter would never overstep the boundary.

> u32 input[16];
> [...]
> /* advance counter */
> if (++input[12] == 0)
> input[13]++;

But even though it doesn't actually affect operation, it's appropriate
to remove the overflow handling at least to harmonize with subroutine
name, ChaCha20_ctr32, as well as with assembly implementations.

Thanks for report.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4512
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4520] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

[Andy Polyakov via RT]

> The change
> 
> https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed
> 
> introduced a typo in the last line of file crypto/camellia/build.info.

Fixed. Thanks for report.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4520
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4439] poly1305-x86.pl produces incorrect output

[Andy Polyakov via RT]

>>> No, it doesn't depend on call pattern. Please confirm that attached
>>> patch solves the problem. Thanks.
>>>
>>
>> (Right, sorry, I meant that the test vectors I have seem to only with
>> their corresponding call patterns.)

And I meant that I observed failure pattern other than suggested. Never
mind...

>> The patch works on my end, and naively comparing random inputs against a
>> reference implementation doesn't reveal any other issues. Thanks for fixing
>> it so quickly!
>>
> 
> Andy, there appears to be a typo in the patch. It says defined(extra)
> rather than defined($extra). It was evaluating a bare word and always using
> paddq.

Thanks, fixed.

> The $extra version seems to work too, but may I suggest adding some
> comments here?

I'll add comment (and elaborate on below questions) at later point, more
specifically after RT#4483 is resolved.

> If I'm understanding correctly, the paddd vs paddq decision is about
> whether the sum fits in 2^32 rather than needing the full 2^64, right? And
> you use paddd preferentially over paddq because paddq is slow on Atom? This
> isn't very clear from "because paddq is "broken" on Atom". It's also no
> longer next to where $paddx is computed.
> 
> Moreover, it seems lazy_reduction conditioning on $extra isn't because
> $extra is in itself significant, but because $extra being set means we are
> following the tail logic and a horizontal addition, so the bounds don't
> hold anymore? This could do with a clear comment.
> 
> Finally, where paddd is used, it's probably worth a comment for why the
> bounds hold and under what assumptions. I haven't been able to trace
> through them myself (based on the paper, it looks like the result of the h4
> -> h0 carry after the horizontal addition should be bound by 2^26 + 2^26 *
> 5 * 2 * 5 = 2^26 * 51, but looking in a debugger, it's larger, so clearly
> I'm missing something), so I can't suggest any particular text.
> 
> David
> 
> PS: By the way, this typo would have been caught by use strict. Have you
> all considered moving perlasm to be use strict clean?
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4439
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4483] Wrong results with Poly1305 functions

[Andy Polyakov via RT]

>>> In the final reduction, $h1 is all ones, so there is one more carry to
>>> propagate. Though $h2 can then overflow its two bits, I think? I expect
>>> that and the cleared bits of r mean the imulqs in poly1305_iteration are
>>> still safe, so we can pick up that slack in poly1305_emit, but I'm not
>> sure
>>> about all the complex switching back and forth in the SIMD codepaths.
>> Does
>>> __poly1305_block need to follow up with one more reduction?
>>
>> That additional adc goes to a perl subroutine that is used in both
>> poly1305_blocks and __poly1305_blocks, so modification covers both. Pure
>> SIMD paths (or FP) are not affected...
>>
> 
> Right. What I meant is that a fully reduced h has $h2 < 4. Is it possible
> that $h2, after that adc, ends up at 4, exceeding that bound?

The question is somewhat ambiguous. I mean you write < 4 and then wonder
if it can end up at 4. If you meant to write $h2 < 3, then it wouldn't
be ambiguous. Anyway...

> If it were,
> that would require one more reduction.

It can (one of suggested test vectors actually exposes it), but no
special treatment is required. If it happens anywhere in the middle it's
handled naturally. If it happens as last step, then final "comparison
with modulus" step effectively takes care of it, because after adding 5
value would still appear as "overflow", and so it will choose value with
5 added. Note that it does mean that *final* $h2 is at most 4. It can
become larger that 4 in the *middle*, but not larger than 6.

> In the non-SIMD paths, I believe this is fine because $r0's and $r1's
> cleared high bits mean we should have plenty of slack to leave that
> unreduced. (And indeed its normally not reduced on input from the
> addition.) Then poly1305_emit's reduction after adding s will resolve
> things before output. But, in the SIMD paths, __poly1305_blocks is called
> and then bits are shifted without any reduction.

What do you mean shifted without any reduction? There is reduction step
after base 2^26 -> 2^64 conversion (which also needs additional adc, but
there *is* reduction step) *prior* call to __poly1305_block. And there
naturally is reduction step at the end of __poly1305_block, so that base
2^64 -> 2^26 conversion *after* __poly1305_block is performed at reduced
value.

> Wouldn't that cause a
> problem? Or is this situation impossible?

If neither of above answers questions, then please elaborate.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4483] Re: [openssl.org #4482] Wrong results with Poly1305 functions

[Andy Polyakov via RT]

>> Attached is a sample code that will test various inputs for the
>> Poly1305 functions of openssl...
> 
> I'm seeing compiler conversion warnings about size_t to int
> truncation.

Can you be more specific?

> Do you have any vectors that cross the 2GB boundary?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4489] PATCH: fix Windows deprecated strdup in crypto\conf\conf_lib.c

[Andy Polyakov via RT]

On 03/28/16 15:16, Viktor Dukhovni via RT wrote:
> 
>> On Mar 28, 2016, at 4:38 AM, noloa...@gmail.com via RT  
>> wrote:
>>
>> On Windows, the fix below also depends upon the patch from Issue 4488
>> ("The POSIX name for this item is deprecated. Instead, use the ISO C++
>> conformant name...").
>>
>> This patch below also fixes some problems with the older standards on
>> Fedora, BSD and Linux.
>>
>> $ cat conf_lib.patch
>> diff --git a/crypto/conf/conf_lib.c b/crypto/conf/conf_lib.c
>> index f197714..7bc3ac0 100644
>> --- a/crypto/conf/conf_lib.c
>> +++ b/crypto/conf/conf_lib.c
>> @@ -392,7 +392,7 @@ void
>> OPENSSL_INIT_set_config_filename(OPENSSL_INIT_SETTINGS *settings,
>>   const char *config_file)
>> {
>> free(settings->config_name);
>> -settings->config_name = config_file == NULL ? NULL : 
>> strdup(config_file);
>> +settings->config_name = config_file == NULL ? NULL :
>> OPENSSL_strdup(config_file);
>> }
>> #endif
> 
> If you're going to change strdup -> OPENSSL_strdup, then the previous
> line needs to also change free -> OPENSSL_free.

Few lines up there is rationale for malloc/free and by association
strdup. Switching to OPENSSL_[strdup|malloc|free] goes against it. On
Windows one can/should switch to _strdup (it also solves another real
yet subtle problem, not just warning). If lack of strdup is concern
(relly? which Fedora, BSD, Linux can it be?), then one might have to
consider local few-liner implementation. And conf_sap.c suffers from
this too...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4489
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4483] Wrong results with Poly1305 functions

[Andy Polyakov via RT]

> For x86-64, this seems to be the bug:
> 
> $ git diff
> diff --git a/crypto/poly1305/asm/poly1305-x86_64.pl b/crypto/poly1305/asm/
> poly1305-x86_64.pl
> index 3c810c5..bc14ed1 100755
> --- a/crypto/poly1305/asm/poly1305-x86_64.pl
> +++ b/crypto/poly1305/asm/poly1305-x86_64.pl
> @@ -97,6 +97,7 @@ $code.=<<___;
> add $d3,%rax
> add %rax,$h0
> adc \$0,$h1
> +   adc \$0,$h2
>  ___
>  }

Correct. Testing is done on all platforms.

> In the final reduction, $h1 is all ones, so there is one more carry to
> propagate. Though $h2 can then overflow its two bits, I think? I expect
> that and the cleared bits of r mean the imulqs in poly1305_iteration are
> still safe, so we can pick up that slack in poly1305_emit, but I'm not sure
> about all the complex switching back and forth in the SIMD codepaths. Does
> __poly1305_block need to follow up with one more reduction?

That additional adc goes to a perl subroutine that is used in both
poly1305_blocks and __poly1305_blocks, so modification covers both. Pure
SIMD paths (or FP) are not affected...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4483] Re: [openssl.org #4482] Wrong results with Poly1305 functions

[Andy Polyakov via RT]

> Attached is an updated version of the test with an additional test
> vector. This one happens on 64 bit and not on 32 bit.

Got it. It will take some time to perform cross-checks. Thanks!



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4325] Unified Builds Don't Work With ARM

[Andy Polyakov via RT]

Hi,

> There are a few problems that I am facing with unified builds with arm:
> 
> 1. arm_arch.h is not in the include path.
>  fatal error: arm_arch.h: No such file or directory
> 
> 2. The arm assembler scripts output to stdout
> (see attached output.txt)

This was addressed in a bigger sweep addressing multiple platforms. Thanks.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4325
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

[Andy Polyakov via RT]

On 03/14/16 17:12, Andy Polyakov via RT wrote:
>> It looks like the ULL suffix should be safe today;
> 
> This is misleading statement. *Today* U suffix should be safe, because
> standard specifies that compiler should pick type automatically
> depending on value of the constant. In order words suffices beyond U are
> required only if you need constant to be of wider type, wider than its
> value, e.g. 13ULL. Well, even then it might be superfluous, because type
> promotion rules might do it for you. Going back to beginning, to "today
> U suffix should be safe". Thing is that we kind of live between today
> and yesterday, making it work not only with contemporary platforms, but
> even older ones. So real question is if there is compiler supporting
> 64-bit integer (which is OpenSSL minimum requirement) which would
> *truncate* constants in question, i.e. with U alone? I'm not aware of
> any. Next question is if there is compiler that would *fail* to parse
> ULL? Yes, older Microsoft 32-bit compilers would. Do you see where is it
> going? It's going toward leaving U alone.
> 
> One can wonder if warning is actually justified. I'd argue that this
> would be a trick question. Compiler in question obviously accepts long
> long, but it's an *extension* to c89 [which we require and rely on]. Now
> if compiler already accepts extensions, why would it have to complain
> about extended constant values? I mean you either process extensions and
> don't complain, or reject extension and complain. Anyway, the U is here
> to stay. If warnings sting the eye that much, then the only appropriate
> action would be to bump standard compliance by passing -std=c9x as
> additional argument to config/Configure. One can argue that it should be
> in Configuration/10-main.conf, or be automatically added by ./config.
> Yes, I suppose it's appropriate assuming that compilers shipped with
> MacOS X all recognize the option.

With rationale that MacOS X for PPC is not going to evolve options for
darwin*-ppc-cc are frozen at -std=gnu9x.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4422
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4439] poly1305-x86.pl produces incorrect output

[Andy Polyakov via RT]

Hi,

> You know the drill. See the attached poly1305_test2.c.
> 
> $ OPENSSL_ia32cap=0 ./poly1305_test2
> PASS
> $ ./poly1305_test2
> Poly1305 test failed.
> got:  2637408fe03086ea73f971e3425e2820
> expected: 2637408fe13086ea73f971e3425e2820
> 
> I believe this affects both the SSE2 and AVX2 code. It does seem to be
> dependent on this input pattern.

No, it doesn't depend on call pattern. Please confirm that attached
patch solves the problem. Thanks.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4439
Please log in as guest with password guest if prompted

diff --git a/crypto/poly1305/asm/poly1305-x86.pl 
b/crypto/poly1305/asm/poly1305-x86.pl
index 4307c99..419cb30 100755
--- a/crypto/poly1305/asm/poly1305-x86.pl
+++ b/crypto/poly1305/asm/poly1305-x86.pl
@@ -540,6 +540,7 @@ my $base = shift; $base = "esp" if (!defined($base));
 
 sub lazy_reduction {
 my $extra = shift;
+my $paddx = defined(extra) ? paddq : paddd;
 

# lazy reduction as discussed in "NEON crypto" by D.J. Bernstein
@@ -563,12 +564,12 @@ my $extra = shift;
# possible, because
# paddq is "broken"
# on Atom
-  ($D1,$MASK);
- ($T1,$D2);  # h1 -> h2
  ($T0,2);
+ ($T1,$D2);  # h1 -> h2
+&$paddx($T0,$D0);  # h4 -> h0
+  ($D1,$MASK);
 ($D2,$T1);
  ($T1,26);
- ($T0,$D0);  # h4 -> h0
   ($D2,$MASK);
  ($T1,$D3);  # h2 -> h3
 ($D0,$T0);
@@ -1708,18 +1709,18 @@ sub vlazy_reduction {
 ($T1,$D1,26);
  ($D1,$D1,$MASK);
 ($D2,$D2,$T1);  # h1 -> h2
-($D0,$D0,$T0);
+($D0,$D0,$T0);
 ($T0,$T0,2);
 ($T1,$D2,26);
  ($D2,$D2,$MASK);
-($D0,$D0,$T0);  # h4 -> h0
-($D3,$D3,$T1);  # h2 -> h3
+($D0,$D0,$T0);  # h4 -> h0
+($D3,$D3,$T1);  # h2 -> h3
 ($T1,$D3,26);
 ($T0,$D0,26);
  ($D0,$D0,$MASK);
  ($D3,$D3,$MASK);
-($D1,$D1,$T0);  # h0 -> h1
-($D4,$D4,$T1);  # h3 -> h4
+($D1,$D1,$T0);  # h0 -> h1
+($D4,$D4,$T1);  # h3 -> h4
 }
_reduction();
 
diff --git a/crypto/poly1305/poly1305.c b/crypto/poly1305/poly1305.c
index 303822e..b500f2e 100644
--- a/crypto/poly1305/poly1305.c
+++ b/crypto/poly1305/poly1305.c
@@ -699,6 +699,35 @@ static const struct poly1305_test poly1305_tests[] = {
  "746869732069732033322d6279746520""6b657920666f7220506f6c7931333035",
  "49ec78090e481ec6c26b33b91ccc0307"
 },
+{
+ "89dab80b7717c1db5db437860a3f70218e93e1b8f461fb677f16f35f6f87e2a9"
+ "1c99bc3a47ace47640cc95c345be5ecca5a3523c35cc01893af0b64a62033427"
+ "0372ec12482d1b1e363561698a578b359803495bb4e2ef1930b17a5190b580f1"
+ "41300df30adbeca28f6427a8bc1a999fd51c554a017d095d8c3e3127daf9f595",
+ "2d773be37adb1e4d683bf0075e79c4ee""037918535a7f99ccb7040fb5f5f43aea",
+ "c85d15ed44c378d6b00e23064c7bcd51"
+},
+{
+ "000b17030302"
+ "06db1f1f368d696a810a349c0c714c9a5e7850c2407d721acded95e018d7a852"
+ "66a6e1289cdb4aeb18da5ac8a2b0026d24a59ad485227f3eaedbb2e7e35e1c66"
+ "cd60f9abf716dcc9ac42682dd7dab287a7024c4eefc321cc0574e16793e37cec"
+ "03c5bda42b54c114a80b57af26416c7be742005e20855c73e21dc8e2edc9d435"
+ "cb6f6059280011c270b71570051c1c9b3052126620bc1e2730fa066c7a509d53"
+ "c60e5ae1b40aa6e39e49669228c90eecb4a50db32a50bc49e90b4f4b359a1dfd"
+ "11749cd3867fcf2fb7bb6cd4738f6a4ad6f7ca5058f7618845af9f020f6c3b96"
+ "7b8f4cd4a91e2813b507ae66f2d35c18284f7292186062e10fd5510d18775351"
+ "ef334e7634ab4743f5b68f49adcab384d3fd75f7390f4006ef2a295c8c7a076a"
+ "d54546cd25d2107fbe1436c840924aaebe5b370893cd63d1325b8616fc481088"
+ "6bc152c53221b6df373119393255ee72bcaa880174f1717f9184fa91646f17a2"
+ "4ac55d16bfddca9581a92eda479201f0edbf633600d6066d1ab36d5d2415d713"
+ "51bbcd608a25108d25641992c1f26c531cf9f90203bc4cc19f5927d834b0a471"
+ "16d3884bbb164b8ec883d1ac832e56b3918a98601a08d171881541d594db399c"
+ "6ae6151221745aec814c45b0b05b565436fd6f137aa10a0c0b643761dbd6f9a9"
+ "dcb99b1a6e690854ce0769cde39761d82fcdec15f0d92d7d8e94ade8eb83fbe0",
+ "99e5822dd4173c995e3dae0ddefb9774""3fde3b080134b39f76e9bf8d0e88d546",
+ "2637408fe13086ea73f971e3425e2820"
+},
 /*
  * 

Re: [openssl-dev] [openssl.org #4428] Gentoo 12.1, x86_64: crypto/aes/aes_cfb.c:1:0: error: CPU you selected does not support x86-64 instruction set

[Andy Polyakov via RT]

>> Is it possible that real target is so called x32, i.e. x86_64 with
>> 32-bit address space limitation? In such case linux-x32 would be the
>> right target...
> 
> I don't believe this is x32 since {x86_64|amd64} and __ILP32__ are not
> defined; see preprocessor output below.

Got it. But just in case x32 was fixed anyway :-)

> The compiler reports its i686:
> 
> # gcc -dumpmachine
> i686-pc-linux-gnu
> 
> The machine appears to be i686:
> 
> # readelf -h /bin/ls | grep -i 'class\|machine'
>   Class: ELF32
>   Machine:   Intel 80386
> 
> The machine reports that its x86_64 through uname, though:
> 
> # uname -m
> x86_64
> 
> Maybe uname cannot be trusted for Gentoo?

Well, x86_64 is a string kernel returns to a user-land program, right?
And the thing is that it doesn't care if the program is 32- or 64-bit
one (unless you've changed "personality" for the said program). So that
above simply means that you have ended up with so to say 32-bit /, i.e.
with 32-bit /bin/ls, 32-bit compiler, the whole thing, but booted 64-bit
kernel. There is no reason why it wouldn't work. I mean such mix of
kernel and user-land. It's not common, but it works. Question is if it's
really the way all Gentoos get installed. On certain level it makes
sense to have all the system programs to be 32-bit, because they are not
performance-critical, so you can afford to trade a bit worse performance
to minimize memory and disk space consumption (latter can be surely
appropriate for a LiveCD). But they ought to provide compiler capable of
generating 64-bit code. So that user can compiler performance-critical
applications. Yes, 32-bit compiler can actually be configured to
generate code of either bitness, but it's not common nowadays. Very much
like 64-bit compiler can be configured to generate code of either
bitness, which is commonplace. The fact that it managed to compile first
assembly module simply means that assembler was configured to assemble
code of either bitness. As they are configured separately, binutils and
compiler, it's not impossible combination.

> # cat /etc/gentoo-release
> Gentoo Base System release 2.2

Once again, is it really average Gentoo installation? If it's not, then
I'd say that it's not OpenSSL problem. If you still have to compile for
this installation, then just invoke './Configure linux-elf ...'
manually. On side note, this is also the way to test 32-bit builds on
64-bit OS, though it normally takes extra option, './Configure linux-elf
-m32 ...'


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4428
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4367] FEATURE: Please add -headerpad_max_install_names to LDFLAGS for dynamic libraries on OS X builds

[Andy Polyakov via RT]

>> OS X side steps the problems with selecting the wrong runtime library
>> and RPATHs by using something called an install name. Effectively, the
>> install name should be placed in libcrypto.dylib and libssl.dylib, and
>> it calls out the fully qualified path name. Programs linked to a
>> library with an install name will record the library, and dyld(1) will
>> link to the proper library at runtime. There's no need for tricks like
>> LD_LIBRARY_PATH on Linux (its called DYLD_LIBRARY_PATH on OS X).
> 
> Well, formally speaking the feature was always there, all you needed to
> do is to pass -Wl,-headerpad_max_install_names at config time ;-) One
> can argue that it would be appropriate to run `which install_name_tool`
> in ./config and add the option automatically. Would it be acceptable? I
> mean would presence of install_name_tool be reliable indicator that
> linker supports -headerpad_max_install_names?
> 
>> To make room for an install name that may change (for example, from
>> PWD to /usr/local/ssl/lib, you need to use the flag
>> -headerpad_max_install_names on libcrypto.dylib and libssl.dylib.
>>
>> To add the icing to the cake, 'make install' should add the following
>> to its recipe for OS X:
>>
>>   cp libcrypto.dylib $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib
>>   install_name_tool -id $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib
>> $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib
> 
> Does it really copy libcrypto.dylib and not libcrypto.1.1.dylib? For me
> it copies the latter... Anyway, the suggested additional step should not
> be required, because we do pass -install_name when linking .dylib.
> install_name_tool step would be required if you install it at
> alternative location, but it doesn't belong in our Makefile. I mean
> because our Makefile would install in same location as -install_name anyway.

This was discussed a little bit off-list. It was confirmed that build
procedure writes correct install path in right places, so that default
install procedure doesn't require any adjustments, and therefore
-headerpad_max_install_names is not normally required. Or in other words
it's required only in *special* cases. And it's argued that special
cases can and should be treated by special means, e.g. by adding
-Wl,-headerpad_max_install_names at config time as mentioned above.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4367
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4428] Gentoo 12.1, x86_64: crypto/aes/aes_cfb.c:1:0: error: CPU you selected does not support x86-64 instruction set

[Andy Polyakov via RT]

> Is it possible that real target is so called x32, i.e. x86_64 with
> 32-bit address space limitation? In such case linux-x32 would be the
> right target...

On side note, I'm getting make test failures for linux-x32 target. I
mean if it turns out that it's the right target for you, and you see
make test failure, there is no need to report it for now, it's being
looked into.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4428
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

[Andy Polyakov via RT]

> It looks like the ULL suffix should be safe today;

This is misleading statement. *Today* U suffix should be safe, because
standard specifies that compiler should pick type automatically
depending on value of the constant. In order words suffices beyond U are
required only if you need constant to be of wider type, wider than its
value, e.g. 13ULL. Well, even then it might be superfluous, because type
promotion rules might do it for you. Going back to beginning, to "today
U suffix should be safe". Thing is that we kind of live between today
and yesterday, making it work not only with contemporary platforms, but
even older ones. So real question is if there is compiler supporting
64-bit integer (which is OpenSSL minimum requirement) which would
*truncate* constants in question, i.e. with U alone? I'm not aware of
any. Next question is if there is compiler that would *fail* to parse
ULL? Yes, older Microsoft 32-bit compilers would. Do you see where is it
going? It's going toward leaving U alone.

One can wonder if warning is actually justified. I'd argue that this
would be a trick question. Compiler in question obviously accepts long
long, but it's an *extension* to c89 [which we require and rely on]. Now
if compiler already accepts extensions, why would it have to complain
about extended constant values? I mean you either process extensions and
don't complain, or reject extension and complain. Anyway, the U is here
to stay. If warnings sting the eye that much, then the only appropriate
action would be to bump standard compliance by passing -std=c9x as
additional argument to config/Configure. One can argue that it should be
in Configuration/10-main.conf, or be automatically added by ./config.
Yes, I suppose it's appropriate assuming that compilers shipped with
MacOS X all recognize the option.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4422
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Andy Polyakov via RT]

 Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
 32-bit tests OK.

 The relevant snippets are:

 $ make test
 ...
 ../test/recipes/90-test_async.t ... 1/1
 #   Failed test 'running asynctest'
 #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
 # Looks like you failed 1 test of 1.
 ../test/recipes/90-test_async.t ... Dubious, test returned 1
 (wstat 256, 0x100)
 Failed 1/1 subtests
>>>
>>> Once again, "it boils down to the fact that getcontext always returns
>>> failure to ppc64 program. There is nothing we can do about it, you just
>>> have to accept that this particular thing doesn't work on MacOS
>>> X/ppc64." getcontext is part of libc equivalent, which is why there is
>>> nothing that can be done about it.
>>>
>>>
>> Can we detect the platform in async_posix.h so that if we work out we're
>> on ppc64 then we default to ASYNC_NULL?
> 
> #if defined(__APPLE__) && (defined(__ppc64__) || defined(_ARCH_PPC64))

add even && defined(__MACH__)



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4366
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Andy Polyakov via RT]

>>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>>> 32-bit tests OK.
>>>
>>> The relevant snippets are:
>>>
>>> $ make test
>>> ...
>>> ../test/recipes/90-test_async.t ... 1/1
>>> #   Failed test 'running asynctest'
>>> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
>>> # Looks like you failed 1 test of 1.
>>> ../test/recipes/90-test_async.t ... Dubious, test returned 1
>>> (wstat 256, 0x100)
>>> Failed 1/1 subtests
>>
>> Once again, "it boils down to the fact that getcontext always returns
>> failure to ppc64 program. There is nothing we can do about it, you just
>> have to accept that this particular thing doesn't work on MacOS
>> X/ppc64." getcontext is part of libc equivalent, which is why there is
>> nothing that can be done about it.
>>
>>
> Can we detect the platform in async_posix.h so that if we work out we're
> on ppc64 then we default to ASYNC_NULL?

#if defined(__APPLE__) && (defined(__ppc64__) || defined(_ARCH_PPC64))


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4366
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Andy Polyakov via RT]

> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
> 32-bit tests OK.
> 
> The relevant snippets are:
> 
> $ make test
> ...
> ../test/recipes/90-test_async.t ... 1/1
> #   Failed test 'running asynctest'
> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
> # Looks like you failed 1 test of 1.
> ../test/recipes/90-test_async.t ... Dubious, test returned 1
> (wstat 256, 0x100)
> Failed 1/1 subtests

Once again, "it boils down to the fact that getcontext always returns
failure to ppc64 program. There is nothing we can do about it, you just
have to accept that this particular thing doesn't work on MacOS
X/ppc64." getcontext is part of libc equivalent, which is why there is
nothing that can be done about it.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4366
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4428] Gentoo 12.1, x86_64: crypto/aes/aes_cfb.c:1:0: error: CPU you selected does not support x86-64 instruction set

[Andy Polyakov via RT]

On 03/14/16 03:58, noloa...@gmail.com via RT wrote:
> Working from Master...
> 
> gentoo@Gentoo-2012 ~/openssl $ ./config
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x1014L)
> no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [forced]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> no-dynamic-engine [forced]
> no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip 
> dir)
> no-egd  [default]  OPENSSL_NO_EGD (skip dir)
> no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
> no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
> no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
> no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
> no-shared   [default]
> no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
> no-ssl3 [default]  OPENSSL_NO_SSL3 (skip dir)
> no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
> no-static-engine [default]  OPENSSL_NO_STATIC_ENGINE (skip dir)
> no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
> no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
> no-zlib [default]
> no-zlib-dynamic [default]
> Configuring for linux-x86_64
> IsMK1MF   =no
> CC=gcc
> CFLAG =-Wall -O3 -pthread -m64 -DL_ENDIAN  -Wa,--noexecstack
> SHARED_CFLAG  =-fPIC
> DEFINES   =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
> OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM
> SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM
> ECP_NISTZ256_ASM POLY1305_ASM
> LFLAG =
> PLIB_LFLAG=
> EX_LIBS   =-ldl
> APPS_OBJ  =
> CPUID_OBJ =x86_64cpuid.o
> UPLINK_OBJ=
> BN_ASM=asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o
> x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
> EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o
> DES_ENC   =des_enc.o fcrypt_b.o
> AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> aesni-mb-x86_64.o
> BF_ENC=bf_enc.o
> CAST_ENC  =c_enc.o
> RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
> RC5_ENC   =rc5_enc.o
> MD5_OBJ_ASM   =md5-x86_64.o
> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> sha1-mb-x86_64.o sha256-mb-x86_64.o
> RMD160_OBJ_ASM=
> CMLL_ENC  =cmll-x86_64.o cmll_misc.o
> MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
> PADLOCK_OBJ   =e_padlock-x86_64.o
> CHACHA_ENC=chacha-x86_64.o
> POLY1305_OBJ  =poly1305-x86_64.o
> BLAKE2_OBJ=
> PROCESSOR =
> RANLIB=/usr/bin/ranlib
> ARFLAGS   =
> PERL  =/usr/bin/perl
> 
> SIXTY_FOUR_BIT_LONG mode
> 
> Configured for linux-x86_64.
> gentoo@Gentoo-2012 ~/openssl $ make depend && make clean && make
> rm -f
> rm -f
> rm -f libcrypto.a libssl.a
> rm -f apps/openssl test/afalgtest test/asynctest test/bftest
> test/bntest test/casttest test/clienthellotest test/constant_time_test
> test/ct_test test/danetest test/destest test/dhtest test/dsatest
> test/dtlsv1listentest test/ecdhtest test/ecdsatest test/ectest
> test/enginetest test/evp_extra_test test/evp_test test/exptest
> test/gmdifftest test/heartbeat_test test/hmactest test/ideatest
> test/igetest test/md2test test/md4test test/md5test test/mdc2test
> test/memleaktest test/nptest test/p5_crpt2_test test/packettest
> test/pbelutest test/randtest test/rc2test test/rc4test test/rc5test
> test/rmdtest test/rsa_test test/secmemtest test/sha1test test/sha256t
> test/sha512t test/srptest test/ssltest test/threadstest
> test/v3nametest test/verify_extra_test test/wp_test  apps/CA.pl
> tools/c_rehash
> rm -f crypto/sha/sha512-sparcv9.s crypto/chacha/chacha-ppc.s
> crypto/sha/sha256-mips.s crypto/sha/sha256-armv8.s
> crypto/rc4/rc4-586.s crypto/bn/ia64-mont.s crypto/x86cpuid.s
> crypto/aes/bsaes-x86_64.s crypto/sha/sha512-ppc.s
> crypto/sha/sha512-mips.s crypto/sha/sha1-mips.s
> crypto/ec/ecp_nistz256-armv4.s crypto/sha/sha1-mb-x86_64.s
> crypto/chacha/chacha-x86.s crypto/bn/alpha-mont.s
> engines/e_padlock-x86.s crypto/sha/sha512-586.s
> crypto/bn/sparcv9-gf2m.s crypto/aes/aes-armv4.s
> crypto/sha/sha256p8-ppc.s crypto/modes/ghash-x86.s
> crypto/modes/ghash-ia64.s crypto/sha/sha256-586.s
> crypto/aes/bsaes-armv7.s crypto/bn/sparct4-mont.s crypto/ia64cpuid.s
> crypto/camellia/cmll-x86.s crypto/x86_64cpuid.s
> crypto/poly1305/poly1305-armv4.s crypto/bn/rsaz-avx2.s
> crypto/bn/x86-mont.s crypto/modes/ghash-parisc.s
> crypto/aes/aest4-sparcv9.s crypto/bn/sparcv9-mont.s crypto/bf/bf-586.s
> crypto/des/crypt586.s crypto/bn/ppc-mont.s
> crypto/ec/ecp_nistz256-avx2.s crypto/aes/aesp8-ppc.s
> crypto/bn/parisc-mont.s crypto/sha/sha256-ppc.s
> crypto/sha/sha512-parisc.s crypto/aes/aesv8-armx.s
> crypto/bn/sparcv9a-mont.s 

Re: [openssl-dev] [openssl.org #4367] FEATURE: Please add -headerpad_max_install_names to LDFLAGS for dynamic libraries on OS X builds

[Andy Polyakov via RT]

> OS X side steps the problems with selecting the wrong runtime library
> and RPATHs by using something called an install name. Effectively, the
> install name should be placed in libcrypto.dylib and libssl.dylib, and
> it calls out the fully qualified path name. Programs linked to a
> library with an install name will record the library, and dyld(1) will
> link to the proper library at runtime. There's no need for tricks like
> LD_LIBRARY_PATH on Linux (its called DYLD_LIBRARY_PATH on OS X).

Well, formally speaking the feature was always there, all you needed to
do is to pass -Wl,-headerpad_max_install_names at config time ;-) One
can argue that it would be appropriate to run `which install_name_tool`
in ./config and add the option automatically. Would it be acceptable? I
mean would presence of install_name_tool be reliable indicator that
linker supports -headerpad_max_install_names?

> To make room for an install name that may change (for example, from
> PWD to /usr/local/ssl/lib, you need to use the flag
> -headerpad_max_install_names on libcrypto.dylib and libssl.dylib.
> 
> To add the icing to the cake, 'make install' should add the following
> to its recipe for OS X:
> 
>   cp libcrypto.dylib $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib
>   install_name_tool -id $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib
> $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib

Does it really copy libcrypto.dylib and not libcrypto.1.1.dylib? For me
it copies the latter... Anyway, the suggested additional step should not
be required, because we do pass -install_name when linking .dylib.
install_name_tool step would be required if you install it at
alternative location, but it doesn't belong in our Makefile. I mean
because our Makefile would install in same location as -install_name anyway.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4367
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

[Andy Polyakov via RT]

On 03/02/16 03:54, noloa...@gmail.com via RT wrote:
> $ make depend && make clean && make
> ...
> 
> $ make test
> ...
> 
> ../test/recipes/80-test_tsa.t . ok
> ../test/recipes/90-test_async.t ... 1/1
> #   Failed test 'running asynctest'
> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
> # Looks like you failed 1 test of 1.
> ../test/recipes/90-test_async.t ... Dubious, test returned 1
> (wstat 256, 0x100)
> Failed 1/1 subtests
> ...
> Test Summary Report
> ---
> ../test/recipes/90-test_async.t (Wstat: 256 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> Files=70, Tests=389, 213 wallclock secs ( 1.44 usr  0.75 sys + 166.97
> cusr 45.51 csys = 214.67 CPU)
> Result: FAIL
> Failed 1/70 test programs. 1/389 subtests failed.
> make[1]: *** [tests] Error 255
> 
> **

This apparently "derailed" off-topic. As for the problem above it boils
down to the fact that getcontext always return failure to ppc64 program.
There is nothing we can do about it, you just have to accept that this
particular thing doesn't work on MacOS X/ppc64.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4366
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4373] OS X 10.5, 32-bit PPC, and missing symbols (_ASYNC_get_current_job, _EVP_MD_meth_set_init, _RSA_PKCS1_OpenSSL, _EVP_MD_meth_new...)

[Andy Polyakov via RT]

> Working from master:
> 
>   $ git reset --hard HEAD && git pull
>   HEAD is now at e9b1c42 make errors
> 
> Then:
> 
> $ KERNEL_BITS=32 ./config
> ...
> 
> $ make depend && make clean && make
> ...
> 
> 
> $ make
> ...
> 
> LD_LIBRARY_PATH=..: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM
> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
> -DENGINESDIR="/usr/local/lib/engines" -O3 -D_REENTRANT -arch ppc
> -DB_ENDIAN -Wa,-force_cpusubtype_ALL -arch ppc -bundle -o
> ./dasync.dylib e_dasync.o -L.. -lcrypto
> Undefined symbols:
>   "_ASYNC_get_current_job", referenced from:
>   _dummy_pause_job in e_dasync.o

Fixed by
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=3ed1839dc3ad285ca83609007a18911d3c7bfdbe.
Closing ticket. [As well as re-closing chacha.s ticket.]




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4373
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

[Andy Polyakov via RT]

>>> If the other EVP ciphers universally allow this then I think we must
>> treat this
>>> as a bug, because people may be relying on this behaviour. There is also
>>> sporadic documentation in lower-level APIs (AES source and des.pod) that
>> the
>>> buffers may overlap.
>>>
>>> If it's inconsistent then, at the very least, we must document that it
>> is not
>>> allowed.
>>
>> I'd like to argue that EVP is not place to provide any guarantees about
>> partially overlapping buffers. Even though all current ciphers process
>> data in ascending address order, we shouldn't make assumption that there
>> won't be one that processes data in reverse order.
> 
> 
> I'm afraid that, since we haven't documented it, the world may already have
> made that assumption.

Fear is irrational and destructive feeling. Having faith that world is
better than that it nothing but healthy :-) What I'm saying is that
let's put a little bit more substance into discourse. Would anybody
consider it *sane* programming practice to rely on partially overlapping
buffers in *general* case? I.e. without actually *knowing* (as opposite
to *assuming*) what's gong on? [Control question: does compiler
guarantee order of references to memory?] As said in last message I
don't consider it sane and even consider it natural [which means that
I'd expect majority to not consider it sane too].

Once again, I'm not saying that nothing would be done, I simply want to
figure out where does line go. From my personal view point I'd say that
nothing *has to* be done, but it's just me. You seem to say that we're
obliged to support partially overlapping buffers. My question then is
*any* overlap, *any* cost? Shall we settle for simply writing down that
application developer may not rely on partially overlapping buffers? If
so, do we fix the modules in question arguing that this quality might be
desirable in different context [where modules in question can be used]?



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

[Andy Polyakov via RT]

> If the other EVP ciphers universally allow this then I think we must treat 
> this
> as a bug, because people may be relying on this behaviour. There is also
> sporadic documentation in lower-level APIs (AES source and des.pod) that the
> buffers may overlap.
> 
> If it's inconsistent then, at the very least, we must document that it is not
> allowed.

I'd like to argue that EVP is not place to provide any guarantees about
partially overlapping buffers. Even though all current ciphers process
data in ascending address order, we shouldn't make assumption that there
won't be one that processes data in reverse order. I'd even argue that
not providing such guarantee is natural, i.e. can be naturally
*implied*. Just like you may not expect a tablet to work after you glued
wheels to it to make a skateboard, arguing that nowhere does it say that
it's not a viable idea. It might work, and apparently did for somebody,
but you may not *expect* it to, neither as tablet or skateboard. And
tablet manufacturer has no obligation to disclaim it in writing.

I'm not saying that this particular problem can't/won't be addressed,
though I consider it kind of bad style. Because it kind of sets a
precedent of creating an undesired illusion. BTW, further measurements
have shown that unlike others, Core2 suffers 20% performance regression.
Well, one can argue that nobody cares about Core2, but what if it was
contemporary processor?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] 答复: [openssl.org #4360] [BUG] OpenSSL-1.0.1 crash on sha1_block_data_order_ssse3 asm

[Andy Polyakov via RT]

> 0x2b41740e8da7 <+2967>:   je 0x2b41740e8f40 
> 
> 0x2b41740e8dad <+2973>:   movdqa 0x40(%r11),%xmm6
> 0x2b41740e8db3 <+2979>:   movdqa (%r11),%xmm9
>  => 0x2b41740e8db8 <+2984>: movdqu (%r9),%xmm0
>  --is this what you want ?

And 'info reg' please.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4360
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4341] [PATCH] Consistently use arm_arch.h constants in armcap assembly code.

[Andy Polyakov via RT]

> Patch attached. This is just a little cleanup change to fix not everything
> using the OPENSSL_armcap constants. (Existing ones already are using them,
> so I'm assuming this is okay.)

Applied. Thanks.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4341
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4360] [BUG] OpenSSL-1.0.1 crash on sha1_block_data_order_ssse3 asm

[Andy Polyakov via RT]

Hi,

> we met crash of openssl (varely, 3 times i have seen) on linux x86_64.
> openSSL version is  1.0.1r.
> 
> The stack is as below:
> Program terminated with signal 11, Segmentation fault.
> Thread 1 (Thread 0x7f0654871700 (LWP 22383)):
> #0 0x7f06a2cdddb8 in sha1_block_data_order_ssse3 ()
> from */libcrypto.so.1.0.0
> #1 0xca62c1d6ca62c1d6 in ?? ()
> #2 0xca62c1d6ca62c1d6 in ?? ()
> #3 0xca62c1d6ca62c1d6 in ?? ()
> 
> We find the similar issue on https://rt.openssl.org/, the ticket id is 3191 .
> Can u help me confirm is it the same issue ?

Not with presented information :-( You need to complement it with output
from 'info reg' as well as output from 'disass' command till you see =>
mark pointing at failing instruction. From debugger prompts that is. And
since stack back-tracing is problematic here, tell approximately what
was going on? I mean did you experience crash with openssl command
(which one if so), or is it a web (or some other tls) server facing network?

> And where can I get the commit b77b58a398c8b9b4113f3fb6b48e162a3b8d4527 ?

It was incorporated 1.0.1 since 1.0.1f.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4360
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code

[Andy Polyakov via RT]

> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not
> attempted to debug this, but I have attached a test file which produces
> different output in normal and AVX2 codepaths. Our existing poly1305
> implementation agrees with the former.
> 
> $ OPENSSL_ia32cap=0 ./poly1305_test
> PASS
> $ ./poly1305_test
> Poly1305 test failed.t
> got:  2e65f0054e36505687d937ff5e8ed112
> expected: 69d28f73dd09d39a92aa179da354b7ea
> 
> You may wish to generalize that Poly1305_Update pattern into your own
> tests. This is what I did to catch this:
> https://boringssl-review.googlesource.com/#/c/7223/

About choice of test vector lengths. From viewpoint of exercising
different branches lengths 2048 through 2048+15 would exercise same
vector path. What one needs is combinations of 64*n+16*m. But you do
compensate for this by exercising varying what you've called excess
lengths. I suppose what I'm saying is that that +15 thing is kind of
redundant in the context. This is because last block is always processed
separately.

> By the way, this assembly code is quite complicated.

Yeah, but what you gonna do, vectorizing is hard in this case...

> I wasn't able to find
> problems in the others (I tested armv4, armv8, x86, and x86_64), but I'm
> far from confident I've covered all the cases.
> 
> With the caveat that I'm no assembly programmer, much of the complexity
> seems to come the SIMD code needing a multiple of 2 or 4 blocks and the
> implementation converting internal state back and forth from base 2^26 and
> 2^64 and handling excess blocks slightly differently in different cases. (I
> counted nine distinct codepaths to test in the x86_64 AVX codepath alone.)

While it's correct that excess blocks are handled though 2^26<>2^64
conversion in 64-bit modules, in 32-bit modules 2^32->2^26 is one way. I
mean in 32-bit modules even excess blocks are handled by vector code
(because it's faster than scalar code even if you have to discard some
data). Though "excess blocks" can be a little bit misleading term in the
context, because it kind of makes you think that processing is done as
[2|4]*n + remainder, while it's actually processed as remainder +
[2|4]n. [For reference, [2|4] will become [2|4|8] as soon as support for
AVX512 is added]. All this is provided that input length is longer than
certain limit. Vectorized procedure requires expensive setup which is
postponed till we know that input is long enough to justify additional
overhead (see
https://www.openssl.org/blog/blog/2016/02/15/poly1305-revised/ for
background information).

> The C code already buffers up to 16-byte blocks. Did you consider buffering
> up to 32 or 64 bytes in C when the SIMD code called for it?

Yes, but here is the thing. You'd need to be able to handle all possible
remainders in either case. So I figured it would be appropriate to take
"straight-forward" version for a "burn-out" to real world prior next
step ;-)

> I haven't tried this, so perhaps the performance costs are prohibitive, but
> if the costs are modest, the simplifications may be worth it.

No, it's perfectly reasonable. One should recognize though that you are
unlikely to gain like a lot in TLS case, because call pattern is rather
predictable. The noticeable gain would be observed in "wilder" mix of
calls. BTW, at some point I also plan to make e_chacha_poly1305.c
process couple of 4KB chunks at a time in order to improve cache locality...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code

[Andy Polyakov via RT]

>> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not
>> attempted to debug this, but I have attached a test file which produces
>> different output in normal and AVX2 codepaths. Our existing poly1305
>> implementation agrees with the former.
>>
>> $ OPENSSL_ia32cap=0 ./poly1305_test
>> PASS
>> $ ./poly1305_test
>> Poly1305 test failed.
>> got:  2e65f0054e36505687d937ff5e8ed112
>> expected: 69d28f73dd09d39a92aa179da354b7ea
> 
> While I keep looking further, double-check attached.

Attached is alternative solution, please double-check.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346
Please log in as guest with password guest if prompted

commit 3902c696c5406d68b17cecf9a9effb0edcb84eb2
Author: Andy Polyakov 
Date:   Sun Feb 28 21:48:43 2016 +0100

poly1305/asm/poly1305-*.pl: flip horizontal add and reduction.

Formally only 32-bit AVX2 code path needs this, but I choose to
harmonize all vector code paths.

RT#4346

diff --git a/crypto/poly1305/asm/poly1305-armv4.pl 
b/crypto/poly1305/asm/poly1305-armv4.pl
index 65b79cf..ac202ad 100755
--- a/crypto/poly1305/asm/poly1305-armv4.pl
+++ b/crypto/poly1305/asm/poly1305-armv4.pl
@@ -1057,6 +1057,15 @@ poly1305_blocks_neon:
 
 .Lshort_tail:

+   @ horizontal addition
+
+   vadd.i64$D3#lo,$D3#lo,$D3#hi
+   vadd.i64$D0#lo,$D0#lo,$D0#hi
+   vadd.i64$D4#lo,$D4#lo,$D4#hi
+   vadd.i64$D1#lo,$D1#lo,$D1#hi
+   vadd.i64$D2#lo,$D2#lo,$D2#hi
+
+   
@ lazy reduction, but without narrowing
 
vshr.u64$T0,$D3,#26
@@ -1086,15 +1095,6 @@ poly1305_blocks_neon:
vadd.i64$D1,$D1,$T0 @ h0 -> h1
 vadd.i64   $D4,$D4,$T1 @ h3 -> h4
 
-   
-   @ horizontal addition
-
-   vadd.i64$D2#lo,$D2#lo,$D2#hi
-   vadd.i64$D0#lo,$D0#lo,$D0#hi
-   vadd.i64$D3#lo,$D3#lo,$D3#hi
-   vadd.i64$D1#lo,$D1#lo,$D1#hi
-   vadd.i64$D4#lo,$D4#lo,$D4#hi
-
cmp $len,#0
bne .Leven
 
diff --git a/crypto/poly1305/asm/poly1305-armv8.pl 
b/crypto/poly1305/asm/poly1305-armv8.pl
index 79185d2..f1359fd 100755
--- a/crypto/poly1305/asm/poly1305-armv8.pl
+++ b/crypto/poly1305/asm/poly1305-armv8.pl
@@ -791,6 +791,19 @@ poly1305_blocks_neon:
 
 .Lshort_tail:

+   // horizontal add
+
+   addp$ACC3,$ACC3,$ACC3
+ldpd8,d9,[sp,#16]  // meet ABI requirements
+   addp$ACC0,$ACC0,$ACC0
+ldpd10,d11,[sp,#32]
+   addp$ACC4,$ACC4,$ACC4
+ldpd12,d13,[sp,#48]
+   addp$ACC1,$ACC1,$ACC1
+ldpd14,d15,[sp,#64]
+   addp$ACC2,$ACC2,$ACC2
+
+   
// lazy reduction, but without narrowing
 
ushr$T0.2d,$ACC3,#26
@@ -822,19 +835,6 @@ poly1305_blocks_neon:
 add$ACC4,$ACC4,$T1.2d  // h3 -> h4
 

-   // horizontal add
-
-   addp$ACC2,$ACC2,$ACC2
-ldpd8,d9,[sp,#16]  // meet ABI requirements
-   addp$ACC0,$ACC0,$ACC0
-ldpd10,d11,[sp,#32]
-   addp$ACC1,$ACC1,$ACC1
-ldpd12,d13,[sp,#48]
-   addp$ACC3,$ACC3,$ACC3
-ldpd14,d15,[sp,#64]
-   addp$ACC4,$ACC4,$ACC4
-
-   
// write the result, can be partially reduced
 
st4 {$ACC0,$ACC1,$ACC2,$ACC3}[0],[$ctx],#16
diff --git a/crypto/poly1305/asm/poly1305-x86.pl 
b/crypto/poly1305/asm/poly1305-x86.pl
index 7c1aee5..fb9fa2b 100755
--- a/crypto/poly1305/asm/poly1305-x86.pl
+++ b/crypto/poly1305/asm/poly1305-x86.pl
@@ -536,6 +536,8 @@ my $base = shift; $base = "esp" if (!defined($base));
 },"edx");
 
 sub lazy_reduction {
+my $extra = shift;
+

# lazy reduction as discussed in "NEON crypto" by D.J. Bernstein
# and P. Schwabe
@@ -543,6 +545,7 @@ sub lazy_reduction {
 ($T0,$D3);
   ($D3,$MASK);
  ($T0,26);
+&$extra()  if (defined($extra));
  ($T0,$D4);  # h3 -> h4
 ($T1,$D0);
   ($D0,$MASK);
@@ -1091,21 +1094,21 @@ my $addr = shift;
 
 _label("short_tail");
 
-   _reduction ();
-

# horizontal addition
 
+  

Re: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code

[Andy Polyakov via RT]

> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not
> attempted to debug this, but I have attached a test file which produces
> different output in normal and AVX2 codepaths. Our existing poly1305
> implementation agrees with the former.
> 
> $ OPENSSL_ia32cap=0 ./poly1305_test
> PASS
> $ ./poly1305_test
> Poly1305 test failed.
> got:  2e65f0054e36505687d937ff5e8ed112
> expected: 69d28f73dd09d39a92aa179da354b7ea

While I keep looking further, double-check attached.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346
Please log in as guest with password guest if prompted

diff --git a/crypto/poly1305/asm/poly1305-x86.pl 
b/crypto/poly1305/asm/poly1305-x86.pl
index 7c1aee5..6f743ba 100755
--- a/crypto/poly1305/asm/poly1305-x86.pl
+++ b/crypto/poly1305/asm/poly1305-x86.pl
@@ -1435,7 +1435,7 @@ sub X { my $reg=shift; $reg=~s/^ymm/xmm/; $reg; }
   ("eax","eax");  # is_base2_26?
 (("enter_blocks"));
 
-_label("enter_avx2",16);
+_label("enter_avx2");
 ();
 
   (("pic_point"));
@@ -1540,6 +1540,8 @@ sub X { my $reg=shift; $reg=~s/^ymm/xmm/; $reg; }
("ecx",-64);
("edx",63);
 
+   _reduction();
+
(($T0),(16*0,"esi"));
("edx",32);
 (("one"));
@@ -1778,8 +1780,8 @@ sub vlazy_reduction {
  ((-16*3+4*3,"edi"),"xmm3");
  ((-16*3+4*4,"edi"),"xmm4");
 ();
+   ("esp","ebp");
 _label("nodata");
-   ("esp","ebp");
 _end("_poly1305_blocks_avx2");
 }
 _label("const_sse2",64);
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs

[Andy Polyakov via RT]

> The fix seems to work.

On related note, a problem was reported with poly1305-armv4 module,
which was traced down to assembler (different versions disagree about
how to treat #-1 as argument to vmov.i64). If you run into problem,
don't panic, fix is upcoming...


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs

[Andy Polyakov via RT]

Hi,

> The partial-block tail code in chacha-armv4.pl also seems to have problems.
> My colleague Steven and I made an attempt to debug it, but we're not
> familiar enough with ARM to fix it.
> 
> From playing with it in a debugger, it doesn't look like @t[3] contains the
> length. We suspect something is going wrong with the condition flags on
> loading or updating length.
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-armv4.pl;h=55ebc9e586475a35e313b74483eb4b8d5b6f2b03;hb=HEAD#l585

Attached is patch for chacha-armv4.pl (please verify) and a test snippet
I've put together.

> It may be worth going back and testing these cases on all of the
> implementations as well.

Besides armv4 only s390x module was failing.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323
Please log in as guest with password guest if prompted

diff --git a/crypto/chacha/asm/chacha-armv4.pl 
b/crypto/chacha/asm/chacha-armv4.pl
index 55ebc9e..6c20755 100755
--- a/crypto/chacha/asm/chacha-armv4.pl
+++ b/crypto/chacha/asm/chacha-armv4.pl
@@ -440,9 +440,9 @@ $code.=<<___;
eorhs   @x[4],@x[4],@t[0]
eorhs   @x[5],@x[5],@t[1]
 # ifdef__thumb2__
-   it  hi
+it ne
 # endif
-ldrhi  @t[0],[sp,#4*(32+2)]@ re-load len
+ldrne  @t[0],[sp,#4*(32+2)]@ re-load len
 # ifdef__thumb2__
itt hs
 # endif
@@ -584,9 +584,9 @@ ___
 }
 $code.=<<___;
 # ifdef__thumb2__
-   it  hi
+   it  ne
 # endif
-   ldrhi   @t[0],[sp,#4*(32+2)]@ re-load len
+   ldrne   @t[0],[sp,#4*(32+2)]@ re-load len
 # ifdef__thumb2__
it  hs
 # endif
@@ -598,15 +598,15 @@ $code.=<<___;
 
 .Ltail:
ldr r12,[sp,#4*(32+1)]  @ load inp
-   add @t[2],sp,#4*(0)
+   add @t[1],sp,#4*(0)
ldr r14,[sp,#4*(32+0)]  @ load out
 
 .Loop_tail:
-   ldrb@t[0],[@t[2]],#1@ read buffer on stack
-   ldrb@t[1],[r12],#1  @ read input
-   subs@t[3],@t[3],#1
-   eor @t[0],@t[0],@t[1]
-   strb@t[0],[r14],#1  @ store output
+   ldrb@t[2],[@t[1]],#1@ read buffer on stack
+   ldrb@t[3],[r12],#1  @ read input
+   subs@t[0],@t[0],#1
+   eor @t[3],@t[3],@t[2]
+   strb@t[3],[r14],#1  @ store output
bne .Loop_tail
 
 .Ldone:
@@ -1120,7 +1120,7 @@ $code.=<<___;
 # endif
stmia   @t[0],{@x[0]-@x[7]}
 add@t[2],sp,#4*(0)
-sub@t[3],@t[0],#64*3   @ len-=64*3
+sub@t[3],@t[3],#64*3   @ len-=64*3
 
 .Loop_tail_neon:
ldrb@t[0],[@t[2]],#1@ read buffer on stack
#include 
#include 
#include 

#include "internal/chacha.h"

const unsigned int key[] =  {0x03020100,0x07060504,0x0b0a0908,0x0f0e0d0c,
 0x13121110,0x17161514,0x1b1a1918,0x1f1e1d1c};
const unsigned int ivp[] =  {0x,0x,0x03020100,0x07060504};
const unsigned char out[] = "f798a189f195e66982105ffb640bb775"
"7f579da31602fc93ec01ac56f85ac3c1"
"34a4547b733b46413042c94400491769"
"05d3be59ea1c53f15916155c2be8241a"
"38008b9a26bc35941e2444177c8ade66"
"89de95264986d95889fb60e84629c9bd"
"9a5acb1cc118be563eb9b3a4a472f82e"
"09a7e778492b562ef7130e88dfe031c7"
"9db9d4f7c7a899151b9a475032b63fc3"
"85245fe054e3dd5a97a5f576fe064025"
"d3ce042c566ab2c507b138db853e3d69"
"59660996546cc9c4a6eafdc777c040d7"
"0eaf46f76dad3979e5c5360c3317166a"
"1c894c94a371876a94df7628fe4eaaf2"
"ccb27d5aaae0ad7ad0f9d4b6ad3b5409"
"8746d4524d38407a6deb3ab78fab78c9"
"4213668bbbd394c5de93b853178addd6"
"b97f9fa1ec3e56c00c9ddff0a44a2042"
"41175a4cab0f961ba53ede9bdf960b94"
"f9829b1f3414726429b362c5b538e391"
"520f489b7ed8d20ae3fd49e9e259e443"
"97514d618c96c4846be3c680bdc11c71"
"dcbbe29ccf80d62a0938fa549391e6ea"
"57ecbe2606790ec15d2224ae307c1442"
"26b7c4e8c2f97d2a1d67852d29beba11"
"0edd445197012062a393a9c92803ad3b"
"4f31d7bc6033ccf7932cfed3f019044d"
"25905916777286f82f9a4cc1ffe430ff"
"d1dcfc27deed327b9f9630d2fa969fb6"
"f0603cd19dd9a9519e673bcfcd901412"
"5291a44669ef7285e74ed3729b677f80"
"1c3cdf058c50963168b496043716c730"
"7cd9e0cdd137fccb0f05b47cdbb95c5f"
"54831622c3652a32b2531fe326bcd6e2"
"bbf56a194fa196fbd1a54952110f51c7"
"3433865f7664b836685e3664b3d8444a"
"f89a242805e18c975f1146324996fde1"

Re: [openssl-dev] [openssl.org #4305] ChaCha20 assembly bugs

[Andy Polyakov via RT]

>> 1. In chacha-x86_64.pl, .Ltail:
>>
>> 2. In chacha-x86_64.pl, .Loop_tail_ssse3:
>>
>> 3. In chacha-x86.pl, loop:
> 
> Fix is upcoming. Thanks!
> 
>> 4. The assembly versions crash if you pass in an empty input/output. The
>> generic C code handles this fine. (I'll defer to you whether this is a bug
>> or a caller obligation to be documented.)
> 
> This will be addressed separately by fixing all modules. I mean not all
> modules have this problem, but all modules will be double-checked and
> fixed as required.

Fixes are committed. Thanks again.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4305
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4210] Compiler warning for Sparc T4 DES opcodes

[Andy Polyakov via RT]

> OpenSSL 1.1.0 Pre 1
> Platform: Sparc Solaris 10
> Compiler: GCC 4.9.3
> 
> Warnings:
> 
> e_des.c: In function 'des_init_key':
> e_des.c:239:29: warning: assignment from incompatible pointer type
>   dat->stream.cbc = enc ? des_t4_cbc_encrypt : 
> des_t4_cbc_decrypt;
>   ^
> e_des3.c: In function 'des_ede_init_key':
> e_des3.c:266:29: warning: assignment from incompatible pointer type
>   dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt :
>   ^
> e_des3.c: In function 'des_ede3_init_key':
> e_des3.c:293:29: warning: assignment from incompatible pointer type
>   dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt :

Addressed in
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7687f5255011a5a3ca75e8c5427683d58ae411c0
(and there is 1.0.2-specific too). Closing the ticket. Thanks.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4210
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

[Andy Polyakov via RT]

>  You can also add some more macros to the perlasm which already translates a
> LOT of opcodes into something older assemblers won't choke on.

If it was a matter of few instructions, then absolutely. But if it's a
question about *all* vector instructions, then it becomes
counter-productive. As already mentioned, in situation like this it
*would* be more appropriate to discuss *option* of disabling vector code
altogether. Rather than implementing complete AltiVec support in perlasm
that is. But as long as we are talking about one obsolete platform(*),
any non-trivial effort becomes questionable. To draw a parallel, why
doesn't IBM provide AIX 5.2 users with more capable assembler? What I'm
trying to say is that whatever reason that is articulated, similar one
can be formulated on OpenSSL behalf.

(*) I'm not referring to AIX as obsolete platform, but to obsolete AIX
*versions*.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

[Andy Polyakov via RT]

Hi,

> Per Jeremy Farrell's suggestion, specifying the "-no-asm" option worked and I 
> was able to get through the build.
> 
> Regarding the "stvx" instruction, here is a bit clearer set of info to map to 
> why that instruction seemed to be the issue:

Original report listed even last lines in error output, and those were
referring to lvx instructions. So that insisting on problem being
limited to stvx by limiting error output doesn't make it clearer.
Question still is if tool-chain in question supports vector instruction
*at all*. If it doesn't, then no-asm is the only option that can be offered.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229
Please log in as guest with password guest if prompted

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