Re: [openssl-dev] Potential timing problems in OpenSSL RSA implementation

Hi, > I'd like to stress that this is highly speculative, it may very well be > that this is not exploitable in any practical way. But I thought it's > important enough that it should be public knowledge. (Also "This leaves > a small timing channel, [...] but it is not believed to be large >

Re: [openssl-dev] #GP happens in do_sse3_after_all

Hi, I met an issue in the crypto/chacha/chacha-x86_64.S, could you be kind to have a look on it? Thanks very much. Currently it will stuck in the function *do_sse3_after_all*, and a #GP will occurs due to the following instructions ““movdqa %xmm0,0(%rsp)” need 16 bytes alignment, however,

Re: [openssl-dev] Travis [extended tests] tag

>> In order to improve CI turn-around times Travis config in master branch >> was tweaked to minimize the time it takes to process pull requests. This >> is done by "short-circuiting" most expensive tests: sanitizers, >> coverage, wine-based tests. Thing to keep in mind is that >>

[openssl-dev] Travis [extended tests] tag

In order to improve CI turn-around times Travis config in master branch was tweaked to minimize the time it takes to process pull requests. This is done by "short-circuiting" most expensive tests: sanitizers, coverage, wine-based tests. Thing to keep in mind is that "short-circuited" test come out

Re: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256

>> Does this fix it? >>https://github.com/openssl/openssl/pull/2582 > > It's unrelated issues. Yes, it's typo in full_handler, will be fixed > [tomorrow]... Fix has been applied. Thank you for report! -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256

> Does this fix it? >https://github.com/openssl/openssl/pull/2582 It's unrelated issues. Yes, it's typo in full_handler, will be fixed [tomorrow]... -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MD5 speed

> I had some surprising results of the speed command when testing the > md5 speed on the 1.1.0-stable branch (for both a shared and a static > build): > openssl speed md5 returns: > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > 16384 bytes > md5

Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

> A run on my laptop gave these results: > > : ; ./util/shlib_wrap.sh apps/openssl speed siphash lhash > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes 16384 bytes > lhash 147387.67k 147940.82k 144937.73k 147177.81k > 147095.55k

Re: [openssl-dev] Cross compiling openssl for an old ARM environment - howto?

>> Are we saying that it absolutely will not support ARM7 thumb mode anymore? > > Nobody is saying that. We're saying that if the address-space is 16bit, > openssl will not work. 16-bit in original request refers to instructions' size, not address space. But it's actually a misnomer, as Thumb,

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

>> I can't reproduce this. But on the other hand I don't have previous > >installation on --prefix. > > But did you add “enable-tls1_3” to your config? > > >I mean I would guess this is because test > >program picks shared libraries at --prefix locations instead of just > >built

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

> Mac OS X 10.11.6, Xcode-8.1. > > $ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib > enable-ec_nistp_64_gcc_128 enable-rfc3779 > --prefix=/Users/ur20980/src/openssl-1.1 > --openssldir=/Users/ur20980/src/openssl-1.1/etc > Configuring OpenSSL version

Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse

> Actually it should also be noted that snippet presented in originally > mentioned > http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html > is actually compiles as just > > _intel_fast_memset(args) > > by Intel compiler 17.0 (a.k.a. 2017). Second look at code generated by

Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse

>> We do have assembler versions for most CPI's. > > In the context one can also add that the kind of optimization that could > omit memset invocation *has to* rely on deep inter-procedural > *multi-file* analysis. If compiler is given mem_clr.c alone, and it > doesn't look at it when compiling

Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse

> We do have assembler versions for most CPI's. In the context one can also add that the kind of optimization that could omit memset invocation *has to* rely on deep inter-procedural *multi-file* analysis. If compiler is given mem_clr.c alone, and it doesn't look at it when compiling other

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

> - 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!

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

> 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

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

> 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

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

> 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

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

> 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

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

> 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

Re: [openssl-dev] Is Intel ADX instruction extension supported by the latest OpenSSL?

> I'm looking at how to adopt Intel ADX instruction extension in OpenSSL. Below > man page mentions ADCX/ADOX instructions: > > https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html > > but I can not find ADCX/ADOX related words/expressions from OpenSSL-1.0.2h > source code. I

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

> Hm, words fail me. > > Well, that's not entirely true. But *polite* words fail me... :-) > Let me try to understand this... you have always ignored, and still > ignore, the actual LC_CTYPE which tells you the character set in which > the password was provided from the user. > > You *used* to

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

> So let's try a better example. The password is "ĂŻ" (U+0102 U+017b), > and the locale (not that it *should* matter) is ISO8859-2. When it comes to locale in *this* case you should rather wonder what does your terminal emulator program do and how does it interact with your shell. Because these

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

First of all. *Everything* that is said below (and what modifications in question are about) applies to non-ASCII passwords. ASCII-only passwords are not affected by this and keep working as they were. >> commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9 >> >> OpenSSL versions before 1.1.0 didn't

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

> 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

Re: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability

>>> How about something like this.. A VC-WIN32-XP target that has >>> everything needed to make a max compatibility target >>> When building under VS2012 and above.. (I also tested in VS2015) >>> adds CFLAGS /arch:IA32 -D_USING_V110_SDK71_ >>> adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref >>

Re: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability

> How about something like this.. A VC-WIN32-XP target that has > everything needed to make a max compatibility target > When building under VS2012 and above.. (I also tested in VS2015) > adds CFLAGS /arch:IA32 -D_USING_V110_SDK71_ > adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref How about

Re: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability

>> When building with Visual Studio 2008 SSE is disabled by default. When >> building with Visual Studio 2012 and above you must supply a new flag >> /arch:IA32 to not build with SSE. Would it be acceptable to update the >> Configure process to add the /arch:IA32 if Visual Studio 2012 or >>

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>>> * Fix ecp_nistz256_mul_by_2 and ecp_nistz256_mul_by_3 to fully reduce >>> their outputs. >>> >>> * Fix ecp_nistz256_add to fully reduce its output. >> >> As for specifically addition see below. As for fixing mul_by_[23] and >> the fact that they use addition. There are two ways. a) Modify

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

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:

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

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: > >

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

