Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent

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?

1 files changed, 0 insertions, 35 deletions

diff --git a/src/lib/libcrypto/x86_64cpuid.pl b/src/lib/libcrypto/x86_64cpuid.pl
index 6ebfd017ea..8422e91342 100644
--- a/src/lib/libcrypto/x86_64cpuid.pl
+++ b/src/lib/libcrypto/x86_64cpuid.pl
@@ -172,41 +172,6 @@ OPENSSL_ia32_cpuid:
         or      %r9,%rax
         ret
 .size   OPENSSL_ia32_cpuid,.-OPENSSL_ia32_cpuid
-
-.globl  OPENSSL_cleanse
-.type   OPENSSL_cleanse,\@abi-omnipotent
-.align  16
-OPENSSL_cleanse:
-        xor     %rax,%rax
-        cmp     \$15,$arg2
-        jae     .Lot
-        cmp     \$0,$arg2
-        je      .Lret
-.Little:
-        mov     %al,($arg1)
-        sub     \$1,$arg2
-        lea     1($arg1),$arg1
-        jnz     .Little
-.Lret:
-        ret
-.align  16
-.Lot:
-        test    \$7,$arg1
-        jz      .Laligned
-        mov     %al,($arg1)
-        lea     -1($arg2),$arg2
-        lea     1($arg1),$arg1
-        jmp     .Lot
-.Laligned:
-        mov     %rax,($arg1)
-        lea     -8($arg2),$arg2
-        test    \$-8,$arg2
-        lea     8($arg1),$arg1
-        jnz     .Laligned
-        cmp     \$0,$arg2
-        jne     .Little
-        ret
-.size   OPENSSL_cleanse,.-OPENSSL_cleanse
 ___
 
 print<<___ if (!$win64);