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 <[email protected]>
>>>> ---
>>>> .../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
>>>
>>
