| 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 |
| Message-ID: | 20190909151845.acjtzqatc4je7pfc@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| 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 |