text:
OpenSSL support for z/OS

We are using OpenSSL 1.1.0 with some modifications on z/OS. While using OpenSSL 1.1.0 as a static library works fine, it is currently not possible to use OpenSSL 1.1.0 in the context of a shared library. If the calling process decides to unload the shared library, there is a crash when the calling process exits, because the cleanup routines registered via atexit() are no longer available after the unloading of the shared library.
The reason is that for z/OS no platform-specific code exists that protects the shared library from unloading by deliberately leaking a reference to the shared library. See the relevant code in crypto/init.c:
https://github.com/openssl/openssl/blob/f2828a14fbe2ce56b5090f45b2a9a6e749d33b22/crypto/init.c#L143
This issue is related to the discussion in issue #7388, and @mattcaswell asked me create a separate issue for the z/OS problem.

Patches for z/OS would also be welcome. It has been on my list to complete that work.

You could also link with -Wl,-znodelete and compile with -DOPENSSL_USE_NODELETE which is what we have done for this issue while we add support for atexit handlers for unloading libraries.

Patches for z/OS would also be welcome. It has been on my list to complete that work.

@t-j-h: In what form would you want the patches, and against what baseline?
Our OpenSSL codebase has additional changes beyond z/OS+EBCDIC support, and we are using OpenSSL 1.1.0 currently. So it would require some additional effort to prepare a patch that only includes our EBCDIC-specific code. It is also possible and even likely that EBCDIC support is incomplete, as we are only using a small fraction of OpenSSL's functionality, and we are testing OpenSSL only in the context of our application.
Nevertheless we would be very interested if we can help to get official z/OS support into OpenSSL.

PRs against master is what are the most useful - and not all lumped into a single patch.
Separately if you want some views on the approach you have taken feel free to contact me directly and I can take a look at what you have done. I've been through multiple sets of approaches - but we haven't ever had a set of patches that get us to the point of the test suite fully working. Getting the library working isn't that hard - but ensuring all the test applications compile and operate is the challenge.
That is the "bar" to get decent support in place and what has slowed me down is being busy on other things and also that my z/OS environment is z/PDT so it is an emulation - and it is very slow to work with.

I'll disagree with Tim on one point: if it's hard for you to transport your changes to the master branch, I think it's better that we get clean patches against whatever OpenSSL base line you use (1.1.0), and we can use git to transport the changes to whatever branch we see fit.
Of course, we do appreciate it if you turn of with PRs against master, should that be easy enough for you.

As a first step I will try to run the test suite. In the past that was a hopeless effort, but maybe it is easier with OpenSSL 1.1.0.

@dlegaultbbry: Thank you for the suggestion, but I'm afraid that -Wl,-znodelete is not a valid option for the z/OS compiler/linker.

@t-j-h: With a small change in the top-level Makefile I was able to run the test suite, and it reported about 40 failed tests of 504 tests executed. I did not find any log files to examine what actually went wrong. How can I find out why a test actually failed?
I will contact you by email how to proceed with the patches.

