openbsd/src/lib/libcrypto/armv4cpuid.S, branch OPENBSD_6_8_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE2019-03-13T10:18:30+00:00Backport support for probing ARMv8 HW acceleration capabilities on armv72019-03-13T10:18:30+00:00patrick2019-03-13T10:18:30+00:00urn:sha1:96e62a13a6d04fbc03969ab4a0627800a44f8342
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 code2014-05-03T19:36:47+00:00miod2014-05-03T19:36:47+00:00urn:sha1:f5a345e09d166911714faaffa3ce076385b9ddfa
will not get referenced if this condition is not met.
Remove unreferenced OPENSSL_instrument_bus and OPENSSL_instrument_bus2 routines.2014-05-01T22:25:13+00:00miod2014-05-01T22:25:13+00:00urn:sha1:ca8f1a96c629cd959d8f55527734f99958508ad3Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.2014-04-17T18:49:35+00:00miod2014-04-17T18:49:35+00:00urn:sha1:b4ee6facff27de9af90bfa187f0b058454154db5Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent2014-04-17T18:16:45+00:00miod2014-04-17T18:16:45+00:00urn:sha1:777aa5b3f157309dd7bae673d3f2ae8f37e71457
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.1c2012-10-13T21:23:50+00:00djm2012-10-13T21:23:50+00:00urn:sha1:228cae30b117c2493f69ad3c195341cd6ec8d430