Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Backport support for probing ARMv8 HW acceleration capabilities on armv7 | patrick | 2019-03-13 | 1 | -29/+95 |
| | | | | | | in preparation for adding support for the probing code for arm64. ok bcook@ | ||||
* | Do not compile the neon probe code until __ARM_ARCH__ >= 7. Neon-specific code | miod | 2014-05-03 | 1 | -0/+2 |
| | | | | will not get referenced if this condition is not met. | ||||
* | Remove unreferenced OPENSSL_instrument_bus and OPENSSL_instrument_bus2 routines. | miod | 2014-05-01 | 1 | -18/+0 |
| | |||||
* | Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function. | miod | 2014-04-17 | 1 | -7/+0 |
| | |||||
* | Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent | miod | 2014-04-17 | 1 | -32/+0 |
| | | | | | | | | | | | supposedly smart compilers from optimizing memory cleanups away. Understood. Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood. But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation? | ||||
* | import OpenSSL-1.0.1c | djm | 2012-10-13 | 1 | -0/+154 |