On 15/11/17 11:05, Jorge Almeida wrote:
On Wed, Nov 15, 2017 at 12:54 AM, Nikos Chantziaras <rea...@gmail.com> wrote:
On 14/11/17 19:36, Jorge Almeida wrote:
On Fri, Nov 10, 2017 at 12:09 PM, Jorge Almeida <jjalme...@gmail.com>
wrote:
Unless you look at the assembly output, you can't be sure. Some optimization
is done even at -O0.
I'd stick to using explicit_bzero() which is safe regardless of compiler
vendor *and* version.
But what about overwriting with random bytes? Having "explicit-*"
versions of whatnot seems madness. BTW, I checked the assemby,
memset() is there. But there should be way to tell the compiler "do
what I say".
Writing random bytes isn't going to help. If the compiler can deduce
that the random bytes aren't being used and that not writing anything
will not change the observable behavior of the code, the write might not
happen. And even if you do use the random bytes (like writing them to
/dev/null,) the write might still not happen. The compiler might have
marked another memory location as "hot" (in cache terms) and safe to
write to, and use that instead.
The only sure way to do this I can think of, is to require the caller to
use volatile and implement your own memset(). This is obviously prone to
error. To fix that, you could enforce your own volatile pointer with
something like:
typedef struct passwd_t {
volatile char* data;
} passwd_t;
passwd_t* alloc_passwd(int len);
void free_passwd(passwd_t* passwd);
However, since explicit_bzero() is something several other people have
come up as the solution to the problem, it's what I recommend. It's been
tested already by other people on multiple platforms and compilers. Have
a configure check for it, and if not found, try again with -lbsd. Or
have a configure switch for it. These tests are easy to do with CMake or
Autoconf.
Trying to reinvent the wheel, especially when it comes to security,
doesn't sound like a good idea. It's easy to get it wrong.
