Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys
On 5/18/2026 8:49 PM, Milan Broz wrote: > On 5/18/26 10:11 AM, Linlin Zhang wrote: > > ... >>> IOW the mapping will look like this (1 is number of optional parameters): >>> >>> 1 hw-wrapped >>> or >>> 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" > > Just use semicolon as separator as Mikulas suggested. > (I mixed that up, we always use semicolan as separator.) > >> 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. > > It no longer works this way, it is normal that in some scenarios "optional" > arguments > are required. For example sector_size - once you use non-default, you have to > specify > it always. > > IOW no problem with that. Thanks for the comments! ACK. I'll send a new patch with such modification. > > Milan >
Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys
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 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
---
.../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::
- \
+ \
[<#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):
>>>
>>> 1 hw-wrapped
>>> or
>>> 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
>>>
>>
Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys
On 5/18/26 10:11 AM, Linlin Zhang wrote: ... IOW the mapping will look like this (1 is number of optional parameters): 1 hw-wrapped or 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" Just use semicolon as separator as Mikulas suggested. (I mixed that up, we always use semicolan as separator.) 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. It no longer works this way, it is normal that in some scenarios "optional" arguments are required. For example sector_size - once you use non-default, you have to specify it always. IOW no problem with that. Milan
Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys
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 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
> >> ---
> >> .../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::
> >> - \
> >> + \
> >> [<#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):
> >
> > 1 hw-wrapped
> > or
> > 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.
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
> >
>
Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys
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 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
>> ---
>> .../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::
>> - \
>> + \
>> [<#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):
>
> 1 hw-wrapped
> or
> 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!
>
> 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
>
Re: [PATCH v2 1/1] dm-inlinecrypt: add support for hardware-wrapped keys
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 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 --- .../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:: - \ + \ [<#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): 1 hw-wrapped or 1 keytype=hw-wrapped The second option will allow to add new key type much easier. Please check how other targets implement it, some dm-crypt examples https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt Thanks, Milan
