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.


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

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