> 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,

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

> 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.

Re: [openssl-dev] ecp_nistz256 is_one is too liberal with what it considers to be one

>>>if (P256_LIMBS == 8) { >>> res |= a[4] ^ ONE[4]; >>> res |= a[5] ^ ONE[5]; >>> res |= a[6] ^ ONE[6]; >>> +res |= a[7] ^ ONE[7]; >>>} >> >> It's not actually a coincidence that it ends with a[6]. If you have >> close look at ecp_nistz256_is_affine_G, you'll see that it

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

e result is correct, and in particular that Z_is_one is set >> correctly on the result, when the final result is at infinity, especially >> for the cases where neither the input points are at infinity, e.g. when >> adding (n-1)G to 1G. >> >> Note that all of the above c

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>> * Fix ecp_nistz256_mul_by_2 and ecp_nistz256_mul_by_3 to fully reduce >> their outputs. >> >> * Fix ecp_nistz256_add to fully reduce its output. > > As for specifically addition see below. As for fixing mul_by_[23] and > the fact that they use addition. There are two ways. a) Modify addition >

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>> It appears to me that with multiplication, squaring, subtraction, >> negation, halving *preserving* property of being fully reduced (i.e. if >> inputs are fully reduced, then output is too), we only have to watch out >> for mul_by_[23], i.e. ensure that their outputs are fully reduced. This >>

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>> I think you are assuming that ret is in the range [0, 2P), so that if >> you subtract P, the result would be in the range [0, P). That is the >> case in normal Montgomery multiplication, where the inputs are in the >> range [0, P). But, my understanding is that if the inputs are in the >> range

Re: [openssl-dev] ecp_nistz256 is_one is too liberal with what it considers to be one

