Re: using explicit_bzero

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: using explicit_bzero
Date: 2019-09-09 15:18:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-09-05 08:38:36 +0200, Peter Eisentraut wrote:
> On 2019-09-05 04:12, Michael Paquier wrote:
> > On Wed, Sep 04, 2019 at 04:38:21PM -0400, Alvaro Herrera wrote:
> >> Marked RfC. Can we get on with this?
> >
> > FWIW, I have been able to test this one on Windows with MSVC and
> > things are handled correctly.
> committed

I still think this change is done wrongly, by providing an
implementation for a library function implemented in various
projects. If you e.g. dynamically load a library that implements its own
version of bzero, ours will replace it in many cases.

I think all this implementation actually guarantees is that bzero2 is
read, but not that the copy is not elided. In practice that's *probably*
good enough, but a compiler could just check whether bzero_p points to

I think we have absolutely no business possibly intercepting / replacing
actually securely coded implementations of sensitive functions.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Murat Tuncer 2019-09-09 16:03:25 Re: having issues with PG12 debian packaging repository
Previous Message Konstantin Knizhnik 2019-09-09 15:12:28 Re: Built-in connection pooler