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