On Fri, Apr 24, 2020 at 6:12 PM JF Bastien via SG12 <sg12@lists.isocpp.org> wrote:
Hello SG12/UB folks,

I'd like to start a discussion about p1315 secure_clear. Please see the paper's history on github.

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.


SG12 mailing list
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
Link to this post: http://lists.isocpp.org/sg12/2020/04/0853.php