Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jan 12, 2021 at 09:40:53PM +0900, Masahiko Sawada wrote: > > > This says: > > > > > > > > > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#Other_requirements > > > > > > wal_log_hints will be enabled automatically in encryption mode. > > > > > > Does that help? > > > > IIUC it helps but not enough. When wal_log_hints is enabled, we write > > a full-page image when updating hint bits if it's the first time > > change for the page since the last checkpoint. But I'm concerned that > > what if we change hint bits again after the page is flushed. We would > > mark the page as dirtied but not write any WAL, leaving the page lsn > > as it is. > > I updated the wiki to be: > > > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#Other_requirements > > wal_log_hints will be enabled automatically in encryption mode. However, > more than one hit change between checkpoints does not cause WAL > activity, which would cause the same LSN to be used for different pages > images. > > I think one big question is that, since we are using a streaming cipher, > do we care about hint bit changes showing to users? I actually don't > know. If we do, some kind of dummy LSN record might be required, as you > suggested.
I don't think there's any doubt that we need to make sure that the IV is distinct and advancing the LSN to get a new one when needed for this case seems like it's probably the way to do that. Hint bit change visibility to users isn't really at issue here- we can't use the same IV multiple times. The two options that we have are to either not actually update the hint bit in such a case, or to make sure to change the LSN/IV. Another option would be to, if we're able to make a hole to put the GCM tag on to the page somewhere, further widen that hole to include an additional space for a counter that would be mixed into the IV, to avoid having to do an XLOG NOOP. Thanks, Stephen
signature.asc
Description: PGP signature
