public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sasasu <[email protected]>
To: Robert Haas <[email protected]>
To: Andres Freund <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: XTS cipher mode for cluster file encryption
Date: Tue, 19 Oct 2021 23:46:12 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoaMHLXrxOj1HA+K=Z_qqgZUOpfdto8+QiVXsfP0ds+ojw@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CA+TgmoaMHLXrxOj1HA+K=Z_qqgZUOpfdto8+QiVXsfP0ds+ojw@mail.gmail.com>
On 2021/10/19 00:37, Robert Haas wrote:
> I think what we ought to be doing at
> this point is combining our efforts to try to get some things
> committed which make future work in this area committed - like that
> patch to preserve relfilenode and database OID, or maybe some patches
> to drive all of our I/O through a smaller number of code paths instead
> of having every different type of temporary file we write reinvent the
> wheel.
A unified block-based I/O API sounds great. Has anyone tried to do this
before? It would be nice if the front-end tools could also use these API.
As there are so many threat models, I propose to do the TDE feature by a
set of hooks. those hooks are on the critical path of IO operation, add
the ability to let extension replace the IO API. and also load extension
when initdb, single-mode, and in front-end tools.
This sounds Like using $LD_PRELOAD to replace pread(2) and pwrite(2),
which widely used in folder based encryption. but the hook will pass
more context (filenode, tableoid, blocksize, and many) to the under
layer, this hook API will look like object_access_hook.
then implement the simplest AES-XTS. and put it to contrib. provide a
tool to deactivate AES-XTS to make PostgreSQL upgradeable.
I think this is the most peaceful method. GCM people will not reject
this just because XTS. and XTS people will satisfied(maybe?) with the
complexity. for performance, just one more long-jump compare with
current AES-XTS code.
Attachments:
[application/pgp-keys] OpenPGP_0x4E72AF09097DAE2E.asc (7.9K, ../[email protected]/2-OpenPGP_0x4E72AF09097DAE2E.asc)
download
[application/pgp-signature] OpenPGP_signature (833B, ../[email protected]/3-OpenPGP_signature)
download
view thread (54+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: XTS cipher mode for cluster file encryption
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox