Correct. Which is why you want a compilation policy parameter to the compiler so that it is observed as a whole, not just on one function in isolation. You need the entire global interpretation to provide a certain behavior - not just a local interpretation.

-- Gaby
________________________________
From: SG12 <sg12-bounces_at_[hidden]> on behalf of Nevin Liber via SG12 <sg12_at_[hidden]>
Sent: Friday, April 24, 2020 4:51:24 PM
To: sg12_at_[hidden] <sg12_at_[hidden]>
Cc: Nevin Liber <nevin_at_[hidden]>; miguel_at_[hidden] <miguel_at_[hidden]>
Subject: Re: [SG12] p1315 secure_clear

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.

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]<mailto:nevin_at_[hidden]>>  +1-847-691-1404