On Tue, Jul 30, 2019 at 5:58 PM Andres Freund <andres@anarazel.de> wrote:
> > +#include "c.h"
>
> Hm?
Heh.
> > +static void (* volatile bzero_p)(void *, size_t) = bzero2;
>
> Hm, I'm not really sure that this does that much. Especially when the
> call is via a function in the same translation unit.
Yeah, I wondered the same (when reading the OpenSSH version). You'd
think you'd need a non-static global so it has to assume that it could
change.
> > +void
> > +explicit_bzero(void *buf, size_t len)
> > +{
> > + bzero_p(buf, len);
>
> I've not followed this discussion. But why isn't the obvious
> implementation here memset(...); pg_compiler_barrier()?
>
> A quick web search indicates that that's what a bunch of projects in the
> cryptography space also ended up with (well, __asm__ __volatile__("" :::
> "memory"), which is what pg_compiler_barrier boils down to for
> gcc/clang/compatibles).
At a glance, I think 3.4.3 of this 2017 paper says that might not work
on Clang and those other people might have a bug:
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-yang.pdf
cfbot says:
fe-connect.obj : error LNK2019: unresolved external symbol
explicit_bzero referenced in function freePGconn
[C:\projects\postgresql\libpq.vcxproj]
Moved to next CF.
--
Thomas Munro
https://enterprisedb.com