Re: using explicit_bzero
От | Thomas Munro |
---|---|
Тема | Re: using explicit_bzero |
Дата | |
Msg-id | CA+hUKGJmARV-YCv=g0kSujpGDm_M-FEPpSrC2Lpa-gSfAQT8-w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: using explicit_bzero (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: using explicit_bzero
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: