wireguard-openbsd/lib/libcrypto/pariscid.pl, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/lib/libcrypto/pariscid.pl?h=jd%2Fqueueboosts2014-05-01T22:26:21ZDo not output SOM-specific directives.2014-05-01T22:26:21Zmiodmiod@openbsd.org2014-05-01T22:26:21Zurn:sha1:88da0340c754ca6ec7ebdbcca1562ffe9490bf19Remove unreferenced OPENSSL_instrument_bus and OPENSSL_instrument_bus2 routines.2014-05-01T22:25:13Zmiodmiod@openbsd.org2014-05-01T22:25:13Zurn:sha1:4b1141835cb2d87ae3bac5b6d3b8aac529007074Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.2014-04-17T18:49:35Zmiodmiod@openbsd.org2014-04-17T18:49:35Zurn:sha1:7a9318151354b01849fa7b72ca43141cd331f42dOk, there was a need for OPENSSL_cleanse() instead of bzero() to prevent2014-04-17T18:16:45Zmiodmiod@openbsd.org2014-04-17T18:16:45Zurn:sha1:71a94becd57c2fb84d531dc50aa1f1a4031889cf
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.1g2014-04-13T15:16:32Zmiodmiod@openbsd.org2014-04-13T15:16:32Zurn:sha1:9eac5592c81620ead272fa71be9a79e0e24176feimport OpenSSL-1.0.1c2012-10-13T21:23:32Zdjmdjm@openbsd.org2012-10-13T21:23:32Zurn:sha1:ec07fdf13572372e9cd617b18f2e2790e6616c8c