C++ Logo

sg12

Advanced search

Re: [SG12] p1315 secure_clear

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Thu, 30 Apr 2020 08:19:50 +0200
On 30/04/2020 02.10, Arthur O'Dwyer via SG12 wrote:
> On Wed, Apr 29, 2020 at 7:26 PM Patrice Roy via SG12 <sg12_at_[hidden] <mailto: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.

Yes.

Paul's P1382 is much easier in this regard, and very close
to traditional volatile semantics.

> 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

And then, the compiler does
      strcpy(passwordbuffer, secondcopy);

rigbt before "passwordbuffer" ends its lifetime. Also undesirable and
totally defeating the purpose, but fine under the status quo as-if rule.

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

Agreed.

Jens

Received on 2020-04-30 01:22:58