wireguard-openbsd/lib/libcrypto/ppccpuid.pl, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/lib/libcrypto/ppccpuid.pl?h=jd%2Fqueueboosts2014-05-03T11:39:46ZDetect Altivec support with the machdep.altivec sysctl rather than setmp and2014-05-03T11:39:46Zmiodmiod@openbsd.org2014-05-03T11:39:46Zurn:sha1:2225b59cce89862e3c29e4c5b3772eeeb548dd45
a SIGILL handler.
Do not attempt to detect and use a 64-bit FPU yet.
Remove 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.1c2012-10-13T21:23:32Zdjmdjm@openbsd.org2012-10-13T21:23:32Zurn:sha1:ec07fdf13572372e9cd617b18f2e2790e6616c8cimport OpenSSL-1.0.0a2010-10-01T22:54:00Zdjmdjm@openbsd.org2010-10-01T22:54:00Zurn:sha1:f1535dc82c407426dcbc37ddee0ceff3f0c94865import of OpenSSL 0.9.8k2009-04-06T06:30:00Zdjmdjm@openbsd.org2009-04-06T06:30:00Zurn:sha1:e2ee43e08a3c7112a5237f4eab21d0b36ff93e5e