Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys

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

On 5/18/2026 8:37 PM, Mikulas Patocka wrote:
> 
> 
> On Mon, 18 May 2026, Linlin Zhang wrote:
> 
>>
>>
>> On 5/16/2026 8:17 PM, Milan Broz wrote:
>>> On 5/16/26 1:50 PM, Linlin Zhang wrote:
>>>> Add support for hardware-wrapped encryption keys to the
>>>> dm-inlinecrypt target.
>>>>
>>>> Introduce a new parameter <is_wrappedkey> to indicate whether
>>>> the provided key is a raw key or a hardware-wrapped key. Based
>>>> on this flag, the appropriate blk-crypto key type is selected
>>>> when initializing the key.
>>>>
>>>> This allows dm-inlinecrypt to work with hardware that requires
>>>> keys to be wrapped and managed by the underlying inline
>>>> encryption engine.
>>>>
>>>> Update the target argument parsing accordingly and pass the
>>>> key type to blk_crypto_init_key(). Documentation is also
>>>> updated to reflect the new parameter and usage.
>>>>
>>>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>>>> ---
>>>>   .../device-mapper/dm-inlinecrypt.rst          | 10 ++-
>>>>   drivers/md/dm-inlinecrypt.c                   | 71 +++++++++++--------
>>>>   2 files changed, 50 insertions(+), 31 deletions(-)
>>>>
>>>> diff --git a/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst b/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst
>>>> index c71e600efb76..3a4ce2c5f228 100644
>>>> --- a/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst
>>>> +++ b/Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst
>>>> @@ -10,7 +10,7 @@ https://docs.kernel.org/block/inline-encryption.html
>>>>     Parameters::
>>>>   -          <cipher> <key> <iv_offset> <device path> \
>>>> +          <cipher> <key> <is_wrappedkey> <iv_offset> <device path> \
>>>>             <offset> [<#opt_params> <opt_params>]
>>>
>>> Please use optional parameter.
>>> Adding mandatory field will introduce unnecessary incompatibility with dm-crypt mappings.
>>> (The idea was that you can simply switch "crypt" to "inlinecrypt" for raw keys.)
>>>
>>> I would probably just add "hw-wrapped" or "keytype=raw|hw-wrapped" optional argument
>>> (with raw as default, so no need so specify it).
>>>
>>> IOW the mapping will look like this (1 is number of optional parameters):
>>>
>>>    <cipher> <key> <iv_offset> <device path> <offset> 1 hw-wrapped
>>> or
>>>    <cipher> <key> <iv_offset> <device path> <offset> 1 keytype=hw-wrapped
>>
>>
>> Thanks for your suggestion!
>>
>> I agree that keeping "hw-wrapped" or "keytype=raw|hw-wrapped" as an optional
>> argument helps preserve compatibility when switching from "crypt" to
>> "inlinecrypt"
>>
>> My concern is that, in practice, this optional argument may effectively become
>> mandatory for certain configurations. For instance, "hw-wrapped" or
>> "keytype=raw|hw-wrapped" must be set for a wrapped key. This slightly blurs the
>> original intent of "optional arguments", which are typically expected to be
>> truly optional for correct operation.
>>
>> Would this be acceptable? which one is more acceptable for upstream?
>> incompatibility semantics mappings b/w dm-crypt and dm-inlinecrypt or blur
>> the original intent of "optional arguments"?
>>
>> Any additional thoughts or feedback from others would be much appreciated. Thanks!
> 
> Hi
> 
> I would prefer an optional argument "keytype:raw" or "keytype:hw-wrapped". 
> Device mapper targets use colon to separate arguments from values, so I 
> would use it here too.

Thanks for the comment!

ACK. I'll send a new patch with such modification.

> 
> I removed the patch that always sets BLK_CRYPTO_KEY_TYPE_HW_WRAPPED from 
> the linux-dm repository and I will accept a patch that introduces 
> "keytype:hw-wrapped" when you send it.
> 
> Mikulas
> 
>>>
>>> The second option will allow to add new key type much easier.
>>
>> Regarding the second option ("keytype=..."), I agree it is more extensible.
>> Could you please clarify what other key types you envision supporting in the
>> future?
>>
>>>
>>> Please check how other targets implement it, some dm-crypt examples
>>> https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt
>>>
>>> Thanks,
>>> Milan
>>>
>>