From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposed patch for key managment |
Date: | 2020-12-05 15:42:05 |
Message-ID: | 20201205154205.GA31727@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Dec 5, 2020 at 09:54:33PM +0900, Michael Paquier wrote:
> On Fri, Dec 04, 2020 at 10:52:29PM -0500, Bruce Momjian wrote:
> > OK, I worked with Sawada-san and added the attached patch. The updated
> > full patch is at the same URL: :-)
> >
> > https://github.com/postgres/postgres/compare/master...bmomjian:key.diff
>
> Oh, I see that you use SHA256 during firstboot, which is why you
> bypass the resowner paths in cryptohash_openssl.c. Wouldn't it be
> better to use IsBootstrapProcessingMode() then?
I tried that, but we also use the resource references before the
resource system is started even in non-bootstrap mode. Maybe we should
be creating a resource owner for this, but it is so early in the boot
process I don't know if that is safe.
> > @@ -72,14 +72,15 @@ pg_cryptohash_create(pg_cryptohash_type type)
> > ctx = ALLOC(sizeof(pg_cryptohash_ctx));
> > if (ctx == NULL)
> > return NULL;
> > + explicit_bzero(ctx, sizeof(pg_cryptohash_ctx));
> >
> > state = ALLOC(sizeof(pg_cryptohash_state));
> > if (state == NULL)
> > {
> > - explicit_bzero(ctx, sizeof(pg_cryptohash_ctx));
> > FREE(ctx);
> > return NULL;
> > }
> > + explicit_bzero(state, sizeof(pg_cryptohash_state));
>
> explicit_bzero() is used to give the guarantee that any sensitive data
> gets cleaned up after an error or on free. So I think that your use
> is incorrect here for an initialization.
It turns out what we were missing was a clear of state->resowner in
cases where the resowner was null. I removed the bzero calls completely
and it now runs fine.
> > if (state->evpctx == NULL)
> > {
> > - explicit_bzero(state, sizeof(pg_cryptohash_state));
> > - explicit_bzero(ctx, sizeof(pg_cryptohash_ctx));
> > #ifndef FRONTEND
> > ereport(ERROR,
> > (errcode(ERRCODE_OUT_OF_MEMORY),
>
> And this original position is IMO more correct.
Do we even need them?
> Anyway, at quick glance, the backtrace of upthread is indicating a
> double-free with an attempt to free a resource owner that has been
> already free'd.
I think that is now fixed too. Updated patch at the same URL:
https://github.com/postgres/postgres/compare/master...bmomjian:key.diff
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-12-05 16:39:26 | Re: automatic analyze: readahead - add "IO read time" log message |
Previous Message | Peter Eisentraut | 2020-12-05 15:30:38 | Change definitions of bitmap flags to bit-shifting style |