On Fri, Apr 24, 2020 at 6:21 PM Jens Maurer via SG12 <sg12_at_[hidden]>
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.

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?

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
+1-847-691-1404