On E, 2017-11-13 at 12:44 +0200, Nikos Chantziaras wrote: > On 13/11/17 09:17, Jorge Almeida wrote: > > > > On Sun, Nov 12, 2017 at 7:03 PM, Mart Raudsepp <l...@gentoo.org> > > wrote: > > > > > > On L, 2017-11-11 at 00:10 +0000, Jorge Almeida wrote: > > > > > > > > Well, most programmers probably won't care about this stuff > > > > anyway, > > > > and people who deal with cryptography tend to be more cautious > > > > than > > > > average. But I'm not really making a case for safe versions of > > > > known > > > > functions. After all, the usual functions do fine for most > > > > applications. memset() would be enough to clear RAM with > > > > sensitive > > > > data if we had a pragma (or equivalent) to convince the > > > > compiler to > > > > not ignore it (I mean a pragma to invoke on a particular > > > > function > > > > definition when the programmer feels that a black box > > > > behaviour is > > > > undesirable). Of course, solving the problem of the compiler > > > > copying > > > > stuff around might be harder nut to crack. > > > Sounds like you want explicit_bzero from libbsd? > > > > > According to their man page, yes. I'll have to [try to] check the > > source. I wonder how they do it? Even the volatile modifier doesn't > > solve the problem, according to the link in previous post. > explicit_bzero() is available in glibc. It's in <string.h>.
Interesting. Some Xorg stuff is using libbsd explicitly, but probably since before glibc gained this. This is new since glibc-2.25. How they do it you can find out from the source code. In libbsd case, I saw a weak linked (do-nothing) function call after memset, so the compiler can't know if that weakly linked function isn't getting replaced with something that might do something with the zeroed memory, and thus can't optimize it out. Though I looked at an older libbsd.