> Please see the attached program and consider the following change: > > ``` >if (P256_LIMBS == 8) { > res |= a[4] ^ ONE[4]; > res |= a[5] ^ ONE[5]; > res |= a[6] ^ ONE[6]; > +res |= a[7] ^ ONE[7]; >} It's not actually a coincidence that it ends with a[6]. If you have

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>>> My understand after talking with Vlad that the "sbb \$0, $acc2" makes >>> this equivalent to (r >= 2**256) ? (r - q) : r. If the "sbb \$0, >>> $acc2" line were removed then it would be equivalent to (r >= q) ? (r >>> - q) : r. My understanding is that the difference in semantics is >>> exactly

Re: [openssl-dev] weird linker warnings on solaris 11

>>> I went back to the 12.4 compiler which works very well, waste of my time >>> to debug Oracle compiler, as we wont see any patches released anyway (no >>> support here) >> >> And I installed vendor compiler, 12.5, and I don't observe linker >> warnings... > >interesting, can I ask which

Re: [openssl-dev] weird linker warnings on solaris 11

> I went back to the 12.4 compiler which works very well, waste of my time > to debug Oracle compiler, as we wont see any patches released anyway (no > support here) And I installed vendor compiler, 12.5, and I don't observe linker warnings... On related note one should probably point out that

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

> Let's recall that result of multiplication prior final reduction is > actually n+1-limb value, with +1 limb being single bit, This came out wrong. Result is N+1 *bits* wide, it's just in this particular case you have to spend additional limb on the the additional bit. It's just that particular

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

> ... I re-read the code for the conditional subtraction at the > end of ecp_nistz256_mul_mont (__ecp_nistz256_mul_montq, actually) and > I couldn't convince myself that the result was always fully reduced. > > My concern is that what you say and what Vlad said is contradictory. > You both

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

> 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 >

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>>> No, it subtraction subroutine uses *borrow* to determine if modulus is >>> to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b >>> are less than P, then result is less than P. >> >> Consider the case where a > P and a >= b and b is very small (e.g. 1). >> For example, a == P

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>> No, it subtraction subroutine uses *borrow* to determine if modulus is >> to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b >> are less than P, then result is less than P. > > Consider the case where a > P and a >= b and b is very small (e.g. 1). > For example, a == P + 2

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

>>> Note in particular that, IIUC, ecp_nistz256_neg will never get an >>> unreduced input when applied to the the based point multiples, because >>> those are already fully reduced. But, when it is used in >>> ecp_nistz256_windowed_mul, it isn't clear whether or how the input Y >>> coordinate is

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

> C-callables are wrappers around inlined subroutines. The only thing they > do is load input into designated registers and call inlines, those used > in point functions. It's true for modules other than x86_64, but not x86_64 one. Sorry about confusion. -- openssl-dev mailing list To

Re: [openssl-dev] [PATCH] crypto/ui/ui_openssl.c: let new-line through after query in Windows path.

>> Originally new-line was suppressed, because double new-line was >> observed under wine. But it appears rather to be a wine bug, >> because on real Windows new-line is much needed. >> >> Reviewed-by: Richard Levitte > > Hm, this commit comment needs an explicit reference

Re: [openssl-dev] weird linker warnings on solaris 11

> the issue appears to be not in the compiler, but the newer Soalris linker (ld) > I switched back to using 12.4 compiler, issue went away BUT now the issue > surfaces > if building OpenSSL using GCC. Some examples during the test suite What I was going to comment before I've read this message

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

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, > -

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

> ( 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 >

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

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 >

Re: [openssl-dev] OpenSSL 1.1.0 pre 6: SPARCv9 capability bits problem

> The following change introduced build problems: > >> +if (vec[1]&0x8) OPENSSL_sparcv9cap_P[0] |= SPARCV9_VIS4; > > ... here we use vec[1], so the compiler warns: > > crypto/sparcv9cap.c:179:20: warning: array subscript is above array > bounds [-Warray-bounds] >

Re: [openssl-dev] OpenSSL 1.1.0 pre 5+6: SPARCv9 assembler stack alignment problem

> When building OpenSSL 1.1.0 pre 5 or pre 6 on Sparc I get: > > /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 4811: warning: > stack alignment problem; second operand is not a multiple of 8 > /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5063: warning: > stack alignment

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

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

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

> 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 --

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

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

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

> 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

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

>>> (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. >>>

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

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 sy

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

>> (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

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

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: > >

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

> 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,

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

> 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

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

> 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

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

>> 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

Re: [openssl-dev] [ARM] sha1_block_armv8 caller

> I see that there is function named sha1_block_armv8 defined in > crypto/sha/asm/sha1-armv8.pl, but I cannot find any function that > calls it. Note that symbol is not global, you can't even link to it from outside. But the real question is if code is *executed*. As calling is not the only way

Re: [openssl-dev] aarch64 64bit build with linaro tools

> I'm trying to build a 64bit aarch64 OpenSSL library with linaro tools[1]. > Whatever I try, the library compiles to the 32bit version. > How do I get a 64bit library version? I'm using very same toolchain, and I get as 64-bit AArch64 library as it can possibly get. Though truth be told I'm

Re: [openssl-dev] arch (ARM) capabilities

>>> But when I've tested it on AArch64 with openssl-1.1.0-pre5 and >>> current master (./configure no-shared no-engine) I'm getting >>> 100524.03k vs 52172.12k/s in favour of the non-EVP version. >>> >>> Is that really expected? >> >> Depends on your system. Not all AArch64 processors were born

Re: [openssl-dev] arch (ARM) capabilities

>> I want something more programmatic, more general. I want to deliver >> a piece of software that will run on ARM architectures and will >> issue a warning or something like that if the user does not have an >> OpenSSL library set to work with ARM Crypto Extension. > > What does "set to work"

Re: [openssl-dev] arch (ARM) capabilities

> I want something more programmatic, more general. > I want to deliver a piece of software that will run on ARM architectures and > will issue a warning or something like that if the user does not have an > OpenSSL library set to work with ARM Crypto Extension. What does "set to work" mean?

Re: [openssl-dev] arch (ARM) capabilities

>> Is there an option when making an app that uses OpenSSL to verify >> that is uses Crypto Extensions (like checking a flag or something >> like that) ? > > With x86_64, ciphers like aes-128-cbc are much faster with AES-NI, > so a simple benchmark: > > openssl speed aes-128-cbc openssl speed

Re: [openssl-dev] Making assembly language optimizations working onCortex-M3

> The BoringSSL works as follows: > > 1. The person building the code passes -DOPENSSL_STATIC_ARMCAP and some > other flags like -DOPENSSL_STATIC_ARMCAP_NEON, to indicate which > features are available on the target. > > 2. When OPENSSL_STATIC_ARMCAP is defined, the runtime detection of >

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

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

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

> ... 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:

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

>>> # ./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" >>

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

> 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:

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

>>> 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

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

> 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]

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

> 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

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

>> 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:

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

> 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) >

Re: [openssl-dev] Assembler warns about constants in poly1306-x86_64.pl

> Yasm 1.3.0 (Like nasm, but it embeds debug symbols into the asm code > on Windows) reports: > > poly1305-x86_64.asm(456): warning : value does not fit in 32 bit field > poly1305-x86_64.asm(459): warning : value does not fit in 32 bit field > poly1305-x86_64.asm(1346): warning : value does not

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

>>> ../test/recipes/30-test_evp.t .. >>> 1..1 >>> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH >>> Expected: >>>

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

d 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 <ap...@openssl.org> Date: Sat, 18 Jun 2016 15:3

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

> 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

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

> 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,

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

> 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

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

> 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

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

> 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:

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

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

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

> 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

Re: [openssl-dev] Stitched AES-NI AES-GCM code & AVX2

>>> But, I think the stitched AES-NI AES-GCM code requires AVX2, not just >>> AVX. >> >> No, it doesn't. It requires exactly AVX+MOVBE. > > I see. I was confused because the code says: > > if ($avx>1) {{{ > > I had been thinking the whole time that "$avx > 1" means that AVX2 is >

Re: [openssl-dev] Stitched AES-NI AES-GCM code & AVX2

Hi, > I see that the stitched AES-NI AES-GCM code will be used if : > > gctx->ctr==aesni_ctr32_encrypt_blocks && \ > gctx->gcm.ghash==gcm_ghash_avx) > > In gcm128, I see that it decides to use gcm_ghash_avx if: > > /* AVX+MOVBE */ > if (((OPENSSL_ia32cap_P[1] >> 22) & 0x41) ==

Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds

>>> Could somebody adjust who understand the assembly code (probably Andy) >>> modify it to use symbolic names for the offsets that are used to >>> access Xi, H, Htable? If so, then I can write the patch to >>> conditionally exclude `H` on platforms that don't need it after >>>

Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds

> One can *probably* discuss > that it would be appropriate to *facilitate* omission of H in context > *other than* OpenSSL by avoiding H during most of the setup procedure. > See attached patch for example. But do note that I'm not saying that it > works or suggesting to include it right away, I

Re: [openssl-dev] Removing gcm128_context->H for non-1-bit builds

> I noticed that the `H` member of `gcm128_context` seems to be > unnecessary for builds that aren't using the 1-bit GCM math. Since > this member is large (128-bits) and some applications may have lots of > GCM contexts relative to the amount of memory they have, I think it > would be great to

Re: [openssl-dev] Why is `volatile` used in MOD_EXP_CTIME_COPY_FROM_PREBUF?

>>> See >>> https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631 >>> >>> + volatile BN_ULONG *table = (volatile BN_ULONG *)buf; >>> >>> Why is `volatile` used here? Is it to work around the effective type >>> (strict aliasing)

  1   2   3   4   5   6   7   8   9   10   >