Re: storing an explicit nonce - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: storing an explicit nonce
Date
Msg-id 20211012131412.GA20500@momjian.us
Whole thread Raw
In response to Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Responses Re: storing an explicit nonce  (Ants Aasma <ants@cybertec.at>)
List pgsql-hackers
On Tue, Oct 12, 2021 at 08:49:28AM -0400, Stephen Frost wrote:
> * Bruce Momjian (bruce@momjian.us) wrote:
> > I thought he was saying that when you extend a file, you might have to
> > extend it with all zeros, rather than being able to extend it with
> > an actual encrypted page of zeros.  For example, I think when a page is
> > corrupt in storage, it reads back as a fully zero page, and we would
> > need to handle that.  Are you saying we already have logic to handle
> > that so we don't need to change anything?
> 
> When we extend a file, it gets extended with all zeros.  PG already
> handles that case, PG w/ TDE would need to also recognize that case
> (which is what Ants was saying their patch does) and handle it.  In
> other words, we just need to realize when a page is all zeros and not
> try to decrypt it when we're reading it.  Ants' patch does that and my
> recollection is that it wasn't very complicated to do, and that seems
> much simpler than trying to figure out a way to ensure we do encrypt a
> zero'd page as part of extending a file.

Well, how do you detect an all-zero page vs a page that encrypted to all
zeros?  I am thinking a zero LSN (which is not encrypted) would be the
only sure way, but we then have to make sure unlogged relations always
get a fake LSN.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Gather performance analysis
Next
From: vignesh C
Date:
Subject: Re: Added schema level support for publication.