| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
meaningful constants in a private header file, so that reviewers can actually
get a chance to figure out what the code is attempting to do without knowing
all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned
64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will
now always use OPENSSL_cpu_caps() and check for the proper bits in the
whole 64-bit word it returns.
i386 tests and ok jsing@
|
| |
|
|
|
|
| |
flag for the presence of a FPU before deciding to wipe the fpu registers.
ok jsing@
|
| |
|
|
| |
have been used under DJGPP in the previous century (if at all).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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?
|
| | |
|
| | |
|
| | |
|
| |
|
