[PATCH v1 0/3] dm-inlinecrypt: add target for inline block device encryption

[PATCH v1 0/3] dm-inlinecrypt: add target for inline block device encryption

[Linlin Zhang]

This patch series is based on Eric’s work posted at:
https://lore.kernel.org/all/ecbb7ea8-11f6-30c1-ad77-bd984c52ca33@quicinc.com/

Eric’s patches introduce a new dm target, dm-inlinecrypt, to support inline
block‑device encryption. The implementation builds on the work previously done
in Android’s dm-default-key, but intentionally drops passthrough support,
as that functionality does not appear likely to be accepted upstream in the
near future. With this limitation, dm-inlinecrypt is positioned as a
practical replacement for dm-crypt, rather than a general passthrough
mechanism.

On top of Eric’s series, this patch addresses a limitation in dm‑core: the
inlinecrypt DM device does not currently have a block crypto profile
initialized, because only DM devices with passthrough support can be associated
with a block crypto profile today. However, dm-inlinecrypt consumes inline
crypto capabilities itself and does not pass them through to upper layers.
To support this model, this series introduces a new consuming‑crypto flag.
This flag indicates that the underlying block device exposes inline crypto
capabilities which are consumed directly by the DM device, rather than being
propagated upward. This allows dm‑core to correctly initialize and manage a
block crypto profile for dm‑inlinecrypt devices.


Eric Biggers (2):
  block: export blk-crypto symbols required by dm-inlinecrypt
  dm-inlinecrypt: add target for inline block device encryption

Linlin Zhang (1):
  dm-inlinecrypt: Expose inline crypto caps to the device

 block/blk-crypto.c            |   3 +
 drivers/md/Kconfig            |  10 +
 drivers/md/Makefile           |   1 +
 drivers/md/dm-inlinecrypt.c   | 416 ++++++++++++++++++++++++++++++++++
 drivers/md/dm-table.c         |   3 +-
 include/linux/device-mapper.h |   7 +
 6 files changed, 439 insertions(+), 1 deletion(-)
 create mode 100644 drivers/md/dm-inlinecrypt.c

-- 
2.34.1

[PATCH v1 1/3] block: export blk-crypto symbols required by dm-inlinecrypt

[Linlin Zhang]

From: Eric Biggers <ebiggers@google.com>

bio_crypt_set_ctx(), blk_crypto_init_key(), and
blk_crypto_start_using_key() are needed to use inline encryption; see
Documentation/block/inline-encryption.rst.  Export them so that
dm-inlinecrypt can use them.  The only reason these weren't exported
before was that inline encryption was previously used only by fs/crypto/
which is built-in code.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 block/blk-crypto.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/blk-crypto.c b/block/blk-crypto.c
index 856d3c5b1fa0..40a99a859748 100644
--- a/block/blk-crypto.c
+++ b/block/blk-crypto.c
@@ -116,6 +116,7 @@ void bio_crypt_set_ctx(struct bio *bio, const struct blk_crypto_key *key,
 
 	bio->bi_crypt_context = bc;
 }
+EXPORT_SYMBOL_GPL(bio_crypt_set_ctx);
 
 void __bio_crypt_free_ctx(struct bio *bio)
 {
@@ -349,6 +350,7 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key,
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(blk_crypto_init_key);
 
 bool blk_crypto_config_supported_natively(struct block_device *bdev,
 					  const struct blk_crypto_config *cfg)
@@ -399,6 +401,7 @@ int blk_crypto_start_using_key(struct block_device *bdev,
 	}
 	return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode);
 }
