On Fri, Dec 18, 2020 at 7:55 AM Daniel Papke via SG14 <sg14_at_[hidden]>
wrote:

> During last week's meeting, I stepped away briefly, but I don't believe we
> covered the secure_clear proposal in any depth. Having read through it, I
> have a concern with the proposal.
> P1315R5 secure_clear (
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1315r5.html)
>
> Secure clear is definitely a useful function. However, I'm concerned
> that the description here is not specific about the resulting value [...]
> I suggest that secure_clear should allow the user to specify a value for
> the overwrite.
>

So instead of (or in addition to) P1315R5's example
    char *buf2 = ...;
    std::secure_clear(buf2, sizeof(buf2)); // OK, explicit
you would also like the ability to write
    std::secure_clear(buf2, sizeof(buf2), 0xAA);
for example?

How is that observably different from
    // A
    std::secure_clear(buf2, sizeof(buf2));
    std::memset(buf2, 0xAA, sizeof(buf2));
?
How is it observably different from
    // B
    std::memset(buf2, 0xAA, sizeof(buf2));
    std::secure_clear(buf2, sizeof(buf2));
?

Since P1315R5 is already supposing some magic way to ensure that the
secure_clear's *write* "really happens," it seems like it would be easy to
specify that secure_clear also *reads* the values in the buffer. So if you
want to ensure that 0xAA definitely gets written prior to the "random"
overwrite, it seems like option B would do that foolproofly.

You can actually use option B today, as long as secure_clear is defined in
a different translation unit. The compiler can't tell that secure_clear
*doesn't* read the contents of buf2, and so it must ensure that the memset
has really happened prior to the call instruction that calls secure_clear.
(Of course this doesn't stop extra copies of the sensitive data appearing
on the stack, hanging around in cache, etc. P1315R5 specifically doesn't
attempt to solve the problem of securely eliminating all *copies* of
secrets.)

 –Arthur