On Fri, Apr 24, 2020 at 8:44 PM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> On Fri, Apr 24, 2020 at 6:12 PM JF Bastien via SG12 <sg12_at_[hidden]>
> wrote:
>
>> Hello SG12/UB folks,
>>
>> I'd like to start a discussion about p1315 <http://wg21.link/p1315>
>> secure_clear. Please see the paper's history on github
>> <https://github.com/cplusplus/papers/issues/67>.
>>
>> Here's what I'd want SG12's help on: assume that there's a need for some
>> sort of "secure clearing of memory", how do we fit this into the abstract
>> machine? What behavior do we specify, what do we leave open, while meeting
>> the stated security goals?
>>
>> For example:
>>
>> - If we clear "memory" then we're not clearing registers, stack
>> copies, caches, etc. What, if anything, should we say?
>> - How do we talk about calling secure_clear right before deallocation
>> functions in such a way that memory is still cleared?
>>
>> The best we have currently is what we say for volatile. I still believe
> that the writes of the values which are being replaced should also have
> been volatile. Whether or not the performance of applications under such a
> solution is "acceptable" may concern some parties. Assuming that
> implementations define the mapping between volatile operations in the
> abstract machine to the physical implementation well enough, this might be
> "good enough" without changing the abstract machine model.
>

Volatile indeed seems like the best we have. I sent this email in large
parts because Miguel isn't used to WG21 / WG14, and needs help to figure
out what's missing and how to fix this. Would your expectation be that this
paper should first try to fix the shortcomings of volatile's specification,
or would you be OK with the paper merely using the same approach as
volatile, with the same normative shortcomings?

What do you mean by "the writes of the values which are being replaced
should also have been volatile"? You mean that the object being cleared
should have been volatile from its inception?



>
>> - The current paper doesn't say what value is stored (unlike
>> memset_s). What's the best way to do this?
>>
>>
>> How should we talk about the feature so it best fits in C++? What should
>> we change about the abstract machine to make it happen?
>>
>> Once SG12 is satisfied with the paper, I'd like EWG and LEWG to review
>> it. We also need to synchronize with WG14. Should we also talk to WG23?
>>
> I imagine that the "observers" from outside the abstract machine act much
> like (extra-abstractional?) threads. Some mechanism is needed to ensure
> that all writes to the memory from "before" the clearing appear to be
> ordered before the writes to the memory occurring from the clearing (and I
> suppose those should appear to be ordered before the writes that occur
> "after" the clearing). At which point I know enough to know that I need
> help from SG1. If we can convince ourselves that optimizations will be
> sufficiently well-behaved given sufficient concurrency-related wording and
> the assumption of "unknown threads", then another approach is to indicate
> the presence of these unknown threads for the purposes of the
> synchronization involved for the clearing operation.
>

SG1 said this didn't concern them. If other groups think SG1 is in error,
I'd like to be able to give SG1 additional guidance, not have the author
run around.



> Thanks,
>>
>> JF
>> _______________________________________________
>> SG12 mailing list
>> SG12_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
>> Link to this post: http://lists.isocpp.org/sg12/2020/04/0853.php
>>
>