On 8/1/2025 2:30 AM, Eric Biggers wrote:
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
Hi, Mikulas
For f2fs, the check happens at the beginning of f2fs_allocate() just
like ext4.
LongPing Wei
