On Tue, Aug 08, 2023 at 01:12:02PM -0400, Sweet Tea Dorminy wrote: > Encryption has been desired for btrfs for a long time, in order to > provide some measure of security for data at rest. However, since btrfs > supports snapshots and reflinks, fscrypt encryption has previously been > incompatible since it relies on single inode ownership of data > locations. A design for fscrypt to support btrfs's requirements, and for > btrfs to use encryption, was constructed in October '21 [1] and refined > in November '22 [2]. > > This patch series builds on two fscrypt patch series adding extent-based > encryption to fscrypt, which allows using fscrypt in btrfs. The fscrypt > patchsets have no effect without a user, and this patchset makes btrfs > use the new extent encryption abilities of fscrypt. > > These constitute the first of several steps laid out in the design > document [2]: the second step will be adding authenticated encryption > support to the block layer, fscrypt, and then btrfs. Other steps will > potentially add the ability to change the key used by a directory > (either for all data or just newly written data), allow use of inline > extents and verity items in combination with encryption, and enable > send/receive of encrypted volumes. This changeset is not suitable for > usage due to the lack of authenticated encryption. > > In addition to the fscrypt patchsets, [3] [4], this changeset requires > the latest version of the btrfs-progs changeset, which is currently at > [5], and the latest version of the fstests changeset, [6]. It is based > on kdave/misc-next as of approximately now. > > This changeset passes all encryption tests in fstests, and also survives > fsperf runs with lockdep turned on, including the previously failing > dbench test. > > This version changes the format of extent contexts on disk as per > Josef's comment on v2: the encryption field in file extents now only > stores the fact of encryption with fscrypt, and the context stored at > the end of the file extent now stores the length of the fscrypt extent > as well as the fscrypt extent itself. > > I remain really excited about Qu's work to make extent buffers > potentially be either folios or vmalloc'd memory -- this would allow > eliminating change 'fscrypt: expose fscrypt_nokey_name' and the code > using it. > Generally speaking I'm pretty happy with the state of this patchset. Please do the fixups I've asked for and refresh, but I think we're getting close to the end here. Thanks, Josef
|