+EXPORT_SYMBOL_GPL(blk_crypto_start_using_key);
 
 /**
  * blk_crypto_evict_key() - Evict a blk_crypto_key from a block_device
-- 
2.34.1

Re: [PATCH v1 1/3] block: export blk-crypto symbols required by dm-inlinecrypt

[Mikulas Patocka]

Hi Jens

Would you please ack this block layer patch, so that I can add it to the 
device mapper tree?

Mikulas


On Wed, 4 Mar 2026, Linlin Zhang wrote:

> From: Eric Biggers <ebiggers@google.com>
> 
> bio_crypt_set_ctx(), blk_crypto_init_key(), and
> blk_crypto_start_using_key() are needed to use inline encryption; see
> Documentation/block/inline-encryption.rst.  Export them so that
> dm-inlinecrypt can use them.  The only reason these weren't exported
> before was that inline encryption was previously used only by fs/crypto/
> which is built-in code.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  block/blk-crypto.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/block/blk-crypto.c b/block/blk-crypto.c
> index 856d3c5b1fa0..40a99a859748 100644
> --- a/block/blk-crypto.c
> +++ b/block/blk-crypto.c
> @@ -116,6 +116,7 @@ void bio_crypt_set_ctx(struct bio *bio, const struct blk_crypto_key *key,
>  
>  	bio->bi_crypt_context = bc;
>  }
> +EXPORT_SYMBOL_GPL(bio_crypt_set_ctx);
>  
>  void __bio_crypt_free_ctx(struct bio *bio)
>  {
> @@ -349,6 +350,7 @@ int blk_crypto_init_key(struct blk_crypto_key *blk_key,
>  
>  	return 0;
>  }
> +EXPORT_SYMBOL_GPL(blk_crypto_init_key);
>  
>  bool blk_crypto_config_supported_natively(struct block_device *bdev,
>  					  const struct blk_crypto_config *cfg)
> @@ -399,6 +401,7 @@ int blk_crypto_start_using_key(struct block_device *bdev,
>  	}
>  	return blk_crypto_fallback_start_using_mode(key->crypto_cfg.crypto_mode);
>  }
> +EXPORT_SYMBOL_GPL(blk_crypto_start_using_key);
>  
>  /**
>   * blk_crypto_evict_key() - Evict a blk_crypto_key from a block_device
> -- 
> 2.34.1
> 

Re: [PATCH v1 1/3] block: export blk-crypto symbols required by dm-inlinecrypt

[Jens Axboe]

On 3/4/26 5:17 AM, Linlin Zhang wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> bio_crypt_set_ctx(), blk_crypto_init_key(), and
> blk_crypto_start_using_key() are needed to use inline encryption; see
> Documentation/block/inline-encryption.rst.  Export them so that
> dm-inlinecrypt can use them.  The only reason these weren't exported
> before was that inline encryption was previously used only by fs/crypto/
> which is built-in code.

Reviewed-by: Jens Axboe <axboe@kernel.dk>

-- 
Jens Axboe

Re: [PATCH v1 1/3] block: export blk-crypto symbols required by dm-inlinecrypt

[Mikulas Patocka]

On Mon, 9 Mar 2026, Jens Axboe wrote:

> On 3/4/26 5:17 AM, Linlin Zhang wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > bio_crypt_set_ctx(), blk_crypto_init_key(), and
> > blk_crypto_start_using_key() are needed to use inline encryption; see
> > Documentation/block/inline-encryption.rst.  Export them so that
> > dm-inlinecrypt can use them.  The only reason these weren't exported
> > before was that inline encryption was previously used only by fs/crypto/
> > which is built-in code.
> 
> Reviewed-by: Jens Axboe <axboe@kernel.dk>
> 
> -- 
> Jens Axboe

Thanks.

Mikulas

[PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Linlin Zhang]

From: Eric Biggers <ebiggers@google.com>

Add a new device-mapper target "dm-inlinecrypt" that is similar to
dm-crypt but uses the blk-crypto API instead of the regular crypto API.
This allows it to take advantage of inline encryption hardware such as
that commonly built into UFS host controllers.

The table syntax matches dm-crypt's, but for now only a stripped-down
set of parameters is supported.  For example, for now AES-256-XTS is the
only supported cipher.

dm-inlinecrypt is based on Android's dm-default-key with the
controversial passthrough support removed.  Note that due to the removal
of passthrough support, use of dm-inlinecrypt in combination with
fscrypt causes double encryption of file contents (similar to dm-crypt +
fscrypt), with the fscrypt layer not being able to use the inline
encryption hardware.  This makes dm-inlinecrypt unusable on systems such
as Android that use fscrypt and where a more optimized approach is
needed.  It is however suitable as a replacement for dm-crypt.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
---
 drivers/md/Kconfig          |  10 +
 drivers/md/Makefile         |   1 +
 drivers/md/dm-inlinecrypt.c | 416 ++++++++++++++++++++++++++++++++++++
 3 files changed, 427 insertions(+)
 create mode 100644 drivers/md/dm-inlinecrypt.c

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index c58a9a8ea54e..aa541cc22ecc 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -313,6 +313,16 @@ config DM_CRYPT
 
 	  If unsure, say N.
 
+config DM_INLINECRYPT
+	tristate "Inline encryption target support"
+	depends on BLK_DEV_DM
+	depends on BLK_INLINE_ENCRYPTION
+	help
+	  This device-mapper target is similar to dm-crypt, but it uses the
+	  blk-crypto API instead of the regular crypto API. This allows it to
+	  take advantage of inline encryption hardware such as that commonly
+	  built into UFS host controllers.
+
 config DM_SNAPSHOT
        tristate "Snapshot target"
        depends on BLK_DEV_DM
diff --git a/drivers/md/Makefile b/drivers/md/Makefile
index c338cc6fbe2e..517d1f7d8288 100644
--- a/drivers/md/Makefile
+++ b/drivers/md/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DM_UNSTRIPED)	+= dm-unstripe.o
 obj-$(CONFIG_DM_BUFIO)		+= dm-bufio.o
 obj-$(CONFIG_DM_BIO_PRISON)	+= dm-bio-prison.o
 obj-$(CONFIG_DM_CRYPT)		+= dm-crypt.o
+obj-$(CONFIG_DM_INLINECRYPT)	+= dm-inlinecrypt.o
 obj-$(CONFIG_DM_DELAY)		+= dm-delay.o
 obj-$(CONFIG_DM_DUST)		+= dm-dust.o
 obj-$(CONFIG_DM_FLAKEY)		+= dm-flakey.o
diff --git a/drivers/md/dm-inlinecrypt.c b/drivers/md/dm-inlinecrypt.c
new file mode 100644
index 000000000000..251760da9f7e
--- /dev/null
+++ b/drivers/md/dm-inlinecrypt.c
@@ -0,0 +1,416 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2024 Google LLC
+ */
+
+#include <linux/blk-crypto.h>
+#include <linux/device-mapper.h>
+#include <linux/hex.h>
+#include <linux/module.h>
+
+#define DM_MSG_PREFIX	"inlinecrypt"
+
+static const struct dm_inlinecrypt_cipher {
+	const char *name;
+	enum blk_crypto_mode_num mode_num;
+	int key_size;
+} dm_inlinecrypt_ciphers[] = {
+	{
+		.name = "aes-xts-plain64",
+		.mode_num = BLK_ENCRYPTION_MODE_AES_256_XTS,
+		.key_size = 64,
+	},
+};
+
+/**
+ * struct inlinecrypt_ctx - private data of an inlinecrypt target
+ * @dev: the underlying device
+ * @start: starting sector of the range of @dev which this target actually maps.
+ *	   For this purpose a "sector" is 512 bytes.
+ * @cipher_string: the name of the encryption algorithm being used
+ * @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)
+ * @sector_bits: log2(sector_size)
+ * @key: the encryption key to use
+ * @max_dun: the maximum DUN that may be used (computed from other params)
+ */
+struct inlinecrypt_ctx {
+	struct dm_dev *dev;
+	sector_t start;
+	const char *cipher_string;
+	u64 iv_offset;
+	unsigned int sector_size;
+	unsigned int sector_bits;
+	struct blk_crypto_key key;
+	u64 max_dun;
+};
+
+static const struct dm_inlinecrypt_cipher *
+lookup_cipher(const char *cipher_string)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(dm_inlinecrypt_ciphers); i++) {
+		if (strcmp(cipher_string, dm_inlinecrypt_ciphers[i].name) == 0)
+			return &dm_inlinecrypt_ciphers[i];
+	}
+	return NULL;
+}
+
+static void inlinecrypt_dtr(struct dm_target *ti)
+{
+	struct inlinecrypt_ctx *ctx = ti->private;
+
+	if (ctx->dev) {
+		if (ctx->key.size)
+			blk_crypto_evict_key(ctx->dev->bdev, &ctx->key);
+		dm_put_device(ti, ctx->dev);
+	}
+	kfree_sensitive(ctx->cipher_string);
+	kfree_sensitive(ctx);
+}
+
+static int inlinecrypt_ctr_optional(struct dm_target *ti,
+				    unsigned int argc, char **argv)
+{
+	struct inlinecrypt_ctx *ctx = ti->private;
+	struct dm_arg_set as;
+	static const struct dm_arg _args[] = {
+		{0, 3, "Invalid number of feature args"},
+	};
+	unsigned int opt_params;
+	const char *opt_string;
+	bool iv_large_sectors = false;
+	char dummy;
+	int err;
+
+	as.argc = argc;
+	as.argv = argv;
+
+	err = dm_read_arg_group(_args, &as, &opt_params, &ti->error);
+	if (err)
+		return err;
+
+	while (opt_params--) {
+		opt_string = dm_shift_arg(&as);
+		if (!opt_string) {
+			ti->error = "Not enough feature arguments";
+			return -EINVAL;
+		}
+		if (!strcmp(opt_string, "allow_discards")) {
+			ti->num_discard_bios = 1;
+		} else if (sscanf(opt_string, "sector_size:%u%c",
+				  &ctx->sector_size, &dummy) == 1) {
+			if (ctx->sector_size < SECTOR_SIZE ||
+			    ctx->sector_size > 4096 ||
+			    !is_power_of_2(ctx->sector_size)) {
+				ti->error = "Invalid sector_size";
+				return -EINVAL;
+			}
+		} else if (!strcmp(opt_string, "iv_large_sectors")) {
+			iv_large_sectors = true;
+		} else {
+			ti->error = "Invalid feature arguments";
+			return -EINVAL;
+		}
+	}
+
+	/* dm-inlinecrypt doesn't implement iv_large_sectors=false. */
+	if (ctx->sector_size != SECTOR_SIZE && !iv_large_sectors) {
+		ti->error = "iv_large_sectors must be specified";
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
+ * Construct an inlinecrypt mapping:
+ * <cipher> <key> <iv_offset> <dev_path> <start>
+ *
+ * This syntax matches dm-crypt's, but the set of supported functionality has
+ * been stripped down.
+ */
+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];
+	unsigned int dun_bytes;
+	unsigned long long tmpll;
+	char dummy;
+	int err;
+
+	if (argc < 5) {
+		ti->error = "Not enough arguments";
+		return -EINVAL;
+	}
+
+	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+	if (!ctx) {
+		ti->error = "Out of memory";
+		return -ENOMEM;
+	}
+	ti->private = ctx;
+
+	/* <cipher> */
+	ctx->cipher_string = kstrdup(argv[0], GFP_KERNEL);
+	if (!ctx->cipher_string) {
+		ti->error = "Out of memory";
+		err = -ENOMEM;
+		goto bad;
+	}
+	cipher = lookup_cipher(ctx->cipher_string);
+	if (!cipher) {
+		ti->error = "Unsupported cipher";
+		err = -EINVAL;
+		goto bad;
+	}
+
+	/* <key> */
+	if (strlen(argv[1]) != 2 * cipher->key_size) {
+		ti->error = "Incorrect key size for cipher";
+		err = -EINVAL;
+		goto bad;
+	}
+	if (hex2bin(raw_key, argv[1], cipher->key_size) != 0) {
+		ti->error = "Malformed key string";
+		err = -EINVAL;
+		goto bad;
+	}
+
+	/* <iv_offset> */
+	if (sscanf(argv[2], "%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),
+			    &ctx->dev);
+	if (err) {
+		ti->error = "Device lookup failed";
+		goto bad;
+	}
+
+	/* <start> */
+	if (sscanf(argv[4], "%llu%c", &tmpll, &dummy) != 1 ||
+	    tmpll != (sector_t)tmpll) {
+		ti->error = "Invalid start sector";
+		err = -EINVAL;
+		goto bad;
+	}
+	ctx->start = tmpll;
+
+	/* optional arguments */
+	ctx->sector_size = SECTOR_SIZE;
+	if (argc > 5) {
+		err = inlinecrypt_ctr_optional(ti, argc - 5, &argv[5]);
+		if (err)
+			goto bad;
+	}
+	ctx->sector_bits = ilog2(ctx->sector_size);
+	if (ti->len & ((ctx->sector_size >> SECTOR_SHIFT) - 1)) {
+		ti->error = "Device size is not a multiple of sector_size";
+		err = -EINVAL;
+		goto bad;
+	}
+
+	ctx->max_dun = (ctx->iv_offset + ti->len - 1) >>
+		       (ctx->sector_bits - SECTOR_SHIFT);
+	dun_bytes = DIV_ROUND_UP(fls64(ctx->max_dun), 8);
+
+	err = blk_crypto_init_key(&ctx->key, raw_key, cipher->key_size,
+				  BLK_CRYPTO_KEY_TYPE_HW_WRAPPED, cipher->mode_num,
+				  dun_bytes, ctx->sector_size);
+	if (err) {
+		ti->error = "Error initializing blk-crypto key";
+		goto bad;
+	}
+
+	err = blk_crypto_start_using_key(ctx->dev->bdev, &ctx->key);
+	if (err) {
+		ti->error = "Error starting to use blk-crypto";
+		goto bad;
+	}
+
+	ti->num_flush_bios = 1;
+
+	err = 0;
+	goto out;
+
+bad:
+	inlinecrypt_dtr(ti);
+out:
+	memzero_explicit(raw_key, sizeof(raw_key));
+	return err;
+}
+
+static int inlinecrypt_map(struct dm_target *ti, struct bio *bio)
+{
+	const struct inlinecrypt_ctx *ctx = ti->private;
+	sector_t sector_in_target;
+	u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE] = {};
+
+	bio_set_dev(bio, ctx->dev->bdev);
+
+	/*
+	 * If the bio is a device-level request which doesn't target a specific
+	 * sector, there's nothing more to do.
+	 */
+	if (bio_sectors(bio) == 0)
+		return DM_MAPIO_REMAPPED;
+
+	/*
+	 * The bio should never have an encryption context already, since
+	 * dm-inlinecrypt doesn't pass through any inline encryption
+	 * capabilities to the layer above it.
+	 */
+	if (WARN_ON_ONCE(bio_has_crypt_ctx(bio)))
+		return DM_MAPIO_KILL;
+
+	/* Map the bio's sector to the underlying device. (512-byte sectors) */
+	sector_in_target = dm_target_offset(ti, bio->bi_iter.bi_sector);
+	bio->bi_iter.bi_sector = ctx->start + sector_in_target;
+	/*
+	 * If the bio doesn't have any data (e.g. if it's a DISCARD request),
+	 * there's nothing more to do.
+	 */
+	if (!bio_has_data(bio))
+		return DM_MAPIO_REMAPPED;
+
+	/* Calculate the DUN and enforce data-unit (crypto sector) alignment. */
+	dun[0] = ctx->iv_offset + sector_in_target; /* 512-byte sectors */
+	if (dun[0] & ((ctx->sector_size >> SECTOR_SHIFT) - 1))
+		return DM_MAPIO_KILL;
+	dun[0] >>= ctx->sector_bits - SECTOR_SHIFT; /* crypto sectors */
+
+	/*
+	 * This check isn't necessary as we should have calculated max_dun
+	 * correctly, but be safe.
+	 */
+	if (WARN_ON_ONCE(dun[0] > ctx->max_dun))
+		return DM_MAPIO_KILL;
+
+	bio_crypt_set_ctx(bio, &ctx->key, dun, GFP_NOIO);
+
+	return DM_MAPIO_REMAPPED;
+}
+
+static void inlinecrypt_status(struct dm_target *ti, status_type_t type,
+			       unsigned int status_flags, char *result,
+			       unsigned int maxlen)
+{
+	const struct inlinecrypt_ctx *ctx = ti->private;
+	unsigned int sz = 0;
+	int num_feature_args = 0;
+
+	switch (type) {
+	case STATUSTYPE_INFO:
+	case STATUSTYPE_IMA:
+		result[0] = '\0';
+		break;
+
+	case STATUSTYPE_TABLE:
+		/*
+		 * Warning: like dm-crypt, dm-inlinecrypt includes the key in
+		 * 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);
+		num_feature_args += !!ti->num_discard_bios;
+		if (ctx->sector_size != SECTOR_SIZE)
+			num_feature_args += 2;
+		if (num_feature_args != 0) {
+			DMEMIT(" %d", num_feature_args);
+			if (ti->num_discard_bios)
+				DMEMIT(" allow_discards");
+			if (ctx->sector_size != SECTOR_SIZE) {
+				DMEMIT(" sector_size:%u", ctx->sector_size);
+				DMEMIT(" iv_large_sectors");
+			}
+		}
+		break;
+	}
+}
+
+static int inlinecrypt_prepare_ioctl(struct dm_target *ti,
+				     struct block_device **bdev, unsigned int cmd,
+				     unsigned long arg, bool *forward)
+{
+	const struct inlinecrypt_ctx *ctx = ti->private;
+	const struct dm_dev *dev = ctx->dev;
+
+	*bdev = dev->bdev;
+
+	/* Only pass ioctls through if the device sizes match exactly. */
+	return ctx->start != 0 || ti->len != bdev_nr_sectors(dev->bdev);
+}
+
+static int inlinecrypt_iterate_devices(struct dm_target *ti,
+				       iterate_devices_callout_fn fn,
+				       void *data)
+{
+	const struct inlinecrypt_ctx *ctx = ti->private;
+
+	return fn(ti, ctx->dev, ctx->start, ti->len, data);
+}
+
+#ifdef CONFIG_BLK_DEV_ZONED
+static int inlinecrypt_report_zones(struct dm_target *ti,
+				    struct dm_report_zones_args *args,
+				    unsigned int nr_zones)
+{
+	const struct inlinecrypt_ctx *ctx = ti->private;
+
+	return dm_report_zones(ctx->dev->bdev, ctx->start,
+			ctx->start + dm_target_offset(ti, args->next_sector),
+			args, nr_zones);
+}
+#else
+#define inlinecrypt_report_zones NULL
+#endif
+
+static void inlinecrypt_io_hints(struct dm_target *ti,
+				 struct queue_limits *limits)
+{
+	const struct inlinecrypt_ctx *ctx = ti->private;
+	const unsigned int sector_size = ctx->sector_size;
+
+	limits->logical_block_size =
+		max_t(unsigned int, limits->logical_block_size, sector_size);
+	limits->physical_block_size =
+		max_t(unsigned int, limits->physical_block_size, sector_size);
+	limits->io_min = max_t(unsigned int, limits->io_min, sector_size);
+	limits->dma_alignment = limits->logical_block_size - 1;
+}
+
+static struct target_type inlinecrypt_target = {
+	.name			= "inlinecrypt",
+	.version		= {1, 0, 0},
+	/*
+	 * Do not set DM_TARGET_PASSES_CRYPTO, since dm-inlinecrypt consumes the
+	 * crypto capability itself.
+	 */
+	.features		= DM_TARGET_ZONED_HM,
+	.module			= THIS_MODULE,
+	.ctr			= inlinecrypt_ctr,
+	.dtr			= inlinecrypt_dtr,
+	.map			= inlinecrypt_map,
+	.status			= inlinecrypt_status,
+	.prepare_ioctl		= inlinecrypt_prepare_ioctl,
+	.iterate_devices	= inlinecrypt_iterate_devices,
+	.report_zones		= inlinecrypt_report_zones,
+	.io_hints		= inlinecrypt_io_hints,
+};
+
+module_dm(inlinecrypt);
+
+MODULE_AUTHOR("Eric Biggers <ebiggers@google.com>");
+MODULE_AUTHOR("Linlin Zhang <linlin.zhang@oss.qualcomm.com>");
+MODULE_DESCRIPTION(DM_NAME " target for inline encryption");
+MODULE_LICENSE("GPL");
-- 
2.34.1

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Milan Broz]

