summaryrefslogtreecommitdiffstats
path: root/lib/libssl/src/crypto/x86cpuid.pl (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove the libssl/src directorybeck2016-09-031-192/+0
|
* Remove OPENSSL_instrument_halt and OPENSSL_far_spin, which both mightmiod2014-06-201-70/+0
| | | | have been used under DJGPP in the previous century (if at all).
* A few months back there was a big community fuss regarding direct-usederaadt2014-06-021-12/+0
| | | | | | | | | | | | of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer. Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone. Send this support straight to the abyss. ok kettenis
* So it turns out that libcrypto on i386 platforms, unconditionaly compiles thismiod2014-04-221-39/+0
| | | | | | | | | | | | | little gem called OPENSSL_indirect_call(), supposedly to be ``handy under Win32''. In my view, this is a free-win ROP entry point. Why try and return to libc when you can return to libcrypto with an easy to use interface? Better not give that much attack surface, and remove this undocumented entry point. ok beck@ tedu@
* Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function.miod2014-04-171-11/+0
|
* Ok, there was a need for OPENSSL_cleanse() instead of bzero() to preventmiod2014-04-171-34/+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.1gmiod2014-04-131-2/+4
|
* import OpenSSL-1.0.1cdjm2012-10-131-17/+61
|
* import OpenSSL-1.0.0adjm2010-10-011-11/+98
|
* import of OpenSSL 0.9.8hdjm2008-09-061-0/+225
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.