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

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

[Linlin Zhang]

dm-inlinecrypt currently assumes that all keys are raw software keys.
That does not work for platforms where inline encryption expects
hardware-wrapped key material managed by secure firmware/hardware.

This series adds support for hardware-wrapped keys in dm-inlinecrypt by
introducing an explicit <is_wrappedkey> target argument. The flag lets
dm-inlinecrypt select the proper blk-crypto key type at key
initialization time:

- 0: BLK_CRYPTO_KEY_TYPE_RAW
- 1: BLK_CRYPTO_KEY_TYPE_HW_WRAPPED

With this change, dm-inlinecrypt can support both raw and wrapped key
deployment models without hardcoding one key ownership model.

The series also:

- updates target argument parsing to include the new required flag
- propagates the wrapped/raw state in target status output
- updates dm-inlinecrypt documentation and examples accordingly

Note: this extends target syntax by adding one required parameter, so
existing userspace table definitions must be updated.
dm-inlinecrypt currently assumes that all keys are raw software keys.
That does not work for platforms where inline encryption expects
hardware-wrapped key material managed by secure firmware/hardware.

This series adds support for hardware-wrapped keys in dm-inlinecrypt by
introducing an explicit <is_wrappedkey> target argument. The flag lets
dm-inlinecrypt select the proper blk-crypto key type at key
initialization time:

- 0: BLK_CRYPTO_KEY_TYPE_RAW
- 1: BLK_CRYPTO_KEY_TYPE_HW_WRAPPED

With this change, dm-inlinecrypt can support both raw and wrapped key
deployment models without hardcoding one key ownership model.

The series also:

- updates target argument parsing to include the new required flag
- propagates the wrapped/raw state in target status output
- updates dm-inlinecrypt documentation and examples accordingly

Note: this extends target syntax by adding one required parameter, so
existing userspace table definitions must be updated.

Linlin Zhang (1):
  dm-inlinecrypt: add support for hardware-wrapped keys

 .../device-mapper/dm-inlinecrypt.rst          | 10 ++-
 drivers/md/dm-inlinecrypt.c                   | 71 +++++++++++--------
 2 files changed, 50 insertions(+), 31 deletions(-)

-- 
2.34.1

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

[Linlin Zhang]

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>]
 
 <cipher>
@@ -52,6 +52,10 @@ Parameters::
     The kernel keyring key description inlinecrypt target should look for
     when loading key of <key_type>.
 
+<is_wrappedkey>
+    The flag used to imply if the key is hardware-wrapped or not.
+    '0' means a raw key and '1' means a wrapped key.
+
 <iv_offset>
     The IV offset is a sector count that is added to the sector number
     before creating the IV.
@@ -113,11 +117,11 @@ using dmsetup
 
 	#!/bin/sh
 	# Create a inlinecrypt device using dmsetup
-	dmsetup create inlinecrypt1 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 babebabebabebabebabebabebabebabebabebabebabebabebabebabebabebabe 0 $1 0"
+	dmsetup create inlinecrypt1 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 babebabebabebabebabebabebabebabebabebabebabebabebabebabebabebabe 0 0 $1 0"
 
 ::
 
 	#!/bin/sh
 	# Create a inlinecrypt device using dmsetup when encryption key is stored in keyring service
-	dmsetup create inlinecrypt2 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 $1 0"
+	dmsetup create inlinecrypt2 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 0 $1 0"
 
