On 25/04/2020 00.12, JF Bastien via SG12 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?

Over the past years, there have been occasional proposals
that want to escape the abstract machine, for various reasons:

N4534: Data-Invariant Functions (revision 3)
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4534.html

P0928R1 Mitigating Spectre v1 Attacks in C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0928r1.pdf

P1315 secure_clear is another such proposal.

All the proposals above are silent on the vital question
how to change the as-if rule of the abstract machine such
that the desired semantics / restrictions are realized,
optimizations can continue to be applied widely,
conformance of a particular implementation can be decided,
and we don't give up the power of the generality of the
as-if rule. (The standard is silent on particular
optimization techniques, which is good.)

I'm strongly opposed to adding such facilities without
changing the abstract machine description in the core
language section. Some hand-waving in the library
section is not enough.

Until we have a viable specification approach for such
matters, my view is such proposals are dead-on-arrival.

(As a side note, we've been occasionally struggling with
the semantics of volatile in the context of the abstract
machine, too.)

> For example:
>
> * If we clear "memory" then we're not clearing registers, stack copies, caches, etc. What, if anything, should we say?

Since secure_clear takes trivially copyable arguments,
the compiler is free to make arbitrary additional copies
on the stack, in registers, or elsewhere. Clearing
just one of the instances is not enough to achieve the
stated use-cases of this function. A security feature
that doesn't reliably deliver should not exist in the
first place.

> * How do we talk about calling secure_clear right before deallocation functions in such a way that memory is still cleared?

There is a need to prevent certain compiler optimizations
from happening, preferably within an abstract model instead
of naming them individually.

> * The current paper doesn't say what value is stored (unlike memset_s). What's the best way to do this?

I don't think this matters, since reading the cleared memory
afterwards would read indeterminate values and thus be
undefined behavior.

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

Ideas welcome.

Jens


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