On Fri, Apr 24, 2020 at 4:21 PM Jens Maurer <Jens.Maurer@gmx.net> wrote:
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.)

I agree with the above. This is the author's first proposal, and I wouldn't expect most seasoned WG21 members to be able to do what you describe. I'm hoping that folks would be able to help Miguel out here, not necessarily by writing the wording but by offering guidance. The papers you provide are a good start on what's been missing in the past. I think Miguel's paper should mention them. It would be useful to go back to their discussions to understand what was suggested there. Are there concrete ideas of what would work? Hubert suggests that relying on volatile would be acceptable handwaving, do you think so as well?

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

This is strongly debated. When I talk to compiler / language folks I hear exactly what you say. When I speak to security folks I hear something completely different: they agree with your point, yet they say that clearing the memory location is the primary source of leaks, and they have (or want) other means to address the other secondary leaks. An outcome of this severe disagreement is that security folks often deride C++ for being insecure and not wanting to fix "obvious" issues. I'd like to run this paper to its natural conclusion, whether that's some inclusion in C++, or its death with strong justification as to why it died (so we can stop having this particular debate).

I don't want to argue this, I'm trying to state facts on various perceptions, and the effects that come out of this. Maybe the paper can discuss this dichotomy in more details to save everyone some time?

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

That's an interesting approach. Miguel, would you be able to do this?


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

Hey that's what *my* email was about! :-p


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@lists.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
> Link to this post: http://lists.isocpp.org/sg12/2020/04/0853.php
>