On 2019-09-09 17:18, Andres Freund wrote:
> 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.
Are you saying that the re
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
> > thing
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
--
Peter Eisentraut
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.
--
Michael
signature.asc
Description: PGP signature
On 2019-Aug-24, Peter Eisentraut wrote:
> On 2019-08-14 05:00, Michael Paquier wrote:
> > On Tue, Aug 13, 2019 at 10:30:39AM +0200, Peter Eisentraut wrote:
> >> Another patch, to attempt to fix the Windows build.
> >
> > I have not been able to test the compilation, but the changes look
> > good
On 2019-08-14 05:00, Michael Paquier wrote:
> On Tue, Aug 13, 2019 at 10:30:39AM +0200, Peter Eisentraut wrote:
>> Another patch, to attempt to fix the Windows build.
>
> I have not been able to test the compilation, but the changes look
> good on this side.
Rebased patch, no functionality change
On Tue, Aug 13, 2019 at 10:30:39AM +0200, Peter Eisentraut wrote:
> Another patch, to attempt to fix the Windows build.
I have not been able to test the compilation, but the changes look
good on this side.
--
Michael
signature.asc
Description: PGP signature
On 2019-07-30 07:58, Andres Freund wrote:
> I think it's better to have a pg_explicit_bzero or such, and implement
> that via the various platform dependant mechanisms. It's considerably
> harder to understand code when one is surprised that a function normally
> not available is called, the build
On 2019-07-30 07:08, Michael Paquier wrote:
> On Mon, Jul 29, 2019 at 11:30:53AM +0200, Peter Eisentraut wrote:
>> Another patch, with various fallback implementations.
>
> I have spotted some issues with this patch:
> 1) The list of port files @pgportfiles in Mkvcbuild.pm has not been
> updated w
Hi,
On 2019-08-01 20:08:15 +1200, Thomas Munro wrote:
> On Tue, Jul 30, 2019 at 5:58 PM Andres Freund wrote:
> > > +#include "c.h"
> > > +static void (* volatile bzero_p)(void *, size_t) = bzero2;
> >
> > Hm, I'm not really sure that this does that much. Especially when the
> > call is via a func
On Tue, Jul 30, 2019 at 5:58 PM Andres Freund wrote:
> > +#include "c.h"
>
> Hm?
Heh.
> > +static void (* volatile bzero_p)(void *, size_t) = bzero2;
>
> Hm, I'm not really sure that this does that much. Especially when the
> call is via a function in the same translation unit.
Yeah, I wondered
Hi,
On 2019-07-29 11:30:53 +0200, Peter Eisentraut wrote:
> For platforms that don't have explicit_bzero(), provide various
> fallback implementations. (explicit_bzero() itself isn't standard,
> but as Linux/glibc and OpenBSD have it, it's the most common spelling,
> so it makes sense to make tha
On Mon, Jul 29, 2019 at 11:30:53AM +0200, Peter Eisentraut wrote:
> Another patch, with various fallback implementations.
I have spotted some issues with this patch:
1) The list of port files @pgportfiles in Mkvcbuild.pm has not been
updated with the new file explicit_bzero.c, so the compilation w
Another patch, with various fallback implementations.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From c040e7aa31a7a12f804c8d32d403861390dec8d5 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 29 Jul
Peter Eisentraut writes:
> On 2019-07-18 00:45, Tom Lane wrote:
>> +1 for using the C11-standard name, even if that's not anywhere
>> in the real world yet.
> ISTM that a problem is that you cannot implement a replacement
> memset_s() as a wrapper around explicit_bzero(), unless you also want to
t; eventually.
>
>> Sounds like a future-proof way would be to implement memset_s in
>> src/port if absent from the OS (using explicit_bzero and other tricks),
>> and use that.
>
> +1 for using the C11-standard name, even if that's not anywhere
> in the real wor
On 2019-07-11 03:11, Michael Paquier wrote:
> On Mon, Jun 24, 2019 at 02:08:50PM +0900, Michael Paquier wrote:
>> CreateRole() and AlterRole() can manipulate a password in plain format
>> in memory. The cleanup could be done just after calling
>> encrypt_password() in user.c.
>>
>> Could it be pos
ro. 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.
> Sounds like a future-proof way would be to imp
27;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.
Sounds like a future-proof way would be to implement memset_s in
src/port if absent from the OS (using explicit_b
On Mon, Jun 24, 2019 at 02:08:50PM +0900, Michael Paquier wrote:
> CreateRole() and AlterRole() can manipulate a password in plain format
> in memory. The cleanup could be done just after calling
> encrypt_password() in user.c.
>
> Could it be possible to add the new flag in pg_config.h.win32?
W
On Sun, Jul 7, 2019 at 1:11 AM Peter Eisentraut
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 con
On 2019-07-05 23:02, Thomas Munro wrote:
> On Sat, Jul 6, 2019 at 1:07 AM Peter Eisentraut
> wrote:
>> On 2019-07-05 14:06, Thomas Munro wrote:
>>> +#ifndef HAVE_EXPLICIT_BZERO
>>> +#define explicit_bzero(b, len) memset(b, 0, len)
>>> +#endif
>>>
>>> I noticed some other libraries use memset throu
On Sat, Jul 6, 2019 at 1:07 AM Peter Eisentraut
wrote:
> On 2019-07-05 14:06, Thomas Munro wrote:
> > +#ifndef HAVE_EXPLICIT_BZERO
> > +#define explicit_bzero(b, len) memset(b, 0, len)
> > +#endif
> >
> > I noticed some other libraries use memset through a function pointer
> > or at least define a
On 2019-07-05 14:06, Thomas Munro wrote:
> +#ifndef HAVE_EXPLICIT_BZERO
> +#define explicit_bzero(b, len) memset(b, 0, len)
> +#endif
>
> I noticed some other libraries use memset through a function pointer
> or at least define a function the compiler can't see.
I don't understand what you are ge
On Mon, Jun 24, 2019 at 7:57 AM Peter Eisentraut
wrote:
> On 2019-06-23 21:55, Peter Eisentraut wrote:
> > On 2019-06-21 15:25, Tom Lane wrote:
> >> years ago (067a5cdb3). Please use memset() for the substitute instead.
> >
> > OK, done.
+#ifndef HAVE_EXPLICIT_BZERO
+#define explicit_bzero(b, le
Michael Paquier writes:
> On Sun, Jun 23, 2019 at 09:56:40PM +0200, Peter Eisentraut wrote:
>> On 2019-06-21 15:45, Dagfinn Ilmari Mannsåker wrote:
>>> Also, on Linux it requires libbsd: https://libbsd.freedesktop.org/
>>
>> No, it's in glibc.
>
> From man:
> explicit_bzero() first appeared in g
On Sun, Jun 23, 2019 at 09:56:40PM +0200, Peter Eisentraut wrote:
> On 2019-06-21 15:45, Dagfinn Ilmari Mannsåker wrote:
>> Also, on Linux it requires libbsd: https://libbsd.freedesktop.org/
>
> No, it's in glibc.
From man:
explicit_bzero() first appeared in glibc 2.25.
--
Michael
signature.asc
On Sun, Jun 23, 2019 at 09:57:18PM +0200, Peter Eisentraut wrote:
> On 2019-06-23 21:55, Peter Eisentraut wrote:
>> On 2019-06-21 15:25, Tom Lane wrote:
>>> Peter Eisentraut writes:
+#ifndef HAVE_EXPLICIT_BZERO
+#define explicit_bzero(b, len) bzero(b, len)
+#endif
>>>
>>> This presu
On 2019-06-23 21:55, Peter Eisentraut wrote:
> On 2019-06-21 15:25, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> +#ifndef HAVE_EXPLICIT_BZERO
>>> +#define explicit_bzero(b, len) bzero(b, len)
>>> +#endif
>>
>> This presumes that every platform has bzero, which is unsafe (POSIX
>> doesn't specif
On 2019-06-21 15:45, Dagfinn Ilmari Mannsåker wrote:
> Also, on Linux it requires libbsd: https://libbsd.freedesktop.org/
No, it's in glibc.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-06-21 15:25, Tom Lane wrote:
> Peter Eisentraut writes:
>> +#ifndef HAVE_EXPLICIT_BZERO
>> +#define explicit_bzero(b, len) bzero(b, len)
>> +#endif
>
> This presumes that every platform has bzero, which is unsafe (POSIX
> doesn't specify it) and is an assumption we kicked to the curb a do
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Also, on Linux it requires libbsd: https://libbsd.freedesktop.org/
> (which seems to be down, but
> https://packages.debian.org/buster/libbsd-dev has a list of the
> functions it provides).
Ugh, that could be a bit nasty. I m
Tom Lane writes:
> Peter Eisentraut writes:
>> +#ifndef HAVE_EXPLICIT_BZERO
>> +#define explicit_bzero(b, len) bzero(b, len)
>> +#endif
>
> This presumes that every platform has bzero, which is unsafe (POSIX
> doesn't specify it) and is an assumption we kicked to the curb a dozen
> years ago (06
Peter Eisentraut writes:
> +#ifndef HAVE_EXPLICIT_BZERO
> +#define explicit_bzero(b, len) bzero(b, len)
> +#endif
This presumes that every platform has bzero, which is unsafe (POSIX
doesn't specify it) and is an assumption we kicked to the curb a dozen
years ago (067a5cdb3). Please use memset()
In a recent thread[0], the existence of explicit_bzero() was mentioned.
I went to look where we could use that to clear sensitive information
from memory and found a few candidates:
- In be-secure-common.c, clear the entered SSL passphrase in the error
path. (In the non-error path, the buffer bel
35 matches
Mail list logo
