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

[Mikulas Patocka <mpatocka@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]



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.

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
> > 
>