Message-ID: <ecbb7ea8-11f6-30c1-ad77-bd984c52ca33@quicinc.com>
Date: Fri, 11 Jul 2025 11:00:40 +0530
From: Md Sadre Alam <quic_mdalam@...cinc.com>
To: Adrian Vovk <adrianvovk@...il.com>, Eric Biggers <ebiggers@...nel.org>,
        <dm-devel@...ts.linux.dev>
CC: <linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Israel
 Rukshin <israelr@...dia.com>, Milan Broz <gmazyland@...il.com>,
        Mikulas
 Patocka <mpatocka@...hat.com>
Subject: Re: [RFC PATCH v2 2/2] dm-inlinecrypt: add target for inline block
 device encryption

Hi Eric,

On 10/18/2024 8:22 AM, Adrian Vovk wrote:
> Hello,
> 
> On 10/16/24 19:27, Eric Biggers wrote:
>> From: Eric Biggers <ebiggers@...gle.com>
>>
>> Add a new device-mapper target "dm-inlinecrypt" that is similar to
>> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
>> This allows it to take advantage of inline encryption hardware such as
>> that commonly built into UFS host controllers.
> 
> Wow! Thank you for this patch! This is something we really want in 
> systemd and in GNOME, and I came across this patchset on accident while 
> trying to find a way to get someone to work on it for us.
> 
>> The table syntax matches dm-crypt's, but for now only a stripped-down
>> set of parameters is supported.  For example, for now AES-256-XTS is the
>> only supported cipher.
>>
>> dm-inlinecrypt is based on Android's dm-default-key with the
>> controversial passthrough support removed.
> 
> That's quite unfortunate. I'd say this passthrough support is probably 
> the most powerful thing about dm-default-key.
> 
> Could you elaborate on why you removed it? I think it's a necessary 
> feature. Enabling multiple layers of encryption stacked on top of each 
> other, without paying the cost of double (or more...) encryption, is 
> something we really want over in userspace. It'll enable us to stack 
> full-disk encryption with encrypted /home directories for each user and 
> then stack encrypted per-app data dirs on top of that. I'd say that the 
> passthrough support is more important for us than the performance 
> benefit of using inline encryption hardware.
> 
> Without a solution to layer encryption we can't do a lot of good things 
> we want to do in userspace.
> 
> As far as I understand, the passthrough support was controversial only 
> because previous upstreaming attempts tried to punch holes into dm-crypt 
> to make this work. I don't know of an attempt to upstream dm-default-key 
> as-is, with passthrough support. As far as I can tell, people even 
> seemed open to that idea...
> 
> Is there some context I'm missing? Information would be appreciated.
> 
>> Note that due to the removal
>> of passthrough support, use of dm-inlinecrypt in combination with
>> fscrypt causes double encryption of file contents (similar to dm-crypt +
>> fscrypt), with the fscrypt layer not being able to use the inline
>> encryption hardware.  This makes dm-inlinecrypt unusable on systems such
>> as Android that use fscrypt and where a more optimized approach is
>> needed.
> 
> Yeah, sadly you've removed the use-case we're very interested in. 
> Generic PC hardware doesn't have blk-crypto hardware as far as I can 
> tell, so we don't get the performance benefit of replacing dm-crypt with 
> dm-inlinecrypt. However, we do get the performance benefit of the 
> passthrough support (if we run this on top of the blk-crypto software 
> emulation mode, for instance)
> 
> 
> Best,
> 
> Adrian Vovk
> 
>> It is however suitable as a replacement for dm-crypt.
>>
>> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
>>

Is there any plan to update this series ? IPQ9574 needs this 
dm-inlinecrypt driver for secure eMMC feature.

Thanks,
Alam.

Powered by blists - more mailing lists