On Fri, Apr 24, 2020 at 4:52 PM Nevin Liber via SG12 <sg12@lists.isocpp.org> wrote:
On Fri, Apr 24, 2020 at 6:21 PM Jens Maurer via SG12 <sg12@lists.isocpp.org> wrote:
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.

Taking a step back and ignoring performance concerns, if secure_clear only worked on trivially copyable volatile objects, would that be sufficient?  If so, would some kind of volatile_ref<T> class (similar to atomic_ref<T> vs. atomic<T>) work?  Just brainstorming here.  Without some way to indicate that we have memory that we want to eventually securely clear, I don't see a way to solve this.

An earlier iteration of this paper had "secure_val". Maybe a survey of what types of values memset_s is used for would help answer your question?

My other question:  even if we can someone guarantee no additional copies inside a C++ program (whatever that means), there are always things outside of our control (demand paging by the OS, debuggers, etc.).  Given that we cannot cover all data leakage scenarios, do we still want this?

I've tried to answer this in my previous email. The discussions in the room also covered this extensively. Do you think the paper needs to explain this better? I'm guessing so since you ask.

 Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com>  +1-847-691-1404
SG12 mailing list
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
Link to this post: http://lists.isocpp.org/sg12/2020/04/0859.php