| 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@
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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?
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
have to go through the PLT/GOT to get at them anymore. In fact going through
the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P.
Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@
who did most of the actual work of tracking down the issue.
ok millert@, mikeb@
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
- global function calls in .init sections (diff makes them via PLT)
- calls to global functions in aes-586.S (made static or local)
- global variable accesses in rc4-x86_64.S (now made via GOT)
from djm@large; ok miod@
|
| |
|
