Re: using explicit_bzero

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: using explicit_bzero
Date: 2019-07-11 00:39:21
Message-ID: CA+hUKGK9dNAQoVtuXSa_rdTwdvtTiG=NytWq+Ert7_UJArTFKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 7, 2019 at 1:11 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-07-11 00:55:01 Re: [sqlsmith] Crash in mcv_get_match_bitmap
Previous Message Michael Paquier 2019-07-11 00:29:27 Re: pg_checksums (or checksums in general) vs tableam