On Wed, Apr 29, 2020 at 7:26 PM Patrice Roy via SG12 <sg12@lists.isocpp.org> 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