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

[Alessandro Ghedini via RT]

On Wed, Nov 11, 2015 at 11:52:56AM +0000, Kurt Roeckx via RT wrote:
> 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.

Well, yeah, but OpenBSD sort of guarantees that explicit_bzero() is safe. In
any case removing that is ok by me.

> > 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().

More recent versions of mingw do support SecureZeroMemory() so that's not the
problem, it just so happens that the one installed by Travis is quite ancient.

> > 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.

No, when using the volatile pointer the compiler doesn't know if the target
function is reentrant or not (because it doesn't know what the target function
actually is) so removing the call is not safe, even by -O3 standards (e.g. that
function might change a global variable or write to a file). Again, that's the
whole point of "volatile".

> > 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.

Well, yeah, I've been doing my manual tests with LTO all along. My point was
that on some platform/compiler/configuration, whatever implementation of
OPENSSL_cleanse is used, it could still be optimized away. So it would be
useful to have a test to detect that automatically when "make test" is run.

However the test provided by OpenBSD/LibreSSL doesn't work, that is, with some
configurations (e.g. when LTO is used) it doesn't actually detect that the call
has been optimized away, so a smarter test is required, but I have no idea what
that might look like.

Cheers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151111/5cdf8540/attachment.sig>