Date: Fri, 24 Apr 2020 21:08:57 -0700
On Fri, Apr 24, 2020 at 4:21 PM Jens Maurer <Jens.Maurer_at_[hidden]> 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_at_[hidden]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
> > Link to this post: http://lists.isocpp.org/sg12/2020/04/0853.php
> >
>
>
> 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_at_[hidden]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
> > Link to this post: http://lists.isocpp.org/sg12/2020/04/0853.php
> >
>
>
Received on 2020-04-24 23:12:07