| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com> |
| Subject: | Re: storing an explicit nonce |
| Date: | 2021-05-27 16:19:11 |
| Message-ID: | 20210527161911.bi2bf2aczmmxlzck@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-05-27 11:10:00 -0400, Bruce Momjian wrote:
> On Wed, May 26, 2021 at 04:46:29PM -0700, Andres Freund wrote:
> > On 2021-05-25 22:23:46 -0400, Stephen Frost wrote:
> > > Andres mentioned other possible cases where the LSN doesn’t change even
> > > though we change the page and, as he’s probably right, we would have to
> > > figure out a solution in those cases too (potentially including cases like
> > > crash recovery or replay on a replica where we can’t really just go around
> > > creating dummy WAL records to get new LSNs..).
> >
> > Yea, I think there's quite a few of those. For one, we don't guarantee
> > that that the hole between pd_lower/upper is zeroes. It e.g. contains
> > old tuple data after deleted tuples are pruned away. But when logging an
> > FPI, we omit that range. Which means that after crash recovery the area
> > is zeroed out. There's several cases where padding can result in the
> > same.
> >
> > Just look at checkXLogConsistency(), heap_mask() et al for all the
> > differences that can occur and that need to be ignored for the recovery
> > consistency checking to work.
> >
> > Particularly the hole issue seems trivial to exploit, because we know
> > the plaintext of the hole after crash recovery (0s).
> >
> >
> > I don't see how using the LSN alone is salvagable.
>
> OK, so you are saying the replica would have all zeros because of crash
> recovery, so XOR'ing that with the encryption steam makes the encryption
> stream visible, and you could use that to decrypt the dead data on the
> primary. That is an interesting case that would need to fix.
I don't see how it's a viable security model to assume that you can
ensure that we never write different data with the same LSN. Yes, you
can fix a few cases, but how can we be confident that we're actually
doing a good job, when the consequences are pretty dramatic.
Nor do I think it's architecturally OK to impose a significant new
hurdle against doing any sort of "changing" writes on standbys.
It's time to move on from the idea of using the LSN as the nonce.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-05-27 16:26:18 | Re: storing an explicit nonce |
| Previous Message | Bruce Momjian | 2021-05-27 16:15:27 | Re: storing an explicit nonce |