Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Linlin Zhang <linlin.zhang@oss.qualcomm.com>]

On 3/13/2026 11:27 PM, Milan Broz wrote:
> On 3/13/26 2:25 PM, Mikulas Patocka wrote:
>> On Thu, 12 Mar 2026, Eric Biggers wrote:
>>
>>> On Wed, Mar 04, 2026 at 04:17:27AM -0800, Linlin Zhang wrote:
>>>> From: Eric Biggers <ebiggers@google.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.
> 
> ...
> 
>>> I don't think it's plausible that this new patch was actually tested.
>>> The version I sent in 2024 was tested at the time
>>> (https://lore.kernel.org/r/20241016232748.134211-3-ebiggers@kernel.org/),
>>> but I see at least two things that would make this new patch not work.
> 
> What a waste of time... thanks.
>> OK. I dropped it.
> 
> Well, the inline crypt has some advantages to proprietary internal
> hw implementations (like self-encrypting drives)  - it can be actually validated
> comparing to sw version.
> 
> Anyway, Mikulas, if this dm-inlinecrypt returns one day, please be
> sure that we do not have security-related "regressions" like not supporting
> keyring. There is no need for dm-inlinecrypt to keep key inside the mapping table.
> The keyring code is in dm-crypt, it should be easy to adapt it here.
> 
> Thanks,
> Milan
> 

Thanks for your review.

I understood that supporting keyring here is to ensure no raw key exposed to
dm table. As implied by the name dm-inlinecrypt, the key used by dm-inlinecyrpt
is a wrapped key, rather raw key. Can we keep the wrapped key inside the mapping
table?
In other word, can dm-inlinecrypt support both keyring and hex key(key in mapping
table)?

Thanks,
Linlin