On Sun, Jul 7, 2019 at 1:11 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> I see. My premise, which should perhaps be explained in a comment at
> least, is that on an operating system that does not provide
> explicit_bzero() (or an obvious alternative), we don't care about
> addressing this particular security concern, since the rest of the
> operating system won't be secure in this way either. It shouldn't be
> our job to fight this battle if the rest of the OS doesn't care.
>
> An alternative patch would define explicit_bzero() to nothing if not
> available. But that might create bugs if subsequent code relies on the
> memory being zeroed, independent of security concerns, so I changed it
> to use memset() so that at least logically both code paths are the same.
Following a trail of crumbs beginning at OpenSSH's fallback
implementation of this[1], I learned that C11 has standardised
memset_s[2] for this purpose. Macs have memset_s but no
explicit_bzero. FreeBSD has both. I wonder if it'd be better to make
memset_s the function we use in our code, considering its standard
blessing and therefore likelihood of being available on every system
eventually.
Oh, I see the problem: glibc 2.25 introduced explicit_bzero, but no
version of glibc has memset_s yet. So that's why you did it that
way... RHEL 8 and Debian 10 ship with explicit_bzero. Bleugh.
[1] https://github.com/openssh/openssh-portable/blob/master/openbsd-compat/explicit_bzero.c
[2]
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#%5B%7B%22num%22%3A1353%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C0%2C792%2C0%5D
--
Thomas Munro
https://enterprisedb.com