Sasasu <i@sasa.su> wrote:
> Hi hackers,
>
> there are a very long discuss about TDE, and we agreed on that if the
> temporary file I/O can be aligned to some fixed size, it will be easier
> to use some kind of encryption algorithm.
>
> discuss:
> https://www.postgresql.org/message-id/20211025155814.GD20998%40tamriel.snowman.net
>
> This patch adjust file->curOffset and file->pos before the real IO to
> ensure the start offset is aligned.
Does this test really pass regression tests? In BufFileRead(), I would
understand if you did
+ file->pos = offsetInBlock;
+ file->curOffset -= offsetInBlock;
rather than
+ file->pos += offsetInBlock;
+ file->curOffset -= offsetInBlock;
Anyway, BufFileDumpBuffer() does not seem to enforce curOffset to end up at
block boundary, not to mention BufFileSeek().
When I was implementing this for our fork [1], I concluded that the encryption
code path is too specific, so I left the existing code for the unecrypted data
and added separate functions for the encrypted data.
One specific thing is that if you encrypt and write n bytes, but only need
part of it later, you need to read and decrypt exactly those n bytes anyway,
otherwise the decryption won't work. So I decided not only to keep curOffset
at BLCKSZ boundary, but also to read / write BLCKSZ bytes at a time. This also
makes sense if the scope of the initialization vector (IV) is BLCKSZ bytes.
Another problem is that you might want to store the IV somewhere in between
the data. In short, the encryption makes the buffered IO rather different and
the specific code should be kept aside, although the same API is used to
invoke it.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
[1] https://github.com/cybertec-postgresql/postgres/tree/PG_14_TDE_1_1