On Fri, Apr 24, 2020 at 11:51 PM JF Bastien <cxx_at_[hidden]> wrote:

> 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?
>
I not looking for either of the above. The shortcomings of volatile's
specification is okay for me (I could be convinced otherwise though). The
"same approach as volatile" seems to be where the paper is trying to go,
but "volatile" works because all volatile operations are evaluated strictly
according to the rules of the abstract machine, which is not necessarily
the case of the operations on the memory being cleared in the status quo of
the paper.


>
> 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?
>
Not exactly, but that would be sufficient. If the user used the object in
ways that they don't consider as "secret", then those writes not being
volatile is fine.
I believe that the wording might end up in a place where the clearing
operation is only sufficient for establishing a physical realization of the
object with respect to the requirements of the clearing operation itself
(which is that there are so many bytes to write to). The use of volatile
for writing and reading the "secret" would make it so that the physical
realization being cleared is also the physical realization of the object
for all "secret"-related purposes.


>
>
>
>>
>>> - 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.
>
I'm not looking for guidance from SG1 on the general topic of the paper,
but if we end up wanting to try the "unknown threads" approach, then I
think we'll need SG1 to tell us if the approach is workable (and to get
guidance to the author on the wording approach for that).


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