Re: [PATCH v3 00/17] btrfs: add encryption feature

[Josef Bacik <josef@toxicpanda.com>]

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