diff --git a/drivers/md/dm-inlinecrypt.c b/drivers/md/dm-inlinecrypt.c
index bd8e58a028c5..4e49edea59cf 100644
--- a/drivers/md/dm-inlinecrypt.c
+++ b/drivers/md/dm-inlinecrypt.c
@@ -29,6 +29,7 @@ static const struct dm_inlinecrypt_cipher {
  *	   For this purpose a "sector" is 512 bytes.
  * @cipher_string: the name of the encryption algorithm being used
  * @key_size: size of the encryption key in bytes
+ * @is_hw_wrapped: true if the key is a hardware-wrapped key, false for a raw key.
  * @iv_offset: starting offset for IVs.  IVs are generated as if the target were
  *	       preceded by @iv_offset 512-byte sectors.
  * @sector_size: crypto sector size in bytes (usually 4096)
@@ -41,6 +42,7 @@ struct inlinecrypt_ctx {
 	sector_t start;
 	const char *cipher_string;
 	unsigned int key_size;
+	bool is_hw_wrapped;
 	u64 iv_offset;
 	unsigned int sector_size;
 	unsigned int sector_bits;
@@ -83,8 +85,8 @@ static bool contains_whitespace(const char *str)
 	return false;
 }
 
-static int set_key_user(struct key *key, char *bin_key,
-			const unsigned int bin_key_size)
+static int set_key_user(struct key *key, char *key_bytes,
+			const unsigned int key_bytes_size)
 {
 	const struct user_key_payload *ukp;
 
@@ -92,23 +94,23 @@ static int set_key_user(struct key *key, char *bin_key,
 	if (!ukp)
 		return -EKEYREVOKED;
 
-	if (bin_key_size != ukp->datalen)
+	if (key_bytes_size != ukp->datalen)
 		return -EINVAL;
 
-	memcpy(bin_key, ukp->data, bin_key_size);
+	memcpy(key_bytes, ukp->data, key_bytes_size);
 
 	return 0;
 }
 
-static int inlinecrypt_get_keyring_key(const char *key_string, u8 *bin_key,
-					const unsigned int bin_key_size)
+static int inlinecrypt_get_keyring_key(const char *key_string, u8 *key_bytes,
+					const unsigned int key_bytes_size)
 {
 	char *key_desc;
 	int ret;
 	struct key_type *type;
 	struct key *key;
-	int (*set_key)(struct key *key, char *bin_key,
-				   const unsigned int bin_key_size);
+	int (*set_key)(struct key *key, char *key_bytes,
+				   const unsigned int key_bytes_size);
 
 	/*
 	 * Reject key_string with whitespace. dm core currently lacks code for
@@ -137,7 +139,7 @@ static int inlinecrypt_get_keyring_key(const char *key_string, u8 *bin_key,
 
 	down_read(&key->sem);
 
-	ret = set_key(key, (char *)bin_key, bin_key_size);
+	ret = set_key(key, (char *)key_bytes, key_bytes_size);
 
 	up_read(&key->sem);
 	key_put(key);
@@ -178,8 +180,8 @@ static int get_key_size(char **key_string)
 
 #else
 
-static int inlinecrypt_get_keyring_key(const char *key_string, u8 *bin_key,
-					const unsigned int bin_key_size)
+static int inlinecrypt_get_keyring_key(const char *key_string, u8 *key_bytes,
+					const unsigned int key_bytes_size)
 {
 	return -EINVAL;
 }
@@ -284,7 +286,7 @@ static int inlinecrypt_ctr_optional(struct dm_target *ti,
 
 /*
  * Construct an inlinecrypt mapping:
- * <cipher> [<key>|:<key_size>:<logon>:<key_description>] <iv_offset> <dev_path> <start>
+ * <cipher> [<key>|:<key_size>:<logon>:<key_description>] <is_wrappedkey> <iv_offset> <dev_path> <start>
  *
  * This syntax matches dm-crypt's, but the set of supported functionality has
  * been stripped down.
@@ -293,13 +295,14 @@ static int inlinecrypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 {
 	struct inlinecrypt_ctx *ctx;
 	const struct dm_inlinecrypt_cipher *cipher;
-	u8 raw_key[BLK_CRYPTO_MAX_ANY_KEY_SIZE];
+	u8 key_bytes[BLK_CRYPTO_MAX_ANY_KEY_SIZE];
+	enum blk_crypto_key_type key_type;
 	unsigned int dun_bytes;
 	unsigned long long tmpll;
 	char dummy;
 	int err;
 
-	if (argc < 5) {
+	if (argc < 6) {
 		ti->error = "Not enough arguments";
 		return -EINVAL;
 	}
@@ -333,21 +336,33 @@ static int inlinecrypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 	}
 	ctx->key_size = err;
 
-	err = inlinecrypt_get_key(argv[1], raw_key, ctx->key_size);
+	err = inlinecrypt_get_key(argv[1], key_bytes, ctx->key_size);
 	if (err) {
 		ti->error = "Malformed key string";
 		goto bad;
 	}
 
+	/* <is_wrappedkey> */
+	if (sscanf(argv[2], "%d%c", &err, &dummy) != 1 ||
+			(err != 0 && err != 1)) {
+		ti->error = "Invalid is_wrappedkey flag";
+		err = -EINVAL;
+		goto bad;
+	}
+	ctx->is_hw_wrapped = err;
+	key_type = ctx->is_hw_wrapped ?
+			   BLK_CRYPTO_KEY_TYPE_HW_WRAPPED :
+			   BLK_CRYPTO_KEY_TYPE_RAW;
+
 	/* <iv_offset> */
-	if (sscanf(argv[2], "%llu%c", &ctx->iv_offset, &dummy) != 1) {
+	if (sscanf(argv[3], "%llu%c", &ctx->iv_offset, &dummy) != 1) {
 		ti->error = "Invalid iv_offset sector";
 		err = -EINVAL;
 		goto bad;
 	}
 
 	/* <dev_path> */
-	err = dm_get_device(ti, argv[3], dm_table_get_mode(ti->table),
+	err = dm_get_device(ti, argv[4], dm_table_get_mode(ti->table),
 			    &ctx->dev);
 	if (err) {
 		ti->error = "Device lookup failed";
@@ -355,7 +370,7 @@ static int inlinecrypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 	}
 
 	/* <start> */
-	if (sscanf(argv[4], "%llu%c", &tmpll, &dummy) != 1 ||
+	if (sscanf(argv[5], "%llu%c", &tmpll, &dummy) != 1 ||
 	    tmpll != (sector_t)tmpll) {
 		ti->error = "Invalid start sector";
 		err = -EINVAL;
@@ -365,8 +380,8 @@ static int inlinecrypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 
 	/* optional arguments */
 	ctx->sector_size = SECTOR_SIZE;
-	if (argc > 5) {
-		err = inlinecrypt_ctr_optional(ti, argc - 5, &argv[5]);
+	if (argc > 6) {
+		err = inlinecrypt_ctr_optional(ti, argc - 6, &argv[6]);
 		if (err)
 			goto bad;
 	}
@@ -385,10 +400,9 @@ static int inlinecrypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 		       (ctx->sector_bits - SECTOR_SHIFT);
 	dun_bytes = DIV_ROUND_UP(fls64(ctx->max_dun), 8);
 
-	err = blk_crypto_init_key(&ctx->key, raw_key, ctx->key_size,
-				  BLK_CRYPTO_KEY_TYPE_RAW,
-				  cipher->mode_num, dun_bytes,
-				  ctx->sector_size);
+	err = blk_crypto_init_key(&ctx->key, key_bytes, ctx->key_size,
+				  key_type, cipher->mode_num,
+				  dun_bytes, ctx->sector_size);
 	if (err) {
 		ti->error = "Error initializing blk-crypto key";
 		goto bad;
@@ -408,7 +422,7 @@ static int inlinecrypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 bad:
 	inlinecrypt_dtr(ti);
 out:
-	memzero_explicit(raw_key, sizeof(raw_key));
+	memzero_explicit(key_bytes, sizeof(key_bytes));
 	return err;
 }
 
@@ -502,9 +516,10 @@ static void inlinecrypt_status(struct dm_target *ti, status_type_t type,
 		 * the returned table.  Userspace is responsible for redacting
 		 * the key when needed.
 		 */
-		DMEMIT("%s %*phN %llu %s %llu", ctx->cipher_string,
-		       ctx->key.size, ctx->key.bytes, ctx->iv_offset,
-		       ctx->dev->name, ctx->start);
+		DMEMIT("%s %*phN %u %llu %s %llu", ctx->cipher_string,
+		       ctx->key.size, ctx->key.bytes,
+		       ctx->is_hw_wrapped ? 1 : 0,
+		       ctx->iv_offset, ctx->dev->name, ctx->start);
 		num_feature_args += !!ti->num_discard_bios;
 		if (ctx->sector_size != SECTOR_SIZE)
 			num_feature_args += 2;
-- 
2.34.1

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

[Milan Broz]

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

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

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

[Linlin Zhang]

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!

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

[Mikulas Patocka]

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

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

[Linlin Zhang]

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

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

[Milan Broz]

On 5/18/26 10:11 AM, Linlin Zhang wrote:

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

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

[Linlin Zhang]

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):
>>>
>>>     <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"
> 
> 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
>