On 25/04/2020 01.51, Nevin Liber via SG12 wrote:
> On Fri, Apr 24, 2020 at 6:21 PM Jens Maurer via SG12 <sg12_at_[hidden] <mailto: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.

The key point here is "volatile object", i.e. *all* reads and writes
are volatile (including those before the secure_clear), and all operations
directly refer to the volatile object as opposed to making convenience
copies. For example,

secure_int x[10];
int y[10];

int compute_with(int x);

for (int i = 0; i < 10; ++i) {
  y[i] = compute_with(x[i]);
}

is bad code, because it passes a non-volatile copy to "compute_with".

I agree this would work, but I suspect the performance implications
will make the substantial chunk of the intended target audience
unhappy.

> 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 think those areas you mentioned are strictly outside the realm of C++.

(Vaguely related scenario: At some point, error handling within your
program is at the end of its abilities, you terminate the program
and hope for the environment to cope with the issue. Maybe by
raising a ticket to a technician or by re-starting the program.)

Jens