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

[Kurt Roeckx via RT]

On Wed, Nov 11, 2015 at 12:37:56PM +0000, Alessandro Ghedini via RT wrote:
> 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:
> > > 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.

As far as I know mingw uses gcc so how is it able to guarantee
that SecureZeroMemory() works as intended?

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

So you're saying they assign the function that should be called
to a volatile pointer, so the compiler can't be sure which
function is called forcing it to read that volatile pointer all
the time?

I'm not sure the compiler isn't going to optimize that if it can
tell nothing else is ever going to write that pointer.  I think
it's reasonable for it to assume that hardware isn't going to
change that pointer.

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

Even the assembler version gets optimized away?


Kurt