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

[Kaduk, Ben via RT]

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

-Ben