On Wed, Apr 29, 2020 at 7:26 PM Patrice Roy via SG12 <sg12_at_[hidden]>
wrote:
>
> The need for a mechanism to ensure some operations are actually
> performed, under whatever name we use, seems clear to me and has
> been a recurring topic over the years.

Yes, but...
I think it's very important to point out that what "secure_clear" is trying
to do is an *opposite, much harder* problem: it's asking for a mechanism to
ensure that some operations are *never *performed.

It's easy to ensure that an operation *is* performed; all you have to do is
insert an optimization barrier like Google Benchmark's DoNotOptimize, which
is basically an `asm volatile("")` statement.

    memset(passwordbuffer, 0x00, sizeof passwordbuffer);
    DoNotOptimize(&passwordbuffer); // escape this variable to force the
memset to be respected

What secure_clear is trying to do is to ensure that a "sufficiently dumb
compiler" does not compile the above code into the equivalent of

    char *secondcopy = strdup(passwordbuffer); free(secondcopy); // oops,
leaked a copy of the data onto the heap
    static char secondcopy[100]; strcpy(secondcopy, passwordbuffer); //
oops, leaked a copy of the data into the data section
    memset(passwordbuffer, 0x00, sizeof passwordbuffer);
    DoNotOptimize(&passwordbuffer); // the memset is respected, but useless

The above is permitted today under the as-if rule; but secure_clear is
asking for some way to *ensure, formally,* that it *never *happens.

Ensuring that something *doesn't *happen is much much harder than ensuring
that it *does *happen.

–Arthur