|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-11 18:03:26
Claudio DeSouza wrote:
> The common practice here is to have a specific allocator that safely memsets
> things to 0, and in a way that is guaranteed that an optimiser wonât just
> remove it.
I have no idea what you're replying to, but anyway...
There's no reliable way to implement a "secure memset" (that doesn't impede
performance) without compiler support.
There is this
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1315r7.html
https://github.com/cplusplus/papers/issues/67
which seemingly got into C23 as `memset_explicit`, so C++ will also get it at
some point, and hopefully compilers will implement it as
__builtin_memset_explicit, available in all standard modes.
As is, compilers remove the memset if they can see the object is being
immediately destroyed afterwards, which in our case may be an issue for
one shot hashing leaving part of the message behind, but it's typically
not going to be an issue for the seed constructor leaving the seed behind,
because the hash algorithm object is rarely being destroyed immediately
after construction.
Either way, we are aware of the need of using secure memset.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk