[openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse()

Kurt Roeckx via RT rt at openssl.org
Wed Nov 11 11:52:56 UTC 2015


On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote:
> 
> I also added support for explicit_bzero() on OpenBSD.

An explicit_bzero() call is no better than whatever
OPENSSL_cleanse() does, because it has exactly the same problems.
So I don't think this is useful to do.

> Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version that
> Travis installs, so that's currently failing to build.

SecureZeroMemory() (and memset_s()) must be supported by the
compiler.  I don't think any compiler other that Microsoft's one
going to support SecureZeroMemory().

> That's also valid for my implementation IMO. The whole point of "volatile" is
> to prevent the compiler from trying to guess the content of the variable and do
> weird things with it.

As far as I understand volatile will not prevent the compiler from
removing the call.  Volatile will only disable some optimizations,
but it can still see that whatever is written isn't used anymore and
so can be removed.

The advantage of assembler is that the compiler doesn't know what
the assembler does and that the call can have side effects other
than writing to that buffer, preventing it from removing that
call.  That is, as Brian points out, as long as the compiler
doesn't start to learn what the assembler does, which currently
seems unlikely.

> In order to avoid having builds that silently optimize away OPENSSL_cleanse
> it'd be nice to have a test case to check for that. OpenBSD/LibreSSL have
> somthing along those lines [0], but it doesn't seem to work as expected (well,
> at least not with OpenSSL), so alternative ideas are welcome.

As you point out, the compiler can be smart enough to optimize the
call away.  You should at least run that test uing LTO.


Kurt




More information about the openssl-dev mailing list