Date: Tue, 19 Oct 2021 14:54:56 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Sasasu <i@sasa.su>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>,
	Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: XTS cipher mode for cluster file encryption
Message-ID: <20211019185456.GV20998@tamriel.snowman.net>
References: <20211013222648.GA373@momjian.us>
 <20211015192248.GP20998@tamriel.snowman.net>
 <20211015212109.ugwjuhe4lzymnorg@alap3.anarazel.de>
 <CA+TgmoaMHLXrxOj1HA+K=Z_qqgZUOpfdto8+QiVXsfP0ds+ojw@mail.gmail.com>
 <4b73c57e-0941-9e66-ea7e-087793c4c927@sasa.su>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="gst1TLx4aVAjus+f"
Content-Disposition: inline
In-Reply-To: <4b73c57e-0941-9e66-ea7e-087793c4c927@sasa.su>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20211019185456.GV20998%40tamriel.snowman.net>
Precedence: bulk


--gst1TLx4aVAjus+f
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Sasasu (i@sasa.su) wrote:
> 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.
>=20
> 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.

The TDE patch from Cybertec did go down this route, but the API ended up
being rather different which menat a lot of changes in other parts of
the system.  If we can get a block-based temporary file method that
maintains more-or-less the same API, that'd be great, but I'm not sure
that we can really do so and I am not entirely convinced that we should
make the TDE effort depend on an otherwise quite independent effort of
making all temp files usage be block based.

> 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), whi=
ch
> widely used in folder based encryption. but the hook will pass more conte=
xt
> (filenode, tableoid, blocksize, and many) to the under layer, this hook A=
PI
> 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.
>=20
> 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 complexi=
ty.
> for performance, just one more long-jump compare with current AES-XTS cod=
e.

I agree with Robert- using hooks for this really isn't realistic.  Where
would you store the tag for GCM without changes in core, for starters..?
Certainly wouldn't make sense to provide GCM only to throw the tag away.
Even between XTS and GCM, to say nothing of other possible methods,
there's going to be some serious differences that a single hook-based
API wouldn't be able to address.

Thanks,

Stephen

--gst1TLx4aVAjus+f
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJhbxSAAAoJEO1sijiDR2RVm+UP/RUh0gwVpHPb+/sDTV3f5bLk
TmRGpB/74ho+6hRw9m9EzwybDBq6xZKmdT8RfkaGhK5ahAnmxq2FUtKoq3lMKkOL
/rNNWaegMEzQWs20+19PxgrEepJuhLjdpF8FWE+w91fRu+Bx8v6153t/gU2fUDNI
daoIguQu6OUpJgU8mnnJpYyOUym5l5kn2LVb84/1s3vVHEeWZnjne0ENLjpfV+aT
nNsftszoD2/MxQ6Az40z1wYVuIuXFhcE5IBx8sETBDIONPlT/Xkb6L/xfZKHhjI1
KIjhyasJgcSOBj+h6Z3RPCXhJ6PJxcLi7q6HOxDl+EuQj+zTpAKBicMYUQyKrSsX
rNL87fcix9mGBlEJqCe6g2LyH+haMalLLxz3ZL/cLNl7qi+nmZPmbvqgLzEk7gH0
27H2X0XWyMdsM3FTVJzIuGkG/bzQ1Rs3wmvCikvcxeYotEh5SNhKbLhqS2fZM5Nw
WAQN2vDG0PhJ5PGwYCzzdqhqbN24DEOCaci7pFBy9/heoqZ/lwfH1Slx3rF/Ri7r
oW9/K8h0sPcaeGexrUQIyxJAFwmD4RerGdnObl0N4WbSN1oJWi1DvTRw+zw1i2GI
z46hxRMwu55A9zw7k6+kGyKxcjtwfyl8tVWJi/T7PGiDHfpzioVGFDaE84+1jIWl
U21zW8VCRpG1fi2miBEf
=wgaG
-----END PGP SIGNATURE-----

--gst1TLx4aVAjus+f--