summaryrefslogtreecommitdiffstats
path: root/crypto/aes
AgeCommit message (Collapse)Author
2020-05-27Avoid undefined behavior with unaligned accessesBernd Edlinger
Fixes: #4983 [extended tests] Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/6074)
2020-04-23Update copyright yearMatt Caswell
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11616)
2020-04-16Use build.info, not ifdef for crypto modulesRich Salz
Don't wrap conditionally-compiled files in global ifndef tests. Instead, test if the feature is disabled and, if so, do not compile it. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11263)
2020-03-05aes-s390x.pl: fix stg offset caused by typo in perlasmPatrick Steuer
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11234)
2020-02-18x86_64: Don't assume 8-byte pointer sizeH.J. Lu
Since pointer in x32 is 4 bytes, add x86_64-support.pl to define pointer_size and pointer_register based on flavour to support stuctures like: struct { void *ptr; int blocks; } This fixes 90-test_sslapi.t on x32. Verified with $ ./Configure shared linux-x86_64 $ make $ make test and $ ./Configure shared linux-x32 $ make $ make test Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10988)
2020-02-17Also check for errors in x86_64-xlate.pl.David Benjamin
In https://github.com/openssl/openssl/pull/10883, I'd meant to exclude the perlasm drivers since they aren't opening pipes and do not particularly need it, but I only noticed x86_64-xlate.pl, so arm-xlate.pl and ppc-xlate.pl got the change. That seems to have been fine, so be consistent and also apply the change to x86_64-xlate.pl. Checking for errors is generally a good idea. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: David Benjamin <davidben@google.com> (Merged from https://github.com/openssl/openssl/pull/10930)
2020-02-17Fix a bug for aarch64 BigEndiansimplelins
FIXES #10692 #10638 a bug for aarch64 bigendian with instructions 'st1' and 'ld1' on AES-GCM mode. CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10751)
2020-02-15x86_64: Add endbranch at function entries for Intel CETH.J. Lu
To support Intel CET, all indirect branch targets must start with endbranch. Here is a patch to add endbranch to function entries in x86_64 assembly codes which are indirect branch targets as discovered by running openssl testsuite on Intel CET machine and visual inspection. Verified with $ CC="gcc -Wl,-z,cet-report=error" ./Configure shared linux-x86_64 -fcf-protection $ make $ make test and $ CC="gcc -mx32 -Wl,-z,cet-report=error" ./Configure shared linux-x32 -fcf-protection $ make $ make test # <<< passed with https://github.com/openssl/openssl/pull/10988 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10982)
2020-02-06Fix misspelling errors and typos reported by codespellDr. Matthias St. Pierre
Fixes #10998 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11000)
2020-01-22Do not silently truncate files on perlasm errorsDavid Benjamin
If one of the perlasm xlate drivers crashes, OpenSSL's build will currently swallow the error and silently truncate the output to however far the driver got. This will hopefully fail to build, but better to check such things. Handle this by checking for errors when closing STDOUT (which is a pipe to the xlate driver). Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10883)
2020-01-17For all assembler scripts where it matters, recognise clang > 9.xRichard Levitte
Fixes #10853 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/10855)
2020-01-06Deprecate the low level AES functionsMatt Caswell
Use of the low level AES functions has been informally discouraged for a long time. We now formally deprecate them. Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex, EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt functions. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10580)
2020-01-06Add AES_CBC_HMAC_SHA ciphers to providers.Shane Lontis
Also Add ability for providers to dynamically exclude cipher algorithms. Cipher algorithms are only returned from providers if their capable() method is either NULL, or the method returns 1. This is mainly required for ciphers that only have hardware implementations. If there is no hardware support, then the algorithm needs to be not available. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10146)
2019-12-23Fix aesni_cbc_sha256_enc_avx2 backtrace infoBernd Edlinger
We store a secondary frame pointer info for the debugger in the red zone. This fixes a crash in the unwinder when this function is interrupted. Additionally the missing cfi function annotation is added to aesni_cbc_sha256_enc_shaext. [extended tests] Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10674)
2019-12-20Add some missing cfi frame info in aesni-sha and sha-x86_64.plBernd Edlinger
Reviewed-by: Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/10655)
2019-12-20Add some missing cfi frame info in aesni-x86_64.plBernd Edlinger
Reviewed-by: Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/10653)
2019-12-20Add some missing cfi frame info in aes-x86_64.plBernd Edlinger
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/10650)
2019-12-11Fix some typosVeres Lajos
Reported-by: misspell-fixer <https://github.com/vlajos/misspell-fixer> CLA: trivial Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10544)
2019-12-11Optimize AES-ECB mode in OpenSSL for both aarch64 and aarch32XiaokangQian
Aes-ecb mode can be optimized by inverleaving cipher operation on several blocks and loop unrolling. Interleaving needs one ideal unrolling factor, here we adopt the same factor with aes-cbc, which is described as below: If blocks number > 5, select 5 blocks as one iteration,every loop, decrease the blocks number by 5. If 3 < left blocks < 5 select 3 blocks as one iteration, every loop, decrease the block number by 3. If left blocks < 3, treat them as tail blocks. Detailed implementation will have a little adjustment for squeezing code space. With this way, for small size such as 16 bytes, the performance is similar as before, but for big size such as 16k bytes, the performance improves a lot, even reaches to 100%, for some arches such as A57, the improvement even exceeds 100%. The following table will list the encryption performance data on aarch64, take a72 and a57 as examples. Performance value takes the unit of cycles per byte, takes the format as comparision of values. List them as below: A72: Before optimization After optimization Improve evp-aes-128-ecb@16 17.26538237 16.82663866 2.61% evp-aes-128-ecb@64 5.50528499 5.222637557 5.41% evp-aes-128-ecb@256 2.632700213 1.908442892 37.95% evp-aes-128-ecb@1024 1.876102047 1.078018868 74.03% evp-aes-128-ecb@8192 1.6550392 0.853982929 93.80% evp-aes-128-ecb@16384 1.636871283 0.847623957 93.11% evp-aes-192-ecb@16 17.73104961 17.09692468 3.71% evp-aes-192-ecb@64 5.78984398 5.418545192 6.85% evp-aes-192-ecb@256 2.872005308 2.081815274 37.96% evp-aes-192-ecb@1024 2.083226672 1.25095642 66.53% evp-aes-192-ecb@8192 1.831992057 0.995916251 83.95% evp-aes-192-ecb@16384 1.821590009 0.993820525 83.29% evp-aes-256-ecb@16 18.0606306 17.96963317 0.51% evp-aes-256-ecb@64 6.19651997 5.762465812 7.53% evp-aes-256-ecb@256 3.176991394 2.24642538 41.42% evp-aes-256-ecb@1024 2.385991919 1.396018192 70.91% evp-aes-256-ecb@8192 2.147862636 1.142222597 88.04% evp-aes-256-ecb@16384 2.131361787 1.135944617 87.63% A57: Before optimization After optimization Improve evp-aes-128-ecb@16 18.61045121 18.36456218 1.34% evp-aes-128-ecb@64 6.438628994 5.467959461 17.75% evp-aes-128-ecb@256 2.957452881 1.97238604 49.94% evp-aes-128-ecb@1024 2.117096219 1.099665054 92.52% evp-aes-128-ecb@8192 1.868385973 0.837440804 123.11% evp-aes-128-ecb@16384 1.853078526 0.822420027 125.32% evp-aes-192-ecb@16 19.07021756 18.50018552 3.08% evp-aes-192-ecb@64 6.672351486 5.696088921 17.14% evp-aes-192-ecb@256 3.260427769 2.131449916 52.97% evp-aes-192-ecb@1024 2.410522832 1.250529718 92.76% evp-aes-192-ecb@8192 2.17921605 0.973225504 123.92% evp-aes-192-ecb@16384 2.162250997 0.95919871 125.42% evp-aes-256-ecb@16 19.3008384 19.12743654 0.91% evp-aes-256-ecb@64 6.992950658 5.92149541 18.09% evp-aes-256-ecb@256 3.576361743 2.287619504 56.34% evp-aes-256-ecb@1024 2.726671027 1.381267599 97.40% evp-aes-256-ecb@8192 2.493583657 1.110959913 124.45% evp-aes-256-ecb@16384 2.473916816 1.099967073 124.91% Change-Id: Iccd23d972e0d52d22dc093f4c208f69c9d5a0ca7 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10518)
2019-11-07Update source files for deprecation at 3.0Richard Levitte
Previous macros suggested that from 3.0, we're only allowed to deprecate things at a major version. However, there's no policy stating this, but there is for removal, saying that to remove something, it must have been deprecated for 5 years, and that removal can only happen at a major version. Meanwhile, the semantic versioning rule is that deprecation should trigger a MINOR version update, which is reflected in the macro names as of this change. Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10364)
2019-10-16Fix missing Assembler definesShane Lontis
Implementations are now spread across several libraries, so the assembler related defines need to be applied to all affected libraries and modules. AES_ASM define was missing from libimplementations.a which disabled AESNI aarch64 changes were made by xkqian. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10180)
2019-10-10Rework how our providers are builtRichard Levitte
We put almost everything in these internal static libraries: libcommon Block building code that can be used by all our implementations, legacy and non-legacy alike. libimplementations All non-legacy algorithm implementations and only them. All the code that ends up here is agnostic to the definitions of FIPS_MODE. liblegacy All legacy implementations. libnonfips Support code for the algorithm implementations. Built with FIPS_MODE undefined. Any code that checks that FIPS_MODE isn't defined must end up in this library. libfips Support code for the algorithm implementations. Built with FIPS_MODE defined. Any code that checks that FIPS_MODE is defined must end up in this library. The FIPS provider module is built from providers/fips/*.c and linked with libimplementations, libcommon and libfips. The Legacy provider module is built from providers/legacy/*.c and linked with liblegacy, libcommon and libcrypto. If module building is disabled, the object files from liblegacy and libcommon are added to libcrypto and the Legacy provider becomes a built-in provider. The Default provider module is built-in, so it ends up being linked with libimplementations, libcommon and libnonfips. For libcrypto in form of static library, the object files from those other libraries are simply being added to libcrypto. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10088)
2019-09-28Fix header file include guard namesDr. Matthias St. Pierre
Make the include guards consistent by renaming them systematically according to the naming conventions below For the public header files (in the 'include/openssl' directory), the guard names try to match the path specified in the include directives, with all letters converted to upper case and '/' and '.' replaced by '_'. For the private header files files, an extra 'OSSL_' is added as prefix. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
2019-09-28Reorganize local header filesDr. Matthias St. Pierre
Apart from public and internal header files, there is a third type called local header files, which are located next to source files in the source directory. Currently, they have different suffixes like '*_lcl.h', '*_local.h', or '*_int.h' This commit changes the different suffixes to '*_local.h' uniformly. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
2019-09-16Unify all assembler file generatorsRichard Levitte
They now generally conform to the following argument sequence: script.pl "$(PERLASM_SCHEME)" [ C preprocessor arguments ... ] \ $(PROCESSOR) <output file> However, in the spirit of being able to use these scripts manually, they also allow for no argument, or for only the flavour, or for only the output file. This is done by only using the last argument as output file if it's a file (it has an extension), and only using the first argument as flavour if it isn't a file (it doesn't have an extension). While we're at it, we make all $xlate calls the same, i.e. the $output argument is always quoted, and we always die on error when trying to start $xlate. There's a perl lesson in this, regarding operator priority... This will always succeed, even when it fails: open FOO, "something" || die "ERR: $!"; The reason is that '||' has higher priority than list operators (a function is essentially a list operator and gobbles up everything following it that isn't lower priority), and since a non-empty string is always true, so that ends up being exactly the same as: open FOO, "something"; This, however, will fail if "something" can't be opened: open FOO, "something" or die "ERR: $!"; The reason is that 'or' has lower priority that list operators, i.e. it's performed after the 'open' call. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9884)
2019-09-16build.info: For all assembler generators, remove all argumentsRichard Levitte
Since the arguments are now generated in the build file templates, they should be removed from the build.info files. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9884)
2019-07-02Fix TyposAntoine Cœur
CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/9288)
2019-06-18crypto/aes/build.info: Fix AES assembler specsRichard Levitte
Two mistakes were made: 1. AES_ASM for x86 was misplaced 2. sse2 isn't applicable for x86_64 code Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9177)
2019-06-17Move aes_asm_src file information to build.info filesRichard Levitte
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9166)
2019-06-15Use variables in build.info files where it's worth the whileRichard Levitte
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9144)
2019-06-03Make basic AES ciphers available from within the FIPS providersMatt Caswell
These ciphers were already provider aware, and were available from the default provider. We move them into the FIPS provider too. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9038)
2019-05-20Revert "ppc assembly pack: always increment CTR IV as quadword"Pauli
The 32 bit counter behaviour is necessary and was intentional. This reverts commit e9f148c9356b18995298f37bafbf1836a3fce078. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8958)
2019-05-17ppc assembly pack: always increment CTR IV as quadwordDaniel Axtens
The kernel self-tests picked up an issue with CTR mode. The issue was detected with a test vector with an IV of FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD: after 3 increments it should wrap around to 0. There are two paths that increment IVs: the bulk (8 at a time) path, and the individual path which is used when there are fewer than 8 AES blocks to process. In the bulk path, the IV is incremented with vadduqm: "Vector Add Unsigned Quadword Modulo", which does 128-bit addition. In the individual path, however, the IV is incremented with vadduwm: "Vector Add Unsigned Word Modulo", which instead does 4 32-bit additions. Thus the IV would instead become FFFFFFFFFFFFFFFFFFFFFFFF00000000, throwing off the result. Use vadduqm. This was probably a typo originally, what with q and w being adjacent. CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8942)
2019-04-17aes/asm/aesv8-armx.pl: ~20% improvement on ThunderX2.Andy Polyakov
Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8776)
2019-04-17ARM64 assembly pack: add ThunderX2 results.Andy Polyakov
Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8776)
2019-04-12Deprecate AES_ige_encrypt() and AES_bi_ige_encrypt()Matt Caswell
These undocumented functions were never integrated into the EVP layer and implement the AES Infinite Garble Extension (IGE) mode and AES Bi-directional IGE mode. These modes were never formally standardised and usage of these functions is believed to be very small. In particular AES_bi_ige_encrypt() has a known bug. It accepts 2 AES keys, but only one is ever used. The security implications are believed to be minimal, but this issue was never fixed for backwards compatibility reasons. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8710)
2019-03-18PPC assembly pack: fix copy-paste error in CTR modeDaniel Axtens
There are two copy-paste errors in handling CTR mode. When dealing with a 2 or 3 block tail, the code branches to the CBC decryption exit path, rather than to the CTR exit path. This can lead to data corruption: in the Linux kernel we have a copy of this file, and the bug leads to corruption of the IV, which leads to data corruption when we call the encryption function again later to encrypt subsequent blocks. Originally reported to the Linux kernel by Ondrej Mosnáček <omosnacek@gmail.com> CLA: trivial Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8510)
2019-02-20MIPS32R3 provides the EXT instruction to extract bits fromMarkus Stockhausen
registers. As the AES table is already 1K aligned we can use it everywhere and speedup table address calculation by 10%. Performance numbers: decryption 16B 64B 256B 1024B 8192B ------------------------------------------------------------------- aes-256-cbc 5636.84k 6443.26k 6689.02k 6752.94k 6766.59k bef. aes-256-cbc 6200.31k 7195.71k 7504.30k 7585.11k 7599.45k aft. ------------------------------------------------------------------- aes-128-cbc 7313.85k 8653.67k 9079.55k 9188.35k 9205.08k bef. aes-128-cbc 7925.38k 9557.99k 10092.37k 10232.15k 10272.77k aft. encryption 16B 64B 256B 1024B 8192B ------------------------------------------------------------------- aes-256 cbc 6009.65k 6592.70k 6766.59k 6806.87k 6815.74k bef. aes-256 cbc 6643.93k 7388.69k 7605.33k 7657.81k 7675.90k aft. ------------------------------------------------------------------- aes-128 cbc 7862.09k 8892.48k 9214.04k 9291.78k 9311.57k bef. aes-128 cbc 8639.29k 9881.17k 10265.86k 10363.56k 10392.92k aft. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8206)
2019-02-17Fix some CFI issues in x86_64 assemblyDavid Benjamin
The add/double shortcut in ecp_nistz256-x86_64.pl left one instruction point that did not unwind, and the "slow" path in AES_cbc_encrypt was not annotated correctly. For the latter, add .cfi_{remember,restore}_state support to perlasm. Next, fill in a bunch of functions that are missing no-op .cfi_startproc and .cfi_endproc blocks. libunwind cannot unwind those stack frames otherwise. Finally, work around a bug in libunwind by not encoding rflags. (rflags isn't a callee-saved register, so there's not much need to annotate it anyway.) These were found as part of ABI testing work in BoringSSL. Reviewed-by: Richard Levitte <levitte@openssl.org> GH: #8109
2019-02-16ARM64 assembly pack: make it Windows-friendly.Andy Polyakov
"Windows friendliness" means a) unified PIC-ification, unified across all platforms; b) unified commantary delimiter; c) explicit ldur/stur, as Visual Studio assembler can't automatically encode ldr/str as ldur/stur when needed. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8256)
2019-02-16ARM assembly pack: make it Windows-friendly.Andy Polyakov
"Windows friendliness" means a) flipping .thumb and .text directives, b) always generate Thumb-2 code when asked(*); c) Windows-specific references to external OPENSSL_armcap_P. (*) so far *some* modules were compiled as .code 32 even if Thumb-2 was targeted. It works at hardware level because processor can alternate between the modes with no overhead. But clang --target=arm-windows's builtin assembler just refuses to compile .code 32... Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8252)
2019-02-12AArch64 assembly pack: authenticate return addresses.Andy Polyakov
ARMv8.3 adds pointer authentication extension, which in this case allows to ensure that, when offloaded to stack, return address is same at return as at entry to the subroutine. The new instructions are nops on processors that don't implement the extension, so that the vetification is backward compatible. Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8205)
2019-01-31Build: Remove BEGINRAW / ENDRAW / OVERRIDERichard Levitte
It was an ugly hack to avoid certain problems that are no more. Also added GENERATE lines for perlasm scripts that didn't have that explicitly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8125)
2018-12-06Following the license change, modify the boilerplates in crypto/aes/Richard Levitte
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7771)
2018-12-06License: change any non-boilerplate comment referring to "OpenSSL license"Richard Levitte
Make it just say "the License", which refers back to the standard boilerplate. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7764)
2018-09-11Update copyright yearMatt Caswell
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7176)
2018-06-25PA-RISC assembly pack: make it work with GNU assembler for HP-UX.Andy Polyakov
Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6583)
2018-06-03PPC assembly pack: correct POWER9 results.Andy Polyakov
As it turns out originally published results were skewed by "turbo" mode. VM apparently remains oblivious to dynamic frequency scaling, and reports that processor operates at "base" frequency at all times. While actual frequency gets increased under load. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6406)
2018-05-29Update copyright yearMatt Caswell
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6371)
2018-05-10PPC assembly pack: add POWER9 results.Andy Polyakov
Reviewed-by: Rich Salz <rsalz@openssl.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-03 11:05:17 +0000