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

[Kurt Roeckx via RT]

On Wed, Nov 11, 2015 at 05:15:06PM +0000, Kaduk, Ben via RT wrote:
> On 11/11/2015 07:06 AM, Kurt Roeckx via RT wrote:
> > 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?
> 
> SecureZeroMemory is provided by the Windows system headers; its contract
> indicates that it will not be optimized out by compilers (it seems
> perform the writes through a volatile char*).

That seems to be problematic, I think it has already be pointed
out that some compilers actually do optimize that away.  Volatile
prevents caching, it does not prevent dead code elimination.

> > 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.
> >
> The contract of volatile means that the compiler is not permitted to
> assume that nothing else is going to write to that variable -- the
> compiler doesn't get to make the assumption about hardware not writing
> to the variable, even if we humans can.

The contract of volatile means that the compiler can't cache it.
But I think that's only when it actually generates code for it,
not when it can optimize it away.


Kurt