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

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

[LongPing Wei]

dm-thin obviously can pass through inline crypto support.

Signed-off-by: LongPing Wei <weilongping@oppo.com>
---
 drivers/md/dm-thin.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 05cf4e3f2bbe..42f218dcf99f 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -4111,7 +4111,7 @@ static void pool_io_hints(struct dm_target *ti, struct queue_limits *limits)
 static struct target_type pool_target = {
 	.name = "thin-pool",
 	.features = DM_TARGET_SINGLETON | DM_TARGET_ALWAYS_WRITEABLE |
-		    DM_TARGET_IMMUTABLE,
+		    DM_TARGET_IMMUTABLE | DM_TARGET_PASSES_CRYPTO,
 	.version = {1, 23, 0},
 	.module = THIS_MODULE,
 	.ctr = pool_ctr,
@@ -4509,6 +4509,7 @@ static struct target_type thin_target = {
 	.status = thin_status,
 	.iterate_devices = thin_iterate_devices,
 	.io_hints = thin_io_hints,
+	.features = DM_TARGET_PASSES_CRYPTO,
 };
 
 /*----------------------------------------------------------------*/
-- 
2.34.1

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

[Mikulas Patocka]

On Wed, 30 Jul 2025, LongPing Wei wrote:

> dm-thin obviously can pass through inline crypto support.

Hi

I'm not sure about it. What if dm-thin performs copy-on-write? How would 
that interact with inline crypto?

Mikulas

> Signed-off-by: LongPing Wei <weilongping@oppo.com>
> ---
>  drivers/md/dm-thin.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
> index 05cf4e3f2bbe..42f218dcf99f 100644
> --- a/drivers/md/dm-thin.c
> +++ b/drivers/md/dm-thin.c
> @@ -4111,7 +4111,7 @@ static void pool_io_hints(struct dm_target *ti, struct queue_limits *limits)
>  static struct target_type pool_target = {
>  	.name = "thin-pool",
>  	.features = DM_TARGET_SINGLETON | DM_TARGET_ALWAYS_WRITEABLE |
> -		    DM_TARGET_IMMUTABLE,
> +		    DM_TARGET_IMMUTABLE | DM_TARGET_PASSES_CRYPTO,
>  	.version = {1, 23, 0},
>  	.module = THIS_MODULE,
>  	.ctr = pool_ctr,
> @@ -4509,6 +4509,7 @@ static struct target_type thin_target = {
>  	.status = thin_status,
>  	.iterate_devices = thin_iterate_devices,
>  	.io_hints = thin_io_hints,
> +	.features = DM_TARGET_PASSES_CRYPTO,
>  };
>  
>  /*----------------------------------------------------------------*/
> -- 
> 2.34.1
> 

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

[LongPing Wei]

On 7/30/2025 6:46 PM, Mikulas Patocka wrote:
> 
> 
> On Wed, 30 Jul 2025, LongPing Wei wrote:
> 
>> dm-thin obviously can pass through inline crypto support.
> 
> Hi
> 
> I'm not sure about it. What if dm-thin performs copy-on-write? How would
> that interact with inline crypto?
> 
> Mikulas
> 
Hi, Mikulas

dm-thin's encryption behavior is the same as dm-bow's when COW occurs, 
and DM_TARGET_PASSES_CRYPTO has already been set to dm-bow.

The key and iv of inline crypto are passed in by the upper layer, which 
is not affected by the specific location of data blocks in thin-pool.

LongPing Wei>> Signed-off-by: LongPing Wei <weilongping@oppo.com>
>> ---
>>   drivers/md/dm-thin.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
>> index 05cf4e3f2bbe..42f218dcf99f 100644
>> --- a/drivers/md/dm-thin.c
>> +++ b/drivers/md/dm-thin.c
>> @@ -4111,7 +4111,7 @@ static void pool_io_hints(struct dm_target *ti, struct queue_limits *limits)
>>   static struct target_type pool_target = {
>>   	.name = "thin-pool",
>>   	.features = DM_TARGET_SINGLETON | DM_TARGET_ALWAYS_WRITEABLE |
>> -		    DM_TARGET_IMMUTABLE,
>> +		    DM_TARGET_IMMUTABLE | DM_TARGET_PASSES_CRYPTO,
>>   	.version = {1, 23, 0},
>>   	.module = THIS_MODULE,
>>   	.ctr = pool_ctr,
>> @@ -4509,6 +4509,7 @@ static struct target_type thin_target = {
>>   	.status = thin_status,
>>   	.iterate_devices = thin_iterate_devices,
>>   	.io_hints = thin_io_hints,
>> +	.features = DM_TARGET_PASSES_CRYPTO,
>>   };
>>   
>>   /*----------------------------------------------------------------*/
>> -- 
>> 2.34.1
>>
> 

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

[Mikulas Patocka]

On Wed, 30 Jul 2025, LongPing Wei wrote:

> On 7/30/2025 6:46 PM, Mikulas Patocka wrote:
> > 
> > 
> > On Wed, 30 Jul 2025, LongPing Wei wrote:
> > 
> > > dm-thin obviously can pass through inline crypto support.
> > 
> > Hi
> > 
> > I'm not sure about it. What if dm-thin performs copy-on-write? How would
> > that interact with inline crypto?
> > 
> > Mikulas
> > 
> Hi, Mikulas
> 
> dm-thin's encryption behavior is the same as dm-bow's when COW occurs, and
> DM_TARGET_PASSES_CRYPTO has already been set to dm-bow.
> 
> The key and iv of inline crypto are passed in by the upper layer, which is not
> affected by the specific location of data blocks in thin-pool.
> 
> LongPing Wei>> Signed-off-by: LongPing Wei <weilongping@oppo.com>

How is it supposed to work during provisioning? Suppose that you have 64k 
chunk with no mapping. dm-thin returns zero for it. Then, you write 4k 
somewhere to this chunk. dm-thin allocates the chunk, writes zeroes to it 
and then writes 4k data into it (and only this 4k block will be 
encrypted). When you attempt to read this chunk, the 4k block will be 
deciphered correctly, but the zero data around it will be deciphered too 
and garbage will be returned to the application.

Mikulas

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

[LongPing Wei]

On 7/30/2025 8:27 PM, Mikulas Patocka wrote:
> 
> 
> On Wed, 30 Jul 2025, LongPing Wei wrote:
> 
>> On 7/30/2025 6:46 PM, Mikulas Patocka wrote:
>>>
>>>
>>> On Wed, 30 Jul 2025, LongPing Wei wrote:
>>>
>>>> dm-thin obviously can pass through inline crypto support.
>>>
>>> Hi
>>>
>>> I'm not sure about it. What if dm-thin performs copy-on-write? How would
>>> that interact with inline crypto?
>>>
>>> Mikulas
>>>
>> Hi, Mikulas
>>
>> dm-thin's encryption behavior is the same as dm-bow's when COW occurs, and
>> DM_TARGET_PASSES_CRYPTO has already been set to dm-bow.
>>
>> The key and iv of inline crypto are passed in by the upper layer, which is not
>> affected by the specific location of data blocks in thin-pool.
>>
>> LongPing Wei>> Signed-off-by: LongPing Wei <weilongping@oppo.com>
> 
> How is it supposed to work during provisioning? Suppose that you have 64k
> chunk with no mapping. dm-thin returns zero for it. Then, you write 4k
> somewhere to this chunk. dm-thin allocates the chunk, writes zeroes to it
> and then writes 4k data into it (and only this 4k block will be
> encrypted). When you attempt to read this chunk, the 4k block will be
> deciphered correctly, but the zero data around it will be deciphered too
> and garbage will be returned to the application.
> 
> Mikulas
> 
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

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

[Mikulas Patocka]

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.

Mikulas

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

[Eric Biggers]

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

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

[LongPing Wei]

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