Hi,

just few comments below, but I am not DM maintainer so feel free to ignore it :)

On 3/4/26 1:17 PM, Linlin Zhang wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Add a new device-mapper target "dm-inlinecrypt" that is similar to
> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
> This allows it to take advantage of inline encryption hardware such as
> that commonly built into UFS host controllers.
> 
> The table syntax matches dm-crypt's, but for now only a stripped-down
> set of parameters is supported.  For example, for now AES-256-XTS is the
> only supported cipher.
> 
> dm-inlinecrypt is based on Android's dm-default-key with the
> controversial passthrough support removed.  Note that due to the removal
> of passthrough support, use of dm-inlinecrypt in combination with
> fscrypt causes double encryption of file contents (similar to dm-crypt +
> fscrypt), with the fscrypt layer not being able to use the inline
> encryption hardware.  This makes dm-inlinecrypt unusable on systems such
> as Android that use fscrypt and where a more optimized approach is
> needed.  It is however suitable as a replacement for dm-crypt.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> ---
>   drivers/md/Kconfig          |  10 +
>   drivers/md/Makefile         |   1 +
>   drivers/md/dm-inlinecrypt.c | 416 ++++++++++++++++++++++++++++++++++++

I think it should also add doc in
Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst
...

> +#define DM_MSG_PREFIX	"inlinecrypt"
> +
> +static const struct dm_inlinecrypt_cipher {
> +	const char *name;
> +	enum blk_crypto_mode_num mode_num;
> +	int key_size;
> +} dm_inlinecrypt_ciphers[] = {
> +	{
> +		.name = "aes-xts-plain64",
> +		.mode_num = BLK_ENCRYPTION_MODE_AES_256_XTS,
> +		.key_size = 64,

Hm. I can understand some translation table for this stupid
dm-crypt notation to inline enum, but why you need key size here?

Shouldn't there be some helper for inline crypt returning
keysize based on BLK_ENCRYPTION_MODE_AES_256_XTS?

I guess you have fixed cipher list already, but what about IV?
Is it always little-endian, or someone already reinvented plain64be (big-endian)?

...> +	while (opt_params--) {

...> +/*
> + * Construct an inlinecrypt mapping:
> + * <cipher> <key> <iv_offset> <dev_path> <start>

As above, it supports opt params, it should mention it here (or in doc).


...
> +	/* <key> */
> +	if (strlen(argv[1]) != 2 * cipher->key_size) {
> +		ti->error = "Incorrect key size for cipher";
> +		err = -EINVAL;
> +		goto bad;
> +	}
> +	if (hex2bin(raw_key, argv[1], cipher->key_size) != 0) {
> +		ti->error = "Malformed key string";
> +		err = -EINVAL;
> +		goto bad;
> +	}


Any reason it does not support keyring keys from the beginning?

...
> +static int inlinecrypt_map(struct dm_target *ti, struct bio *bio)

> +	/* Map the bio's sector to the underlying device. (512-byte sectors) */
> +	sector_in_target = dm_target_offset(ti, bio->bi_iter.bi_sector);
> +	bio->bi_iter.bi_sector = ctx->start + sector_in_target;
> +	/*
> +	 * If the bio doesn't have any data (e.g. if it's a DISCARD request),
> +	 * there's nothing more to do.
> +	 */

dmcrypt uses bio_set_dev() for REQ_PREFLUSH or REQ_OP_DISCARD, why this differs?

> +
> +	switch (type) {
> +	case STATUSTYPE_INFO:
> +	case STATUSTYPE_IMA:
> +		result[0] = '\0';

This should really emit audit information similar to dm-crypt.

> +		break;
> +
> +	case STATUSTYPE_TABLE:
> +		/*
> +		 * Warning: like dm-crypt, dm-inlinecrypt includes the key in
> +		 * the returned table.  Userspace is responsible for redacting
> +		 * the key when needed.

Again, why not support keyring format? LUKS2 uses it by default for dm-crypt table.

Milan

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Linlin Zhang]

On 3/4/2026 9:11 PM, Milan Broz wrote:
> Hi,
> 
> just few comments below, but I am not DM maintainer so feel free to ignore it :)
> 
> On 3/4/26 1:17 PM, Linlin Zhang wrote:
>> From: Eric Biggers <ebiggers@google.com>
>>
>> Add a new device-mapper target "dm-inlinecrypt" that is similar to
>> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
>> This allows it to take advantage of inline encryption hardware such as
>> that commonly built into UFS host controllers.
>>
>> The table syntax matches dm-crypt's, but for now only a stripped-down
>> set of parameters is supported.  For example, for now AES-256-XTS is the
>> only supported cipher.
>>
>> dm-inlinecrypt is based on Android's dm-default-key with the
>> controversial passthrough support removed.  Note that due to the removal
>> of passthrough support, use of dm-inlinecrypt in combination with
>> fscrypt causes double encryption of file contents (similar to dm-crypt +
>> fscrypt), with the fscrypt layer not being able to use the inline
>> encryption hardware.  This makes dm-inlinecrypt unusable on systems such
>> as Android that use fscrypt and where a more optimized approach is
>> needed.  It is however suitable as a replacement for dm-crypt.
>>
>> Signed-off-by: Eric Biggers <ebiggers@google.com>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> ---
>>   drivers/md/Kconfig          |  10 +
>>   drivers/md/Makefile         |   1 +
>>   drivers/md/dm-inlinecrypt.c | 416 ++++++++++++++++++++++++++++++++++++
> 
> I think it should also add doc in
> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst

Thanks for your review.
You're right. I'll add it in next patch.

> ...
> 
>> +#define DM_MSG_PREFIX    "inlinecrypt"
>> +
>> +static const struct dm_inlinecrypt_cipher {
>> +    const char *name;
>> +    enum blk_crypto_mode_num mode_num;
>> +    int key_size;
>> +} dm_inlinecrypt_ciphers[] = {
>> +    {
>> +        .name = "aes-xts-plain64",
>> +        .mode_num = BLK_ENCRYPTION_MODE_AES_256_XTS,
>> +        .key_size = 64,
> 
> Hm. I can understand some translation table for this stupid
> dm-crypt notation to inline enum, but why you need key size here?
> 
> Shouldn't there be some helper for inline crypt returning
> keysize based on BLK_ENCRYPTION_MODE_AES_256_XTS?

Similar to dm-default-key in Android (https://android.googlesource.com/kernel/common/+/android-mainline/drivers/md/dm-default-key.c),
key_size 64 here is always corresponding to a raw key. For a HW wrapped key, the key
size differs from different manufacturers. Linux kernel only constraints that the max
key size of HW wrapped key isn't larger than BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE(128).
So we get the actual key size based on the input key parameter received in ctr functions.

> 
> I guess you have fixed cipher list already, but what about IV?
> Is it always little-endian, or someone already reinvented plain64be (big-endian)?
> 
> ...> +    while (opt_params--) {
> 
> ...> +/*

Same to dm-crypt, 'plain64' in "aes-xts-plain64" of cipher name is the IV mode. It uses
the 64‑bit little‑endian sector number as the IV.


>> + * Construct an inlinecrypt mapping:
>> + * <cipher> <key> <iv_offset> <dev_path> <start>
> 
> As above, it supports opt params, it should mention it here (or in doc).

ACK, refer to dm-crypt, I'll add it in doc.

> 
> 
> ...
>> +    /* <key> */
>> +    if (strlen(argv[1]) != 2 * cipher->key_size) {
>> +        ti->error = "Incorrect key size for cipher";
>> +        err = -EINVAL;
>> +        goto bad;
>> +    }
>> +    if (hex2bin(raw_key, argv[1], cipher->key_size) != 0) {
>> +        ti->error = "Malformed key string";
>> +        err = -EINVAL;
>> +        goto bad;
>> +    }
> 
> 
> Any reason it does not support keyring keys from the beginning?

No special reason. The implementation of `dm-inlinecrypt` was modeled after
'dm-default-key', which, in Android, does not support keyring keys.
I'll have a insight about keyring and dm-crypt, inspect how to add keyring support
in dm-inline-crypt.

> 
> ...
>> +static int inlinecrypt_map(struct dm_target *ti, struct bio *bio)
> 
>> +    /* Map the bio's sector to the underlying device. (512-byte sectors) */
>> +    sector_in_target = dm_target_offset(ti, bio->bi_iter.bi_sector);
>> +    bio->bi_iter.bi_sector = ctx->start + sector_in_target;
>> +    /*
>> +     * If the bio doesn't have any data (e.g. if it's a DISCARD request),
>> +     * there's nothing more to do.
>> +     */
> 
> dmcrypt uses bio_set_dev() for REQ_PREFLUSH or REQ_OP_DISCARD, why this differs?

bio_has_data() is a payload‑based check that decides whether an encryption context
is needed, while REQ_PREFLUSH and REQ_OP_DISCARD are semantic checks that ensure
flush and discard requests bypass the dm‑crypt processing pipeline to maintain
correct I/O ordering. As a result, the two mechanisms address different concerns
and are not interchangeable.

In addition, bio_has_data is called in the beginning of inlinecrypt_map, rather
in the conditional branch like dm-crypt. But they have same effect.

> 
>> +
>> +    switch (type) {
>> +    case STATUSTYPE_INFO:
>> +    case STATUSTYPE_IMA:
>> +        result[0] = '\0';
> 
> This should really emit audit information similar to dm-crypt.
> 
>> +        break;
>> +
>> +    case STATUSTYPE_TABLE:
>> +        /*
>> +         * Warning: like dm-crypt, dm-inlinecrypt includes the key in
>> +         * the returned table.  Userspace is responsible for redacting
>> +         * the key when needed.
> 
> Again, why not support keyring format? LUKS2 uses it by default for dm-crypt table.

ACK. Need support keyring format.
I see both hex key and keyring-based keys are supported in dm-crypt. can both of them
be supported in dm-inlinecrypt?

> 
> Milan
> 

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Eric Biggers]

On Wed, Mar 04, 2026 at 04:17:27AM -0800, Linlin Zhang wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Add a new device-mapper target "dm-inlinecrypt" that is similar to
> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
> This allows it to take advantage of inline encryption hardware such as
> that commonly built into UFS host controllers.
> 
> The table syntax matches dm-crypt's, but for now only a stripped-down
> set of parameters is supported.  For example, for now AES-256-XTS is the
> only supported cipher.
> 
> dm-inlinecrypt is based on Android's dm-default-key with the
> controversial passthrough support removed.  Note that due to the removal
> of passthrough support, use of dm-inlinecrypt in combination with
> fscrypt causes double encryption of file contents (similar to dm-crypt +
> fscrypt), with the fscrypt layer not being able to use the inline
> encryption hardware.  This makes dm-inlinecrypt unusable on systems such
> as Android that use fscrypt and where a more optimized approach is
> needed.  It is however suitable as a replacement for dm-crypt.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>

I don't think it's plausible that this new patch was actually tested.
The version I sent in 2024 was tested at the time
(https://lore.kernel.org/r/20241016232748.134211-3-ebiggers@kernel.org/),
but I see at least two things that would make this new patch not work.

First, the call to blk_crypto_init_key() will always fail, since it's
being passed BLK_CRYPTO_KEY_TYPE_HW_WRAPPED but using a 64-byte raw key.

It needs to be BLK_CRYPTO_KEY_TYPE_RAW.  (BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
support would make sense to add as an extra feature, once the basic raw
key support is working.  Note that when I sent the first version of this
patch, support for wrapped keys was not yet upstream at all.)

Second, since v7.0-rc1, submitters of bios don't automatically get
blk-crypto-fallback support; they need to request it explicitly.  So,
this patch will not work with blk-crypto-fallback anymore.

If you'd like to continue work on this patch, it might be helpful to
check the latest version of dm-default-key.c in "android-mainline"
(https://android.googlesource.com/kernel/common/+/android-mainline/drivers/md/dm-default-key.c)
and resynchronize this patch with it.  It already has the code to
correctly support both key types and blk-crypto-fallback, for example.

Either way, this patch also needs to be re-tested with the latest
upstream kernel, which doesn't seem to have happened unfortunately.

- Eric

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Mikulas Patocka]

On Thu, 12 Mar 2026, Eric Biggers wrote:

> On Wed, Mar 04, 2026 at 04:17:27AM -0800, Linlin Zhang wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Add a new device-mapper target "dm-inlinecrypt" that is similar to
> > dm-crypt but uses the blk-crypto API instead of the regular crypto API.
> > This allows it to take advantage of inline encryption hardware such as
> > that commonly built into UFS host controllers.
> > 
> > The table syntax matches dm-crypt's, but for now only a stripped-down
> > set of parameters is supported.  For example, for now AES-256-XTS is the
> > only supported cipher.
> > 
> > dm-inlinecrypt is based on Android's dm-default-key with the
> > controversial passthrough support removed.  Note that due to the removal
> > of passthrough support, use of dm-inlinecrypt in combination with
> > fscrypt causes double encryption of file contents (similar to dm-crypt +
> > fscrypt), with the fscrypt layer not being able to use the inline
> > encryption hardware.  This makes dm-inlinecrypt unusable on systems such
> > as Android that use fscrypt and where a more optimized approach is
> > needed.  It is however suitable as a replacement for dm-crypt.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> 
> I don't think it's plausible that this new patch was actually tested.
> The version I sent in 2024 was tested at the time
> (https://lore.kernel.org/r/20241016232748.134211-3-ebiggers@kernel.org/),
> but I see at least two things that would make this new patch not work.
> 
> First, the call to blk_crypto_init_key() will always fail, since it's
> being passed BLK_CRYPTO_KEY_TYPE_HW_WRAPPED but using a 64-byte raw key.
> 
> It needs to be BLK_CRYPTO_KEY_TYPE_RAW.  (BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
> support would make sense to add as an extra feature, once the basic raw
> key support is working.  Note that when I sent the first version of this
> patch, support for wrapped keys was not yet upstream at all.)
> 
> Second, since v7.0-rc1, submitters of bios don't automatically get
> blk-crypto-fallback support; they need to request it explicitly.  So,
> this patch will not work with blk-crypto-fallback anymore.
> 
> If you'd like to continue work on this patch, it might be helpful to
> check the latest version of dm-default-key.c in "android-mainline"
> (https://android.googlesource.com/kernel/common/+/android-mainline/drivers/md/dm-default-key.c)
> and resynchronize this patch with it.  It already has the code to
> correctly support both key types and blk-crypto-fallback, for example.
> 
> Either way, this patch also needs to be re-tested with the latest
> upstream kernel, which doesn't seem to have happened unfortunately.

OK. I dropped it.

Mikulas

> - Eric
> 

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Milan Broz]

On 3/13/26 2:25 PM, Mikulas Patocka wrote:
> On Thu, 12 Mar 2026, Eric Biggers wrote:
> 
>> On Wed, Mar 04, 2026 at 04:17:27AM -0800, Linlin Zhang wrote:
>>> From: Eric Biggers <ebiggers@google.com>
>>>
>>> Add a new device-mapper target "dm-inlinecrypt" that is similar to
>>> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
>>> This allows it to take advantage of inline encryption hardware such as
>>> that commonly built into UFS host controllers.

...

>> I don't think it's plausible that this new patch was actually tested.
>> The version I sent in 2024 was tested at the time
>> (https://lore.kernel.org/r/20241016232748.134211-3-ebiggers@kernel.org/),
>> but I see at least two things that would make this new patch not work.

What a waste of time... thanks.
> OK. I dropped it.

Well, the inline crypt has some advantages to proprietary internal
hw implementations (like self-encrypting drives)  - it can be actually validated
comparing to sw version.

Anyway, Mikulas, if this dm-inlinecrypt returns one day, please be
sure that we do not have security-related "regressions" like not supporting
keyring. There is no need for dm-inlinecrypt to keep key inside the mapping table.
The keyring code is in dm-crypt, it should be easy to adapt it here.

Thanks,
Milan

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Linlin Zhang]

On 3/13/2026 11:27 PM, Milan Broz wrote:
> On 3/13/26 2:25 PM, Mikulas Patocka wrote:
>> On Thu, 12 Mar 2026, Eric Biggers wrote:
>>
>>> On Wed, Mar 04, 2026 at 04:17:27AM -0800, Linlin Zhang wrote:
>>>> From: Eric Biggers <ebiggers@google.com>
>>>>
>>>> Add a new device-mapper target "dm-inlinecrypt" that is similar to
>>>> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
>>>> This allows it to take advantage of inline encryption hardware such as
>>>> that commonly built into UFS host controllers.
> 
> ...
> 
>>> I don't think it's plausible that this new patch was actually tested.
>>> The version I sent in 2024 was tested at the time
>>> (https://lore.kernel.org/r/20241016232748.134211-3-ebiggers@kernel.org/),
>>> but I see at least two things that would make this new patch not work.
> 
> What a waste of time... thanks.
>> OK. I dropped it.
> 
> Well, the inline crypt has some advantages to proprietary internal
> hw implementations (like self-encrypting drives)  - it can be actually validated
> comparing to sw version.
> 
> Anyway, Mikulas, if this dm-inlinecrypt returns one day, please be
> sure that we do not have security-related "regressions" like not supporting
> keyring. There is no need for dm-inlinecrypt to keep key inside the mapping table.
> The keyring code is in dm-crypt, it should be easy to adapt it here.
> 
> Thanks,
> Milan
> 

Thanks for your review.

I understood that supporting keyring here is to ensure no raw key exposed to
dm table. As implied by the name dm-inlinecrypt, the key used by dm-inlinecyrpt
is a wrapped key, rather raw key. Can we keep the wrapped key inside the mapping
table?
In other word, can dm-inlinecrypt support both keyring and hex key(key in mapping
table)?

Thanks,
Linlin

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Milan Broz]

On 3/25/26 12:57 PM, Linlin Zhang wrote:
> I understood that supporting keyring here is to ensure no raw key exposed to
> dm table. As implied by the name dm-inlinecrypt, the key used by dm-inlinecyrpt
> is a wrapped key, rather raw key. Can we keep the wrapped key inside the mapping
> table?

Whatever key it is, it allows activation of the encrypted device. And it does not
need to be cached inside device-mapper layer (in DM table).

> In other word, can dm-inlinecrypt support both keyring and hex key(key in mapping
> table)?

Yes, support both. There are situations user must use hexkey directly.
But IMO, keyring option should be supported from the beginning.

Thanks,
Milan

Re: [PATCH v1 2/3] dm-inlinecrypt: add target for inline block device encryption

[Linlin Zhang]

On 3/12/2026 3:01 PM, Eric Biggers wrote:
> On Wed, Mar 04, 2026 at 04:17:27AM -0800, Linlin Zhang wrote:
>> From: Eric Biggers <ebiggers@google.com>
>>
>> Add a new device-mapper target "dm-inlinecrypt" that is similar to
>> dm-crypt but uses the blk-crypto API instead of the regular crypto API.
>> This allows it to take advantage of inline encryption hardware such as
>> that commonly built into UFS host controllers.
>>
>> The table syntax matches dm-crypt's, but for now only a stripped-down
>> set of parameters is supported.  For example, for now AES-256-XTS is the
>> only supported cipher.
>>
>> dm-inlinecrypt is based on Android's dm-default-key with the
>> controversial passthrough support removed.  Note that due to the removal
>> of passthrough support, use of dm-inlinecrypt in combination with
>> fscrypt causes double encryption of file contents (similar to dm-crypt +
>> fscrypt), with the fscrypt layer not being able to use the inline
>> encryption hardware.  This makes dm-inlinecrypt unusable on systems such
>> as Android that use fscrypt and where a more optimized approach is
>> needed.  It is however suitable as a replacement for dm-crypt.
>>
>> Signed-off-by: Eric Biggers <ebiggers@google.com>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> 
> I don't think it's plausible that this new patch was actually tested.
> The version I sent in 2024 was tested at the time
> (https://lore.kernel.org/r/20241016232748.134211-3-ebiggers@kernel.org/),
> but I see at least two things that would make this new patch not work.
> 
> First, the call to blk_crypto_init_key() will always fail, since it's
> being passed BLK_CRYPTO_KEY_TYPE_HW_WRAPPED but using a 64-byte raw key.
> 
> It needs to be BLK_CRYPTO_KEY_TYPE_RAW.  (BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
> support would make sense to add as an extra feature, once the basic raw
> key support is working.  Note that when I sent the first version of this
> patch, support for wrapped keys was not yet upstream at all.)
Thanks for the review!
Yes, a mini change about key size validation is absent in this patch, which
leads to the failure of dm-table loading with dm-inlinecrypt target.
Similar to dm-default-key in Android, next patch updates ctr function to
ensure the key size not larger than BLK_CRYPTO_MAX_ANY_KEY_SIZE, and pass
this key size to blk_crypto_init_key().

> 
> Second, since v7.0-rc1, submitters of bios don't automatically get
> blk-crypto-fallback support; they need to request it explicitly.  So,
> this patch will not work with blk-crypto-fallback anymore.
> 
> If you'd like to continue work on this patch, it might be helpful to
> check the latest version of dm-default-key.c in "android-mainline"
> (https://android.googlesource.com/kernel/common/+/android-mainline/drivers/md/dm-default-key.c)
> and resynchronize this patch with it.  It already has the code to
> correctly support both key types and blk-crypto-fallback, for example.

ACK

> 
> Either way, this patch also needs to be re-tested with the latest
> upstream kernel, which doesn't seem to have happened unfortunately.

I'll share the test result on top of the latest upstream kernel in next patch.

> 
> - Eric

[PATCH v1 3/3] dm-inlinecrypt: Expose inline crypto caps to the device

[Linlin Zhang]

Add a new DM flag, which means the inline crypto capabilities
from underlying devices can be exposed to the DM device, and
the DM device consumes these capabilities, rather pass through
them to the upper layer.

Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
---
 drivers/md/dm-inlinecrypt.c   | 2 +-
 drivers/md/dm-table.c         | 3 ++-
 include/linux/device-mapper.h | 7 +++++++
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-inlinecrypt.c b/drivers/md/dm-inlinecrypt.c
index 251760da9f7e..eda56893d430 100644
--- a/drivers/md/dm-inlinecrypt.c
+++ b/drivers/md/dm-inlinecrypt.c
@@ -396,7 +396,7 @@ static struct target_type inlinecrypt_target = {
 	 * Do not set DM_TARGET_PASSES_CRYPTO, since dm-inlinecrypt consumes the
 	 * crypto capability itself.
 	 */
-	.features		= DM_TARGET_ZONED_HM,
+	.features		= DM_TARGET_CONSUME_CRYPTO | DM_TARGET_ZONED_HM,
 	.module			= THIS_MODULE,
 	.ctr			= inlinecrypt_ctr,
 	.dtr			= inlinecrypt_dtr,
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 7be1d8dc8bdd..f0580935394a 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -1407,7 +1407,8 @@ static int dm_table_construct_crypto_profile(struct dm_table *t)
 	for (i = 0; i < t->num_targets; i++) {
 		struct dm_target *ti = dm_table_get_target(t, i);
 
-		if (!dm_target_passes_crypto(ti->type)) {
+		if (!dm_target_passes_crypto(ti->type)
+				&& !dm_target_consume_crypto(ti->type)) {
 			blk_crypto_intersect_capabilities(profile, NULL);
 			break;
 		}
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 38f625af6ab4..6abd1b4fcb76 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -306,6 +306,13 @@ struct target_type {
 #define dm_target_supports_mixed_zoned_model(type) (false)
 #endif
 
+/*
+ * A target consumes inline crypto capabilities itself and doesn't support
+ * passing through inline crypto support.
+ */
+#define DM_TARGET_CONSUME_CRYPTO		0x00000300
+#define dm_target_consume_crypto(type) ((type)->features & DM_TARGET_CONSUME_CRYPTO)
+
 #define DM_TARGET_ATOMIC_WRITES		0x00000400
 #define dm_target_supports_atomic_writes(type) ((type)->features & DM_TARGET_ATOMIC_WRITES)
 
-- 
2.34.1

Re: [PATCH v1 3/3] dm-inlinecrypt: Expose inline crypto caps to the device

[Eric Biggers]

On Wed, Mar 04, 2026 at 04:17:28AM -0800, Linlin Zhang wrote:
> Add a new DM flag, which means the inline crypto capabilities
> from underlying devices can be exposed to the DM device, and
> the DM device consumes these capabilities, rather pass through
> them to the upper layer.
> 
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> ---
>  drivers/md/dm-inlinecrypt.c   | 2 +-
>  drivers/md/dm-table.c         | 3 ++-
>  include/linux/device-mapper.h | 7 +++++++
>  3 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/md/dm-inlinecrypt.c b/drivers/md/dm-inlinecrypt.c
> index 251760da9f7e..eda56893d430 100644
> --- a/drivers/md/dm-inlinecrypt.c
> +++ b/drivers/md/dm-inlinecrypt.c
> @@ -396,7 +396,7 @@ static struct target_type inlinecrypt_target = {
>  	 * Do not set DM_TARGET_PASSES_CRYPTO, since dm-inlinecrypt consumes the
>  	 * crypto capability itself.
>  	 */
> -	.features		= DM_TARGET_ZONED_HM,
> +	.features		= DM_TARGET_CONSUME_CRYPTO | DM_TARGET_ZONED_HM,
>  	.module			= THIS_MODULE,
>  	.ctr			= inlinecrypt_ctr,
>  	.dtr			= inlinecrypt_dtr,
> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
> index 7be1d8dc8bdd..f0580935394a 100644
> --- a/drivers/md/dm-table.c
> +++ b/drivers/md/dm-table.c
> @@ -1407,7 +1407,8 @@ static int dm_table_construct_crypto_profile(struct dm_table *t)
>  	for (i = 0; i < t->num_targets; i++) {
>  		struct dm_target *ti = dm_table_get_target(t, i);
>  
> -		if (!dm_target_passes_crypto(ti->type)) {
> +		if (!dm_target_passes_crypto(ti->type)
> +				&& !dm_target_consume_crypto(ti->type)) {
>  			blk_crypto_intersect_capabilities(profile, NULL);
>  			break;
>  		}
> diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
> index 38f625af6ab4..6abd1b4fcb76 100644
> --- a/include/linux/device-mapper.h
> +++ b/include/linux/device-mapper.h
> @@ -306,6 +306,13 @@ struct target_type {
>  #define dm_target_supports_mixed_zoned_model(type) (false)
>  #endif
>  
> +/*
> + * A target consumes inline crypto capabilities itself and doesn't support
> + * passing through inline crypto support.
> + */
> +#define DM_TARGET_CONSUME_CRYPTO		0x00000300
> +#define dm_target_consume_crypto(type) ((type)->features & DM_TARGET_CONSUME_CRYPTO)

This patch doesn't make any sense.  First, no new flag is needed, as the
behavior is already correct if you just leave DM_TARGET_PASSES_CRYPTO
unset, as far as I can tell.  Second, the new flag is numerically equal
to DM_TARGET_PASSES_CRYPTO|CONFIG_BLK_DEV_ZONED.  Third, even if it had
a unique bit as seems to have been intended, the behavior is the same as
DM_TARGET_PASSES_CRYPTO, which should not be used on this target.

- Eric

Re: [PATCH v1 3/3] dm-inlinecrypt: Expose inline crypto caps to the device

[Mikulas Patocka]

On Wed, 11 Mar 2026, Eric Biggers wrote:

> On Wed, Mar 04, 2026 at 04:17:28AM -0800, Linlin Zhang wrote:
> > Add a new DM flag, which means the inline crypto capabilities
> > from underlying devices can be exposed to the DM device, and
> > the DM device consumes these capabilities, rather pass through
> > them to the upper layer.
> > 
> > Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> > ---
> >  drivers/md/dm-inlinecrypt.c   | 2 +-
> >  drivers/md/dm-table.c         | 3 ++-
> >  include/linux/device-mapper.h | 7 +++++++
> >  3 files changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/md/dm-inlinecrypt.c b/drivers/md/dm-inlinecrypt.c
> > index 251760da9f7e..eda56893d430 100644
> > --- a/drivers/md/dm-inlinecrypt.c
> > +++ b/drivers/md/dm-inlinecrypt.c
> > @@ -396,7 +396,7 @@ static struct target_type inlinecrypt_target = {
> >  	 * Do not set DM_TARGET_PASSES_CRYPTO, since dm-inlinecrypt consumes the
> >  	 * crypto capability itself.
> >  	 */
> > -	.features		= DM_TARGET_ZONED_HM,
> > +	.features		= DM_TARGET_CONSUME_CRYPTO | DM_TARGET_ZONED_HM,
> >  	.module			= THIS_MODULE,
> >  	.ctr			= inlinecrypt_ctr,
> >  	.dtr			= inlinecrypt_dtr,
> > diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
> > index 7be1d8dc8bdd..f0580935394a 100644
> > --- a/drivers/md/dm-table.c
> > +++ b/drivers/md/dm-table.c
> > @@ -1407,7 +1407,8 @@ static int dm_table_construct_crypto_profile(struct dm_table *t)
> >  	for (i = 0; i < t->num_targets; i++) {
> >  		struct dm_target *ti = dm_table_get_target(t, i);
> >  
> > -		if (!dm_target_passes_crypto(ti->type)) {
> > +		if (!dm_target_passes_crypto(ti->type)
> > +				&& !dm_target_consume_crypto(ti->type)) {
> >  			blk_crypto_intersect_capabilities(profile, NULL);
> >  			break;
> >  		}
> > diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
> > index 38f625af6ab4..6abd1b4fcb76 100644
> > --- a/include/linux/device-mapper.h
> > +++ b/include/linux/device-mapper.h
> > @@ -306,6 +306,13 @@ struct target_type {
> >  #define dm_target_supports_mixed_zoned_model(type) (false)
> >  #endif
> >  
> > +/*
> > + * A target consumes inline crypto capabilities itself and doesn't support
> > + * passing through inline crypto support.
> > + */
> > +#define DM_TARGET_CONSUME_CRYPTO		0x00000300
> > +#define dm_target_consume_crypto(type) ((type)->features & DM_TARGET_CONSUME_CRYPTO)
> 
> This patch doesn't make any sense.  First, no new flag is needed, as the
> behavior is already correct if you just leave DM_TARGET_PASSES_CRYPTO
> unset, as far as I can tell.  Second, the new flag is numerically equal
> to DM_TARGET_PASSES_CRYPTO|CONFIG_BLK_DEV_ZONED.  Third, even if it had
> a unique bit as seems to have been intended, the behavior is the same as
> DM_TARGET_PASSES_CRYPTO, which should not be used on this target.
> 
> - Eric

OK, I'm dropping this patch from the linux-dm/for-next branch. Thanks for 
review.

Mikulas

Re: [PATCH v1 3/3] dm-inlinecrypt: Expose inline crypto caps to the device

[Linlin Zhang]

On 3/12/2026 2:35 PM, Eric Biggers wrote:
> On Wed, Mar 04, 2026 at 04:17:28AM -0800, Linlin Zhang wrote:
>> Add a new DM flag, which means the inline crypto capabilities
>> from underlying devices can be exposed to the DM device, and
>> the DM device consumes these capabilities, rather pass through
>> them to the upper layer.
>>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> ---
>>  drivers/md/dm-inlinecrypt.c   | 2 +-
>>  drivers/md/dm-table.c         | 3 ++-
>>  include/linux/device-mapper.h | 7 +++++++
>>  3 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/md/dm-inlinecrypt.c b/drivers/md/dm-inlinecrypt.c
>> index 251760da9f7e..eda56893d430 100644
>> --- a/drivers/md/dm-inlinecrypt.c
>> +++ b/drivers/md/dm-inlinecrypt.c
>> @@ -396,7 +396,7 @@ static struct target_type inlinecrypt_target = {
>>  	 * Do not set DM_TARGET_PASSES_CRYPTO, since dm-inlinecrypt consumes the
>>  	 * crypto capability itself.
>>  	 */
>> -	.features		= DM_TARGET_ZONED_HM,
>> +	.features		= DM_TARGET_CONSUME_CRYPTO | DM_TARGET_ZONED_HM,
>>  	.module			= THIS_MODULE,
>>  	.ctr			= inlinecrypt_ctr,
>>  	.dtr			= inlinecrypt_dtr,
>> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
>> index 7be1d8dc8bdd..f0580935394a 100644
>> --- a/drivers/md/dm-table.c
>> +++ b/drivers/md/dm-table.c
>> @@ -1407,7 +1407,8 @@ static int dm_table_construct_crypto_profile(struct dm_table *t)
>>  	for (i = 0; i < t->num_targets; i++) {
>>  		struct dm_target *ti = dm_table_get_target(t, i);
>>  
>> -		if (!dm_target_passes_crypto(ti->type)) {
>> +		if (!dm_target_passes_crypto(ti->type)
>> +				&& !dm_target_consume_crypto(ti->type)) {
>>  			blk_crypto_intersect_capabilities(profile, NULL);
>>  			break;
>>  		}
>> diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
>> index 38f625af6ab4..6abd1b4fcb76 100644
>> --- a/include/linux/device-mapper.h
>> +++ b/include/linux/device-mapper.h
>> @@ -306,6 +306,13 @@ struct target_type {
>>  #define dm_target_supports_mixed_zoned_model(type) (false)
>>  #endif
>>  
>> +/*
>> + * A target consumes inline crypto capabilities itself and doesn't support
>> + * passing through inline crypto support.
>> + */
>> +#define DM_TARGET_CONSUME_CRYPTO		0x00000300
>> +#define dm_target_consume_crypto(type) ((type)->features & DM_TARGET_CONSUME_CRYPTO)
> 
> This patch doesn't make any sense.  First, no new flag is needed, as the
> behavior is already correct if you just leave DM_TARGET_PASSES_CRYPTO
> unset, as far as I can tell.  Second, the new flag is numerically equal
> to DM_TARGET_PASSES_CRYPTO|CONFIG_BLK_DEV_ZONED.  Third, even if it had
> a unique bit as seems to have been intended, the behavior is the same as
> DM_TARGET_PASSES_CRYPTO, which should not be used on this target.

Thanks for your review!

ACK. The key can be evicted through the real block device (the backend of DM device) during
the removal of DM device when a blk-crypto-profile isn't tied to a DM device.
I'll remove this patch in the next review.

> 
> - Eric

Re: [PATCH v1 0/3] dm-inlinecrypt: add target for inline block device encryption

[Christoph Hellwig]

What is the use case for this?  I'd much rather add fscrypt support
to file systems that are missing it than forcing another stacking
layer.

Re: [PATCH v1 0/3] dm-inlinecrypt: add target for inline block device encryption

[Adrian Vovk]

Hello Christoph,

On Wed, Mar 4, 2026 at 8:06 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> What is the use case for this?  I'd much rather add fscrypt support
> to file systems that are missing it than forcing another stacking
> layer.

Maybe I am misunderstanding something, but this seems orthogonal to
fscrypt? Userspace would use this to do LUKS full-disk encryption, but
with the hardware acceleration provided by the inline encryption
hardware.

Best,
Adrian

Re: [PATCH v1 0/3] dm-inlinecrypt: add target for inline block device encryption

[Christoph Hellwig]

On Wed, Mar 04, 2026 at 01:02:41PM -0500, Adrian Vovk wrote:
> Hello Christoph,
> 
> Maybe I am misunderstanding something, but this seems orthogonal to
> fscrypt? Userspace would use this to do LUKS full-disk encryption, but with
> the hardware acceleration provided by the inline encryption hardware.

Ok, if people really still want to do that that should be ok.

Re: [PATCH v1 0/3] dm-inlinecrypt: add target for inline block device encryption

[Linlin Zhang]

On 3/5/2026 10:38 PM, Christoph Hellwig wrote:
> On Wed, Mar 04, 2026 at 01:02:41PM -0500, Adrian Vovk wrote:
>> Hello Christoph,
>>
>> Maybe I am misunderstanding something, but this seems orthogonal to
>> fscrypt? Userspace would use this to do LUKS full-disk encryption, but with
>> the hardware acceleration provided by the inline encryption hardware.
> 
> Ok, if people really still want to do that that should be ok.
> 

Thanks for your review!

Yes, this new dm-target type is designed for the Full-Disk Encryption with
inline encryption hardware used scenario.
I believe it's necessary as dm-crypt only provide software encryption, the hardware
acceleration provided by the inline encryption hardware for Full-Disk Encryption
is always what the customer wants, like File-based Encryption with Inline Crypto
Engine supported.