Top level Makefile? With 1.1.0, there is only one Makefile (top-level indeed)
Anyway, the method to get verbosity out of the tests is this: make test V=1
You can also select exactly what tests to run like this: make test V=1 TESTS='test_evp test_enc' (I hope it's obvious what those names correspond to)

Top level Makefile? With 1.1.0, there is only one Makefile (top-level indeed)

You're right. I was so used to the old build system that I hadn't realized up to now that this is the only Makefile left except for
./demos/bio/Makefile
./demos/evp/Makefile

I was so used to the old build system ...

Yup, gotcha.  I was wondering, for a moment, if there was a more serious mixup there.  Glad it was just a slip.

I've transformed the issue into a generic OpenSSL support for z/OS one. Of course it would need a community to support this - providing patches and so on.

Doesn't the work that @p-steuer did cover this? Or are there still things that don't work on z/OS?

@smuehlst Are there still any further issues to solve?

The original problem for which I opened this issue has been resolved (crashes with dynamic linking and atexit() handlers on z/OS).
We are currently using a version from the OpenSSL_1_1_1-stable branch which has some patches of us on top for fixing EBCDIC issues. We plan to switch to OpenSSL 3.0 in the future, but we haven't tried a 3.0 release candidate yet.
This will go along with the switch to a new compiler on z/OS. There is now an clang-based compiler for z/OS available from IBM which we will use for all future development. This will maybe make some things easier, but maybe there also will be new issues.
In the past I also gave up after a while when I tried to run the test suite, but this may have improved as well in the meantime.
@t8m: Are you interested in z/OS- and EBCDIC-related issues in the OpenSSL_1_1_1-stable branch, or is the focus on OpenSSL 3.0 now?
@mattcaswell: Regarding the work of @p-steuer I looked at his commits, and I have the impression that he worked on the port for Linux on z/Series machines, which does not involve any EBCDIC-specific code.

@t8m: Are you interested in z/OS- and EBCDIC-related issues in the OpenSSL_1_1_1-stable branch, or is the focus on OpenSSL 3.0 now?

Given the z/OS and EBCDIC is not really working without significant patches on 1.1.1 I do not think we want such changes there. And 3.0 release is imminent so any eventual changes probably won't be merged there. But that does not mean they cannot be merged after the release. So please test OpenSSL 3.0.

Given the z/OS and EBCDIC is not really working without significant patches on 1.1.1 I do not think we want such changes there. And 3.0 release is imminent so any eventual changes probably won't be merged there. But that does not mean they cannot be merged after the release. So please test OpenSSL 3.0.

Ok, we will test OpenSSL 3.0 then, but I can't yet estimate how soon that will happen.
I think this issue can be closed then, and I will open a new issue for OpenSSL 3.0 in the future.

authors: dlegaultbbry levitte mattcaswell smuehlst t-j-h t8m


text:
Send bad_record_mac instead of decryption_failed

The decryption failed alert was deprecated a long time ago. It can
provide an attacker too much information to be able to distinguish between
MAC failures and decryption failures and can lead to oracle attacks.
Instead we should always use the bad_record_mac alert for these issues.
This fixes one instance that still exists. It does not represent a
security issue in this case because it is only ever sent if the record is
publicly invalid, i.e. we have detected it is invalid without using any
secret material.

Pushed. Thanks.

source: gharchive/pull-request

repo: openssl/openssl

license_type: permissive

license_source: github-api


text:
Allow EVP_PKEY private key creation without a public component

Remove the conditional code which prevents a private key from being created without a public component. Also added a couple of tests.
Fixes #13506

[x] tests are added or updated

This pull request is ready to merge

This pull request is ready to merge

Merged to master as 2c04b34. Thank you for the contribution!

Merged to master as 2c04b34. Thank you for the contribution!

authors: jon-oracle openssl-machine t8m


text:
[1.0.2] Add missing error string for SSL_R_TOO_MANY_WARN_ALERTS

22646a0 left out the error string for SSL_R_TOO_MANY_WARN_ALERTS, this commit adds the 1.1.0 branches version of the error string.

+1.
ping @mattcaswell

+1

Pushed.

authors: mattcaswell richsalz x64architecture


text:
cmp_ctx.c: Remove redundancy form the defs of many getters and setters

This refactoring has been carved out from #17277.

This pull request is ready to merge

Typo : form -> from in commit message , no ?

Typo : form -> from in commit message , no ?

Ah, thanks, but already too late: commit is merged.

Merged. Thanks @paulidale for the approval and discussion.

authors: DDvO FdaSilvaYY openssl-machine


text:
Avoid crashing if CONF_modules_unload() is called after OPENSSL_cleanup()

Although this is basically an incorrect API call it was not crashing
before and it might happen inadvertently if CONF_modules_unload()
is called from a destructor for example.
Fixes #18669

Technically, we also might not have been initialised but I don't think that impacts the fix.

In that case the RUN_ONCE should return false.

@t8m   Can you please merge this if there is no other concern?  Thanks

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged to master and 3.0 branches. Thank you for your reviews.

authors: openssl-machine t8m yuqiangh


text:
Address session ownership

This commit resolves an issue with corruption of session cache lists. There is an undocumented invariant maintained by SSL_SESSION_list_add and SSL_SESSION_list_remove that either a session has an owner and is in the linked list of that owning session, or is not. However duplication did not clear the owner.
Timeout management added in https://github.com/openssl/openssl/pull/8687 uses the owner pointer to update the list order, however if the session is a copy of the one in the cache, this logic is incorrect and leads to corruption of the list structures. The solution is to ensure duplicates have owner unset.
I also took the liberty of updating the documentation while I was at it.
Checklist

[x] documentation is added or updated
[x] tests are added or updated

We will need CLA to be signed to be able to merge this PR. Could you please look at https://www.openssl.org/policies/cla.html

I sent a snail mail in a while ago let me try electronic this time

I've sent Tam an email with someone who should be the right current contact, so that should get sorted out soon.

Merged to master, 3.1, and 3.0 branches. Thank you for your contribution.


text:
Add FIPS build instructions

If you are building the latest release source code with enable-fips configured then the FIPS provider you are using is not likely to be FIPS compliant.
This update demonstrates how to build a FIPS provider that is compliant and use it with the latest source code.

Checklist

[X] documentation is added or updated
[ ] tests are added or updated

It seems that if someone configures with enable-fips then the non-FIPS-validated branches could issue a warning along the lines of "This build will only be FIPS-compliant if the FIPS module from the validated version (3.0.0) is used" (of course, people might just ignore such a warning)

It seems that if someone configures with enable-fips then the non-FIPS-validated branches could issue a warning along the lines of "This build will only be FIPS-compliant if the FIPS module from the validated version (3.0.0) is used" (of course, people might just ignore such a warning)

The problem is that the validation only occurs some time after the release of a particular version. So, 3.0.8 is currently going through validation - but isn't validated yet. But once a release is made we can't change any warning text in it....catch 22.

The problem is that the validation only occurs some time after the release of a particular version. So, 3.0.8 is currently going through validation - but isn't validated yet. But once a release is made we can't change any warning text in it....catch 22.

This isn't a perfect example, it is possible to use FIPS modules while they are going through the review process. I don't know what happens if they end up failing however.
A better example is 3.1.0.  We built this to be FIPS validated but it turns out it will be 3.1.1 because of CVEs inside the boundary.  If 3.1.0 had text saying it was valid (or vice-versa), it would need it retrofitted which is impossible.

// This still needs addressing....
You want be me add a comment?

Yes please.

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

Can we please get this one moving again?
The added documentation is genuinely useful and I've referenced this PR several times responding to questions.

The CI is relevant. Also I assume we want this documentation on all 3 branches. @paulidale ok with that?

Yes to multiple branches.

Looks like the quicapi tests are broken.

dgram_pair_ctrl() does not handle BIO_C_GET_FD

Merged to all three branches.  Glad that this is finally in.

authors: mattcaswell openssl-machine paulidale slontis t8m tom-cosgrove-arm


text:
Alternative fix for BIO_get_mem_ptr

Alternative to #8378 removing BIO_FLAGS_NONCLEAR_RST which did never work.
Checklist

[x] documentation is added or updated
[x] tests are added or updated

Hi @openssl/omc I think the fist commit is probably good to go.
But the second one is where things get hairy, because I see no way
how to fix BIO_FLAGS_NONCLEAR_RST.
Also BIO_get_mem_ptr seems to be incompatible with BIO_FLAGS_MEM_RDONLY
since it tries to memmove the data which is supposed to be read only.

In my opinion the correct fix for the BIO_FLAGS_MEM_RDONLY behavior is to just revert its functionality back to what it is in 1.0.2. The readp and buf could be made identical in MEM_RDONLY BIO so there should be no need to memmove anything, however the reset operation would need to be reverted back to 1.0.2 implementation for MEM_RDONLY . It should be also documented that before freeing the buf in case of the MEM_RDONLY BIO, the data must be set to NULL. What to do with BIO_FLAGS_NONCLEAR_RST is unclear to me however that should not block fixing the implementation to at least not regress from 1.0.2.

The 1.0.2 reset function does not work correctly if the read only MEM_BUF
was created using BUF_MEM_grow_clean and assigned using BIO_set_mem_buf
because that allocates 33% more memory than necessary,
thus max > length, but the code here assumed that max = length initially:
            if (b->flags & BIO_FLAGS_MEM_RDONLY) {
                bm->data -= bm->max - bm->length;
                bm->length = bm->max;


text:
Cleanup MAC

Two things are happening in this changeset:
Remove MAC cruft
A few declarations and static functions / arrays that are no longer
used were left behind when MACs moved to be implemented by providers.
Get rid of the diversity of names for MAC parameters
The EVP_PKEY MAC implementations had a diversity of controls that were
really the same thing.  We did reproduce that for the provider based
MACs, but are changing our minds on this.  Instead of that, we now use
one parameter name for passing the name of the underlying algorithm to
a MAC implementation, "algorithm", and one parameter name for passing
the output size of the MAC, "size".
Then we leave it to the EVP_PKEY->EVP_MAC bridge to translate "md",
"digest" and "cipher" to "algorithm", and "digestsize" to "size".

Reworked a bit following your remarks, @slontis.  I believe I addressed them all

I've changed the KDFs/PRFs draft to match this.

Cool, thanks!
Merged.
9f57e2184de330e83d0636586e88a8524c513b8e Remove MAC cruft
703170d4b9da1b3adc0e4d87719a5156080b2dca Get rid of the diversity of names for MAC parameters
f3b8d77f99c84e39c48599ad54366e806f3b9478 Update EVP_MAC.pod

authors: levitte paulidale


text:
Prefer VPAES over BSAES if both are supported

The performance is comparable but BSAES is not
completely constant time, there are table lookups
using secret key data in AES_set_encrypt/decrypt_key
and in the ctr mode short data uses the non-constant
time AES_encrypt function instead of bit-slicing.

FYI: I found those non-constant time codes by using this little hack:
diff --git a/apps/speed.c b/apps/speed.c
index d71b823..a9e8c5b 100644
--- a/apps/speed.c
+++ b/apps/speed.c
@@ -2736,6 +2736,7 @@ int speed_main(int argc, char **argv)
                     keylen = EVP_CIPHER_CTX_key_length(loopargs[k].ctx);
                     loopargs[k].key = app_malloc(keylen, "evp_cipher key");
                     EVP_CIPHER_CTX_rand_key(loopargs[k].ctx, loopargs[k].key);
+{int ii;for(ii=0;ii<keylen;ii++){volatile int xx;loopargs[k].key[ii]^=xx^xx;}}
                     if (!EVP_CipherInit_ex(loopargs[k].ctx, NULL, NULL,
                                            loopargs[k].key, NULL, -1)) {
                         BIO_printf(bio_err, "\nEVP_CipherInit_ex failure\n");

and valgrind apps/openssl speed -evp aes-128-ctr
==14017== Memcheck, a memory error detector
==14017== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14017== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==14017== Command: apps/openssl speed -evp aes-128-ctr
==14017==
Doing aes-128-ctr for 3s on 16 size blocks: ==14017== Use of uninitialised value of size 8
==14017==    at 0x4ADFB4: _x86_64_AES_set_encrypt_key (aes-x86_64.s:974)
==14017==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14017==    by 0x69D85C: cipher_hw_aes_initkey (cipher_aes_hw.c:76)
==14017==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14017==    by 0x441FFE: speed_main (speed.c:2740)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4ADFC1: _x86_64_AES_set_encrypt_key (aes-x86_64.s:979)
==14017==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14017==    by 0x69D85C: cipher_hw_aes_initkey (cipher_aes_hw.c:76)
==14017==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14017==    by 0x441FFE: speed_main (speed.c:2740)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4ADFCE: _x86_64_AES_set_encrypt_key (aes-x86_64.s:984)
==14017==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14017==    by 0x69D85C: cipher_hw_aes_initkey (cipher_aes_hw.c:76)
==14017==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14017==    by 0x441FFE: speed_main (speed.c:2740)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4ADFDB: _x86_64_AES_set_encrypt_key (aes-x86_64.s:989)
==14017==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14017==    by 0x69D85C: cipher_hw_aes_initkey (cipher_aes_hw.c:76)
==14017==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14017==    by 0x441FFE: speed_main (speed.c:2740)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD68F: _x86_64_AES_encrypt_compact (aes-x86_64.s:184)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD694: _x86_64_AES_encrypt_compact (aes-x86_64.s:185)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD699: _x86_64_AES_encrypt_compact (aes-x86_64.s:186)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD69E: _x86_64_AES_encrypt_compact (aes-x86_64.s:187)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD6A3: _x86_64_AES_encrypt_compact (aes-x86_64.s:189)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD6AB: _x86_64_AES_encrypt_compact (aes-x86_64.s:191)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD6B3: _x86_64_AES_encrypt_compact (aes-x86_64.s:193)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD6B8: _x86_64_AES_encrypt_compact (aes-x86_64.s:194)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD6DF: _x86_64_AES_encrypt_compact (aes-x86_64.s:206)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD6F3: _x86_64_AES_encrypt_compact (aes-x86_64.s:213)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD6FB: _x86_64_AES_encrypt_compact (aes-x86_64.s:215)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD717: _x86_64_AES_encrypt_compact (aes-x86_64.s:224)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD71C: _x86_64_AES_encrypt_compact (aes-x86_64.s:225)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD721: _x86_64_AES_encrypt_compact (aes-x86_64.s:226)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD726: _x86_64_AES_encrypt_compact (aes-x86_64.s:227)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)
==14017==
==14017== Use of uninitialised value of size 8
==14017==    at 0x4AD72B: _x86_64_AES_encrypt_compact (aes-x86_64.s:228)
==14017==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14017==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14017==    by 0x574FF6: CRYPTO_ctr128_encrypt_ctr32 (ctr128.c:184)
==14017==    by 0x6A169D: cipher_hw_generic_ctr (cipher_common_hw.c:115)
==14017==    by 0x6A0EAB: cipher_generic_stream_update (cipher_common.c:284)
==14017==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14017==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14017==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14017==    by 0x44206A: speed_main (speed.c:2754)
==14017==    by 0x41C5FC: do_cmd (openssl.c:479)
==14017==    by 0x406211: main (openssl.c:294)

and valgrind apps/openssl speed -evp aes-128-gcm
==14021== Memcheck, a memory error detector
==14021== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14021== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==14021== Command: apps/openssl speed -evp aes-128-gcm
==14021==
Doing aes-128-gcm for 3s on 16 size blocks: ==14021== Use of uninitialised value of size 8
==14021==    at 0x4ADFB4: _x86_64_AES_set_encrypt_key (aes-x86_64.s:974)
==14021==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14021==    by 0x6A2FAC: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4ADFC1: _x86_64_AES_set_encrypt_key (aes-x86_64.s:979)
==14021==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14021==    by 0x6A2FAC: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4ADFCE: _x86_64_AES_set_encrypt_key (aes-x86_64.s:984)
==14021==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14021==    by 0x6A2FAC: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4ADFDB: _x86_64_AES_set_encrypt_key (aes-x86_64.s:989)
==14021==    by 0x4ADF02: AES_set_encrypt_key (aes-x86_64.s:911)
==14021==    by 0x6A2FAC: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD68F: _x86_64_AES_encrypt_compact (aes-x86_64.s:184)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD694: _x86_64_AES_encrypt_compact (aes-x86_64.s:185)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD699: _x86_64_AES_encrypt_compact (aes-x86_64.s:186)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD69E: _x86_64_AES_encrypt_compact (aes-x86_64.s:187)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6A3: _x86_64_AES_encrypt_compact (aes-x86_64.s:189)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6AB: _x86_64_AES_encrypt_compact (aes-x86_64.s:191)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6B3: _x86_64_AES_encrypt_compact (aes-x86_64.s:193)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6B8: _x86_64_AES_encrypt_compact (aes-x86_64.s:194)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6DF: _x86_64_AES_encrypt_compact (aes-x86_64.s:206)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6F3: _x86_64_AES_encrypt_compact (aes-x86_64.s:213)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6FB: _x86_64_AES_encrypt_compact (aes-x86_64.s:215)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD717: _x86_64_AES_encrypt_compact (aes-x86_64.s:224)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD71C: _x86_64_AES_encrypt_compact (aes-x86_64.s:225)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD721: _x86_64_AES_encrypt_compact (aes-x86_64.s:226)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD726: _x86_64_AES_encrypt_compact (aes-x86_64.s:227)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD72B: _x86_64_AES_encrypt_compact (aes-x86_64.s:228)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x5751D8: CRYPTO_gcm128_init (gcm128.c:724)
==14021==    by 0x6A2FC0: generic_aes_gcm_initkey (cipher_gcm_hw.c:63)
==14021==    by 0x55031F: EVP_CipherInit_ex (evp_enc.c:321)
==14021==    by 0x441FFE: speed_main (speed.c:2740)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD68F: _x86_64_AES_encrypt_compact (aes-x86_64.s:184)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD694: _x86_64_AES_encrypt_compact (aes-x86_64.s:185)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD699: _x86_64_AES_encrypt_compact (aes-x86_64.s:186)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD69E: _x86_64_AES_encrypt_compact (aes-x86_64.s:187)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6A3: _x86_64_AES_encrypt_compact (aes-x86_64.s:189)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6AB: _x86_64_AES_encrypt_compact (aes-x86_64.s:191)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6B3: _x86_64_AES_encrypt_compact (aes-x86_64.s:193)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6B8: _x86_64_AES_encrypt_compact (aes-x86_64.s:194)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6DF: _x86_64_AES_encrypt_compact (aes-x86_64.s:206)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6F3: _x86_64_AES_encrypt_compact (aes-x86_64.s:213)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6FB: _x86_64_AES_encrypt_compact (aes-x86_64.s:215)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD717: _x86_64_AES_encrypt_compact (aes-x86_64.s:224)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD71C: _x86_64_AES_encrypt_compact (aes-x86_64.s:225)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD721: _x86_64_AES_encrypt_compact (aes-x86_64.s:226)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD726: _x86_64_AES_encrypt_compact (aes-x86_64.s:227)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD72B: _x86_64_AES_encrypt_compact (aes-x86_64.s:228)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x575710: CRYPTO_gcm128_setiv (gcm128.c:908)
==14021==    by 0x6A2F2F: gcm_setiv (cipher_gcm_hw.c:87)
==14021==    by 0x6A258B: gcm_cipher_internal (cipher_gcm.c:315)
==14021==    by 0x6A258B: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD68F: _x86_64_AES_encrypt_compact (aes-x86_64.s:184)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD694: _x86_64_AES_encrypt_compact (aes-x86_64.s:185)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD699: _x86_64_AES_encrypt_compact (aes-x86_64.s:186)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD69E: _x86_64_AES_encrypt_compact (aes-x86_64.s:187)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6A3: _x86_64_AES_encrypt_compact (aes-x86_64.s:189)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6AB: _x86_64_AES_encrypt_compact (aes-x86_64.s:191)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6B3: _x86_64_AES_encrypt_compact (aes-x86_64.s:193)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6B8: _x86_64_AES_encrypt_compact (aes-x86_64.s:194)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6DF: _x86_64_AES_encrypt_compact (aes-x86_64.s:206)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6F3: _x86_64_AES_encrypt_compact (aes-x86_64.s:213)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD6FB: _x86_64_AES_encrypt_compact (aes-x86_64.s:215)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD717: _x86_64_AES_encrypt_compact (aes-x86_64.s:224)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD71C: _x86_64_AES_encrypt_compact (aes-x86_64.s:225)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD721: _x86_64_AES_encrypt_compact (aes-x86_64.s:226)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD726: _x86_64_AES_encrypt_compact (aes-x86_64.s:227)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)
==14021==
==14021== Use of uninitialised value of size 8
==14021==    at 0x4AD72B: _x86_64_AES_encrypt_compact (aes-x86_64.s:228)
==14021==    by 0x4AD91A: AES_encrypt (aes-x86_64.s:387)
==14021==    by 0x61B56F: bsaes_ctr32_encrypt_blocks (bsaes-x86_64.s:1523)
==14021==    by 0x576665: CRYPTO_gcm128_encrypt_ctr32 (gcm128.c:1573)
==14021==    by 0x6A2D21: gcm_cipher_update (cipher_gcm_hw.c:116)
==14021==    by 0x6A23EA: gcm_cipher_internal (cipher_gcm.c:327)
==14021==    by 0x6A23EA: gcm_stream_update (cipher_gcm.c:226)
==14021==    by 0x54E694: EVP_EncryptUpdate (evp_enc.c:656)
==14021==    by 0x4399CD: EVP_Update_loop (speed.c:957)
==14021==    by 0x43A8D6: run_benchmark (speed.c:1314)
==14021==    by 0x44206A: speed_main (speed.c:2754)
==14021==    by 0x41C5FC: do_cmd (openssl.c:479)
==14021==    by 0x406211: main (openssl.c:294)

"uninitailized value" actually means "secret value used as array index"
or branch condition.

I believe this means bsaes-x86_64.pl is unreachable and can likely be dropped.
We made a change like this and dropped bsaes-x86_64.pl, but not before we first adapted vpaes-armv8.pl's (currently largely unreachable) "2x" optimization to vpaes-x86_64.pl, so the performance gap was smaller. I also have a vpaes-armv7.pl I've been chewing on, but the perf hit is non-trivial. ARMv7 does not appear to be very good at vector permutations. :-/

Yeah, no problem.  This should be back-ported to 1.1.1 at least.

Yeah, no problem. This should be back-ported to 1.1.1 at least.

Will that be a seperate PR?

Absolutely.

However currently I am not sure if we should simply drop the x86_64 bsaes and
the default assembler support altogether since the non-asm implementaion
outperforms the assembler by far see #9640, which would mean, only ARMv7
would remain using bsaes

However currently I am not sure if we should simply drop the x86_64 bsaes

I dont know either - is it always slower, or just slower on a particular machine?

It is 25% slower on AMD64 at least

It is 25% slower on AMD64 at least

It is 25% slower on AMD64 at least

So I dont know the history of this, but you would assume that the HW implementation was faster at some point otherwise why was it even added?

From the comments there it might have been faster than gcc-3 but
gcc-4.8 and newer outperforms it on 64bit by at least 25% that
repeats with AMD and with Intel I7.
It is even on 32bit still 10% slower.
You can try simply compare
OPENSSL_ia32cap=0:0 util/shlib_wrap.sh apps/openssl speed -evp aes-128-ctr
on a no-asm and normal build.
I would be interested in what you see on your systems.

Just running inside a VM on a mac pro (So this probably doesnt mean much)..
no-asm
Doing aes-128-ctr for 3s on 16 size blocks: 25979568 aes-128-ctr's in 2.97s
Doing aes-128-ctr for 3son a mac pro on 64 size blocks: 9510396 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 256 size blocks: 2741844 aes-128-ctr's in 2.98s
Doing aes-128-ctr for 3s on 1024 size blocks: 704374 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 8192 size blocks: 89182 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 16384 size blocks: 44877 aes-128-ctr's in 3.00s
version: 3.0.0-dev
built on: built on: Fri Aug 23 09:18:04 2019 UTC
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wall -O3 -Werror -DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wmissing-prototypes -Wstrict-prototypes -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr     139957.27k   203567.00k   235540.96k   241230.43k   243526.31k   245088.26k

Doing aes-128-ctr for 3s on 16 size blocks: 17082834 aes-128-ctr's in 2.98s
Doing aes-128-ctr for 3s on 64 size blocks: 5855172 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 256 size blocks: 1562397 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 1024 size blocks: 404918 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 8192 size blocks: 51080 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 16384 size blocks: 25621 aes-128-ctr's in 2.99s
version: 3.0.0-dev
built on: built on: Fri Aug 23 09:13:16 2019 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -Werror -DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wmissing-prototypes -Wstrict-prototypes -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr      91719.91k   125328.10k   133770.45k   138674.26k   139948.95k   140392.80k

Yes I see the same everywhere now. real hardware.
Probably not the one in the deutsche museum though, but that doesn't count.
I am not so good at percent, that means rather 40% right?

I am not sure which way to do the divide - either way its a significant difference.

I will probably close this PR in favor of removing bsaes eintirely,
maybe leave ARMv7 at the moment until @davidben comes up
with an vpaes assembler module.

Sounds good - probably needs approval from a few people..

@slontis, we have a problem.
The performance of current master dropped by 50% on AESNI-capable hardware.
Take #9675 as a reference, I don't have an idea what is wrong, but for that
the non-sse2 assembler support is probably not to blame. That must be
something different.  Any ideas?

So I did the following as root:
root@w-ed:/sys/devices/system/cpu# cd /sys/devices/system/cpu/cpu0/cpufreq
root@w-ed:/sys/devices/system/cpu/cpu0/cpufreq# echo userspace > scaling_governor
root@w-ed:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_min_freq > scaling_setspeed
root@w-ed:/sys/devices/system/cpu/cpu0/cpufreq# cd ../..
root@w-ed:/sys/devices/system/cpu# cd cpu1/cpufreq
root@w-ed:/sys/devices/system/cpu/cpu1/cpufreq# echo userspace > scaling_governor
root@w-ed:/sys/devices/system/cpu/cpu1/cpufreq# cat scaling_min_freq > scaling_setspeed
root@w-ed:/sys/devices/system/cpu/cpu1/cpufreq# cd ..
root@w-ed:/sys/devices/system/cpu/cpu1# cd ..
root@w-ed:/sys/devices/system/cpu# cd cpu2/cpufreq
root@w-ed:/sys/devices/system/cpu/cpu2/cpufreq# echo userspace > scaling_governor
root@w-ed:/sys/devices/system/cpu/cpu2/cpufreq# cat scaling_min_freq > scaling_setspeed
root@w-ed:/sys/devices/system/cpu/cpu2/cpufreq# cd ..
root@w-ed:/sys/devices/system/cpu/cpu2# cd ..
root@w-ed:/sys/devices/system/cpu# cd cpu3/cpufreq
root@w-ed:/sys/devices/system/cpu/cpu3/cpufreq# echo userspace > scaling_governor
root@w-ed:/sys/devices/system/cpu/cpu3/cpufreq# cat scaling_min_freq > scaling_setspeed
root@w-ed:/sys/devices/system/cpu/cpu3/cpufreq#

so I can get reproducible results:
Then I do build #9675 with ../openssl/config -g no-pic
$ apps/openssl speed -evp aes-128-ctr
Doing aes-128-ctr for 3s on 16 size blocks: 21770719 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 64 size blocks: 19044275 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 256 size blocks: 12385944 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 1024 size blocks: 4829416 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 8192 size blocks: 705071 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 16384 size blocks: 355344 aes-128-ctr's in 2.98s
OpenSSL 1.1.1d-dev  xx XXX xxxx
built on: Fri Aug 23 14:56:14 2019 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -pthread -m64 -Wa,--noexecstack -Wall -O3 -g -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr     116498.83k   406277.87k  1056933.89k  1648440.66k  1925313.88k  1953676.54k

and current master without any patch (also ../openssl/config -g no-pic):
$ apps/openssl speed -evp aes-128-ctr
Doing aes-128-ctr for 3s on 16 size blocks: 10249218 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 64 size blocks: 9628670 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 256 size blocks: 7449274 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 1024 size blocks: 3833326 aes-128-ctr's in 2.99s
Doing aes-128-ctr for 3s on 8192 size blocks: 678716 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 16384 size blocks: 347001 aes-128-ctr's in 3.00s
version: 3.0.0-dev
built on: built on: Fri Aug 23 14:59:53 2019 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -pthread -m64 -Wa,--noexecstack -Wall -O3 -g -DOPENSSL_USE_NODELETE -DL_ENDIAN -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr      54662.50k   205411.63k   635671.38k  1312818.00k  1853347.16k  1895088.13k

So there seems to be a constant rather big overhead per each cipher invocation.
I doubt that will be acceptable.

So there seems to be a constant rather big overhead per each cipher invocation.

I was expecting there to be some overhead (but not that much). It will need to be investigated.

Thanks Shane.
I will close this PR now in favour of #9675 and #9677

Hmm .. As an experiment can you change a single line in evp_enc.c and see what results you get.. (I know it was then comparable for me)
inside EVP_EncryptUpdate()
replace
blocksize = EVP_CIPHER_CTX_block_size(ctx);
with
blocksize = 1
@levitte - looks like all the indirection to just get a constant hurts quite a bit here..

That gives for me:
$ apps/openssl speed -evp aes-128-ctr
Doing aes-128-ctr for 3s on 16 size blocks: 24782276 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 64 size blocks: 21524363 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 256 size blocks: 13430276 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 1024 size blocks: 4969573 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 8192 size blocks: 708642 aes-128-ctr's in 3.00s
Doing aes-128-ctr for 3s on 16384 size blocks: 355901 aes-128-ctr's in 3.00s
version: 3.0.0-dev
built on: built on: Sat Aug 24 06:18:32 2019 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -pthread -m64 -Wa,--noexecstack -Wall -O3 -g -DOPENSSL_USE_NODELETE -DL_ENDIAN -DNDEBUG -DOPENSSL_IA32_SSE2
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr     132172.14k   459186.41k  1146050.22k  1696280.92k  1935065.09k  1943693.99k

even a bit more than 1.1.1 yesterday.

authors: bernd-edlinger davidben slontis


text:
Ensure we install tmux

tmux is a widely used software, and usually we install it manually as
soon as we jump on a host. It was included only on controller-0, but we
also use it from the hypervisor directly.
Let's make that software available anywhere.
As a pull request owner and reviewers, I checked that:

[X] Appropriate testing is done and actually running

/lgtm

authors: cjeanner pablintino


text:
Test suite refactorings to catch up with docs

(description in individual commit messages)
Closes: #65

recheck

recheck -- failed at "check that Keystone is reachable and its endpoints are defined" which previously already worked

recheck

Green! Marking ready for review. FYI @booxter i renamed OVN-related env vars to keep consistency with the recently renamed vars elsewhere, but there shouldn't be a functional change.


text:
Requeue when TLS secret isn't found

closes OSPRH-7090

/cherrypick 18.0.0-proposed


text:
[OSPRH-11692] node_exporter scrapeconfig must include full fqdn instead

of hostname
This creates a ScrapeConfig.staticConfigs section like this
staticConfigs:
  - labels:
      fqdn: edpm-compute-0.ctlplane.example.com
    targets:
    - 192.168.122.100:9100
  - labels:
      fqdn: edpm-compute-1.ctlplane.example.com
    targets:
    - 192.168.122.101:9100

/lgtm

/cherry-pick 18.0-fr1

/cherry-pick 18.0-fr1

authors: jlarriba vyzigold


text:
added marker for access permissive

fixes #77

I don't know what access=permissive means and what should the icon look like. I made this PR that shows what should be changed to add separate icon. If someone wants to continue working on that then fell free to do so.
Note translation would also probably need to be updated in public/locales/en/translation.json

license: MIT


text:
Unable to Unlock tasks.

After finishing a tile it won't unlock. Going back to the tile, images have been doubled or tripled. Fixing them, then going back to the Tasking Manager, the tile still won't unlock. Many tries and waiting for the server (waiting 60 to 120 seconds), still won't unlock.
Internet speed is fast.
OS 10.6.8 Firefox MacBook Pro
http://tasks.hotosm.org/project/689#task/65

iD doesn't have any integration with the HOTOSM task manager to lock or unlock tasks, so the issue you are seeing is between your computer and the task manager.  You could try opening this issue with the task manager project here.
If when unlocking a task you need to wait 60-120 seconds for a response from their server, I'm afraid there is something wrong with your internet connection.  Troubleshooting issues like this is really tricky because it can be anything from a bad cable at your ISP to malware on your computer.

Thank you for responding. I must have incorrectly described. The wait time
was something I tried, but it didn't work. I pinged my Internet connection
and it's exceptionly fast. Thanks again.
Suzan
On June 1, 2015 7:54:11 AM Bryan Housel notifications@github.com wrote:

iD doesn't have any integration with the HOTOSM task manager to lock or
unlock tasks, so the issue you are seeing is between your computer and the
task manager.  You could try opening this issue with the task manager
project here.
If when unlocking a task you need to wait 60-120 seconds for a response
from their server, I'm afraid there is something wrong with your internet
connection.  Troubleshooting issues like this is really tricky because it
can be anything from a bad cable at your ISP to malware on your computer.

Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/iD/issues/2666#issuecomment-107546211

source: gharchive/issue

authors: SuzanReed bhousel

repo: openstreetmap/iD

license: ISC


text:
I get ground twice for autocomplete surface

Location: http://preview.ideditor.com/master/#background=Berlin-2018&disable_features=boundaries&map=18.21/52.61924/13.35056
Screenshot:

Me too.. Taginfo is returning 2 and I have no idea why..

https://taginfo.openstreetmap.org/keys/surface#values
results as JSON

Looks like a data issue. See http://overpass-turbo.eu/s/HlP

I am now running https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/elimination_of_nonprintable_characters_at_start_or_end_of_tags

Taginfo updated, and this problem is now fixed. Feel free to ping me in case of similar cases.

authors: bhousel matkoniecz tordans


text:
car_repair overwrites building tag

If I select a building and choose the preset for "Autowerkstatt" (car repair), ID tags the building with shop=car_repair (correct) but it also overwrites any present building= key with building=yes. This should not happen.

This is intended behavior, see #4315 :(

Then the intentions are wrong. An OSM editor should never silently remove information from the database without the user's consent. And it doesn't really matter if the user is "supposed to" use presets like that.

Hi folks, this is actually a really tricky issue. #4315 is several years old. See #7221 for newer details on this, but I'll elaborate again here.
When you switch presets in iD, you're saying "this feature isn't an instance of Preset A, it's instead an instance of Preset B". So iD naturally removes all the tags defining Preset A, otherwise you'd have old tags piling up every time you switch presets. So when you switch from say, Church Building to Cafe, you're saying "this isn't a Church Building". iD removes the information you asked it to remove—it's not silently removing anything.
The problem is that buildings are special in OSM. You can say "this is a Church Building, but it is also a Cafe" (which arguably violates the "one feature one element" principle). When you're using the preset switcher in iD, you might have it in your head that you just want to add the Cafe, but you're in fact swapping out the Church Building like any other preset.
While we could theoretically make the switcher work differently for these cases, I contend that inconsistency would be confusing for many mappers. There's a good chance the feature was never a Church Building in the first place. If the preset change is simply a correction, then retaining the building value would be wrong.

As you point out yourself, buildings and POIs are independent of each other in OSM. I do understand that you want consistency in how ID behaves when you select a preset. In my opinion the solution should be that building presets and POI presets should behave independently from each other. This means that the car repair preset should not contain a building tag ans building presets should only contain building-related tags, no POI tags.
So the workflow for a church would be to first select the church preset and then select the place of worship preset or the cafe preset, depending on what the church building is used for.
What do you think?

Apart from that I think that ID should always give a message when a preset overwrites existing tags, like Vespucci does for example.

While we could theoretically make the switcher work differently for these cases, I contend that inconsistency would be confusing for many mappers. There's a good chance the feature was never a Church Building in the first place. If the preset change is simply a correction, then retaining the building value would be wrong.

Note that it already works specially by deleting detailed building tag but keeping building=yes.
Maybe a good idea would be to keep detailed building value but display in the left menu "this object is still tagged as church building" with buttons "this is correct" and "change to unspecific building type"?

Or have popup asking for that decision but it would be likely to annoying (or maybe not? How often it is done? Probably not many times in row)

A good solution would be not to connect the POI with the building.

A good solution would be not to connect the POI with the building.

This is common mapping practice supported by wiki documentation and nothing we can change in this issue.

Any progress here? With the current behavior iD is slowly degrading OSM's data quality.

A similar issue arises when shops mapped as a room within a larger building are changed. ID incorrectly adds a building=yes tag.

@Discostu36 It looks like this issue has been fixed.


text:
iD damages relations when splitting ways

My System
Windows 10, 64 Bit
Firefox 89.0.2, 64 Bit
MS Edge 91.0.864.67, 64 Bit
iD 2.19.6
Description
Splitting ways that are members of relations destroys the order of the members. See also Order matters.
Steps to Reproduce
Starting point
The Rabenfeldstraße  is, among other things, part of the Relation Weingarten-Tour. It has 58 members:

Change
The "Rabenfeldstraße" is split with the scissors:

Actual Result
As expected, the relation Weingarten-Tour has 59 members afterwards, but the order is destroyed:

The effect is not always reproducible. On the "Panorama Tour (Eibiswald)" it no longer occurred the third time I wanted to take screenshots. With the "Weingarten Tour" I took the screenshots on the first repetition.
Of course, I did not save the changes.
Expected Result
Unchanged order of members as done by JOSM.
Other, possibly relevant issues
https://github.com/openstreetmap/iD/issues/4978
https://github.com/openstreetmap/iD/issues/4876
https://github.com/openstreetmap/iD/issues/4861
PLEASE
Do not allow splitting of ways that are part of a relation as long as the issue is unresolved.

Yes, I paid attention to which parts were downloaded.

Test case 2: Before splitting members manually NOT downloaded - order damaged
Test case 3: Before splitting members manually NOT downloaded - order ok

There seems to be no direct correlation with the issue.

Sorry for the confusion. In this post

Yes, I paid attention to which parts were downloaded.
* Test case 2: Before splitting members manually NOT downloaded - order damaged

* Test case 3: Before splitting members manually NOT downloaded - order ok

There seems to be no direct correlation with the issue.

Test cases related to the last test "Test Weingarten Tour, today" of 7 Oct. 21. iD version was 2.20.1, tests were completed within 1 hour.

By the way, you may find it more convenient to test iD without uploading your changes to the live OSM server: click the “Download osmChange file” link at the bottom of the upload screen, then manually inspect the file’s list of relation member IDs to see if the order is correct. One side of the split will have a negative value, and the other should be adjacent to it in the list.

Addendum for completeness
This issue was the subject of a discussion on OSMF-Talk.
A discussion about 23 mails ensued. A short summary can be found here.

To bring here the information the OP supplied in the local forum: The case "Weingartentour" seems to be fixed with the new release, only the case "Panorama Tour" remains wanting - I guess that is this one https://www.openstreetmap.org/relation/3132692 ?
The Panorama route looks quite simple, one complete round, no spurs. Searching for differences - it goes thtough a roundabout, that is mapped in much detail - https://www.openstreetmap.org/relation/3132692#map=19/46.68934/15.24868 - Tough to sort, quite close to the Rabenfeldstraße https://www.openstreetmap.org/way/962203250 too.
PS: What is completeness meant to say?

I use ID mostly for my edits and if I edit and an existing multipolygon (...Node Line Node Line Node Line Node Line Node...) and remove the center node in the multi polygon there is now a hole in the multiploygon.  Save. When I save I get no errors that the multipolygon is now (broken). No warning no errors are being displayed.

To recreate this
select a large recently unchanged  multipolygon.
create three new nodes in a line
cut middle one
delete it.
Save the data.

@natfoot I guess, what you describe is worth an issue of its own. This here is only about sorting the order of relation members, not about them providing closed ways.
BTW: your example matches the label bug much more than this one.

Just stumbled into this issue with https://www.openstreetmap.org/changeset/126323215 by splitting a simple way - fixed the damage in JOSM afterwards. Didn't happen on the split of another way, so this looks like the new ordering is just determined by a coin toss and not by considering the original order ;-)
Never had this problem when splitting ways in JOSM, just saying...

Just stumbled into this issue with https://www.openstreetmap.org/changeset/126323215 by splitting a simple way

This is related to the roundabout case discussed above in that this route relation is nonlinear: it includes all of this way but also this way that intersects it midway. If this way had been split and the route were continuous, I suspect the split you performed would’ve worked without any problems. In fact, if the relation had been poorly sorted beforehand, iD would’ve fixed the sorting. The reason JOSM doesn’t have this problem is that it doesn’t automatically sort relation members in the same manner.
/ref https://github.com/openstreetmap/iD/issues/8578#issuecomment-937484354

Just stumbled into this issue with https://www.openstreetmap.org/changeset/126323215 by splitting a simple way

This is related to the roundabout case discussed above in that this route relation is nonlinear: it includes all of this roadway but also this pathway that intersects it midway. If this roadway had been split and the route were continuous,

that split broke 3 MTB relations, I can't be sure they were ok before the split, but all 3 of them already broken/non-continuous? I don't know... And the fix in JOSM was to shuffle up a couple of ways "left" of the split, that intersection you pointed out had nothing to do with it.
Be that as it may - I know from my own experience that relation sorting is tricky. I was unsuccessfully trying to do my own resort implementation for my via ferrata and cross country skiing trails map site elevation profiles for a long time and eventually gave up. But that was only for a data consumer. If a resorting approach is known to break properly sorted relations (even only in edge cases) in the actual data, I'd make that an option (with a possibility to visually verify) and not a default.
I frequently observe broken relations for the ferrata and cross country skiing trail relations I keep an eye on, that iD behavior could be an explanation.

And the fix in JOSM was to shuffle up a couple of ways "left" of the split, that intersection you pointed out had nothing to do with it.

The sorting code operates on the whole relation without assuming that any members were previously sorted, so it’s possible for a loop or backtrack to affect members far away. MTB Prinzenweg-Rundtour and MTB Alpbachtal Rundtour both have a loop (a very large one) along with a “tail”, so splitting anything along either relation would definitely trigger #4876. I can’t explain MTB Almtour though – I was under the impression that this issue doesn’t affect routes that only consist of a loop. Maybe it affects them too, maybe nondeterministically as https://github.com/openstreetmap/iD/issues/8578#issuecomment-938178678 discovered.

If a resorting approach is known to break properly sorted relations (even only in edge cases) in the actual data, I'd make that an option (with a possibility to visually verify) and not a default.

At a minimum, disabling the automatic resorting by default would require a more robust UI for ordering relations manually. But I think it would probably uncover a lot of other issues that would be even more commonplace than this loop issue. If I remember correctly, automatic resorting was implemented in response to a lot of feedback that iD was mangling member order of perfectly linear relations, so those latent issues would need to be addressed at the same time.
As far as I can tell, the loop/discontinuity issue raised here so far doesn’t appear to be a fundamentally intractable shortcoming of the automatic resorting approach. Rather, it’s an edge case that wasn’t addressed originally, essentially a to-do item as I mentioned in https://github.com/openstreetmap/iD/issues/8578#issuecomment-937484354. Unfortunately, it has been tripping up certain kinds of route relations more frequently than originally expected.
It is possible, though not particularly convenient, to visually verify the order before saving: with the relation selected, hover the cursor over each member in the list. As you hover over each member, iD highlights it on the map. Verify that the members are highlighted in the order that you expect.

See also the issue #8415

authors: 1ec5 Mahabarata arminus hungerburg natfoot robhubi


text:
feat: 新增 websocket 鉴权机制

Types

[x] 🎉 New Features

Background or solution
fix: #1222
之后鉴权方式：
前端：
new ClientApp({
  connectionPath: async () => {
       return `${wsPath}/service?token=${await getAuthToken()}`;
  }
})

后端
new ServerApp({
   wsServerOptions: {
       verifyClient: (info, done) => {
           const url = URL.parse(info.req.url, true);
           const { query } = url;
           if (!query.token) {
             done(false);
           }
           // 在这里实现鉴权逻辑
           const authed = await ctx.service.cloudideWsGateway.verifyAuthToken(query.token);
           done(authed);
        }
   }
})

Changelog
新增 websocket 鉴权机制

有一个问题，对于每个 ws 消息都做鉴权，目前对于通信的速度影响情况有测试过吗？

这个只是在连接 open 的时候鉴权，我们这边之前用的都是 issue 里 hack 的方式

补点测试吧 ~

补点测试吧 ~

加了

repo: opensumi/core