On Fri, Apr 24, 2020 at 4:52 PM Nevin Liber via SG12 <sg12_at_[hidden]>
wrote:

> 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.
>

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_at_[hidden]
> <nevin_at_[hidden]>>  +1-847-691-1404
> _______________________________________________
> 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/0859.php
>