Re: [PATCH] dm: set DM_TARGET_PASSES_CRYPTO feature for dm-thin

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Jul 31, 2025 at 06:04:52PM +0200, Mikulas Patocka wrote:
> 
> 
> On Wed, 30 Jul 2025, LongPing Wei wrote:
> 
> > Hi, Mikulas
> > 
> > For example:
> > 
> > F2FS/EXT4
> > ----
> > dm-thin
> > ----
> > dm-thin-pool
> > ----
> > pool data
> > 
> > 1. There is a block of testfile in F2FS/EXT4.
> > 2. The offset of this block is n.
> > 3. The position in the dm-thin device is m.
> > 4. The position in the pool data is x.
> > 
> > The IV is only be affectted by offset in file and the ino of this file.
> > 
> > Even if we change m by defrag or change x by COW, IV won't changed.
> > 
> > The upper layer will only read the decrypted blocks with the same key and
> > continous IV in one bio.
> > 
> > If the upper layer read the full chunk with mixed blocks for GC purpose, key
> > and IV won't be passed in. Then the upper layer just get the encrypted blocks.
> > 
> > LongPing Wei
> 
> Yes - so if the IV is calculated from inode and offset, it seems safe to 
> support it on dm-thin. So, I accepted the patch (and increased the target 
> version).
> 
> BTW. what happens if someone uses FALLOC_FL_COLLAPSE_RANGE or 
> FALLOC_FL_INSERT_RANGE on a file with inline encryption? That changes file 
> offsets of existing data, so it should be disallowed when using inline 
> encryption - but I don't see a test for this in the functions 
> ext4_collapse_range and ext4_insert_range.

This seems to be a question about fscrypt, not about inline encryption
per se.  FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE fail with
EOPNOTSUPP on encrypted files, as is documented in
Documentation/filesystems/fscrypt.rst.  For ext4, the check happens at
the beginning of ext4_fallocate().

- Eric