Re: using explicit_bzero - Mailing list pgsql-hackers

From Andres Freund
Subject Re: using explicit_bzero
Date
Msg-id 20190909151845.acjtzqatc4je7pfc@alap3.anarazel.de
Whole thread Raw
In response to Re: using explicit_bzero  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: using explicit_bzero
List pgsql-hackers
Hi,

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
memset.

http://cseweb.ucsd.edu/~lerner/papers/dse-usenix2017.pdf
https://boringssl-review.googlesource.com/c/boringssl/+/1339/

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

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooler
Next
From: Murat Tuncer
Date:
Subject: Re: having issues with PG12 debian packaging repository