[PATCH v2 0/2] dm: pass through operations on wrapped inline crypto keys

[PATCH v2 0/2] dm: pass through operations on wrapped inline crypto keys

[Eric Biggers]

This series makes the device-mapper layer pass through the blk-crypto
wrapped key operations when underlying devices support them.

This is targeting linux-dm/dm-6.16.

Changed in v2:
  - Call dm_put_live_table() even when dm_get_live_table() returns NULL.

Eric Biggers (2):
  blk-crypto: export wrapped key functions
  dm: pass through operations on wrapped inline crypto keys

 block/blk-crypto-profile.c |   4 +
 drivers/md/dm-table.c      | 177 +++++++++++++++++++++++++++++++++++++
 2 files changed, 181 insertions(+)


base-commit: d5d16fabe431d1f7b822cf03f54e7186b284b7bd
-- 
2.49.0

[PATCH v2 1/2] blk-crypto: export wrapped key functions

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Export blk_crypto_derive_sw_secret(), blk_crypto_import_key(),
blk_crypto_generate_key(), and blk_crypto_prepare_key() so that they can
be used by device-mapper when passing through wrapped key support.

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

diff --git a/block/blk-crypto-profile.c b/block/blk-crypto-profile.c
index 94a155912bf1c..81918f6e0caea 100644
--- a/block/blk-crypto-profile.c
+++ b/block/blk-crypto-profile.c
@@ -499,10 +499,11 @@ int blk_crypto_derive_sw_secret(struct block_device *bdev,
 	err = profile->ll_ops.derive_sw_secret(profile, eph_key, eph_key_size,
 					       sw_secret);
 	blk_crypto_hw_exit(profile);
 	return err;
 }
+EXPORT_SYMBOL_GPL(blk_crypto_derive_sw_secret);
 
 int blk_crypto_import_key(struct blk_crypto_profile *profile,
 			  const u8 *raw_key, size_t raw_key_size,
 			  u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
 {
@@ -518,10 +519,11 @@ int blk_crypto_import_key(struct blk_crypto_profile *profile,
 	ret = profile->ll_ops.import_key(profile, raw_key, raw_key_size,
 					 lt_key);
 	blk_crypto_hw_exit(profile);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(blk_crypto_import_key);
 
 int blk_crypto_generate_key(struct blk_crypto_profile *profile,
 			    u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
 {
 	int ret;
@@ -535,10 +537,11 @@ int blk_crypto_generate_key(struct blk_crypto_profile *profile,
 	blk_crypto_hw_enter(profile);
 	ret = profile->ll_ops.generate_key(profile, lt_key);
 	blk_crypto_hw_exit(profile);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(blk_crypto_generate_key);
 
 int blk_crypto_prepare_key(struct blk_crypto_profile *profile,
 			   const u8 *lt_key, size_t lt_key_size,
 			   u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
 {
@@ -554,10 +557,11 @@ int blk_crypto_prepare_key(struct blk_crypto_profile *profile,
 	ret = profile->ll_ops.prepare_key(profile, lt_key, lt_key_size,
 					  eph_key);
 	blk_crypto_hw_exit(profile);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(blk_crypto_prepare_key);
 
 /**
  * blk_crypto_intersect_capabilities() - restrict supported crypto capabilities
  *					 by child device
  * @parent: the crypto profile for the parent device
-- 
2.49.0

[PATCH v2 2/2] dm: pass through operations on wrapped inline crypto keys

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Make the device-mapper layer pass through the derive_sw_secret,
import_key, generate_key, and prepare_key blk-crypto operations when all
underlying devices support hardware-wrapped inline crypto keys and are
passing through inline crypto support.

Commit ebc4176551cd ("blk-crypto: add basic hardware-wrapped key
support") already made BLK_CRYPTO_KEY_TYPE_HW_WRAPPED be passed through
in the same way that the other crypto capabilities are.  But the wrapped
key support also includes additional operations in blk_crypto_ll_ops,
and the dm layer needs to implement those to pass them through.
derive_sw_secret is needed by fscrypt, while the other operations are
needed for the new blk-crypto ioctls to work on device-mapper devices
and not just the raw partitions.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/md/dm-table.c | 177 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 177 insertions(+)

diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index a937e1e12482e..0a71bedff81c5 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -1189,10 +1189,180 @@ static int dm_keyslot_evict(struct blk_crypto_profile *profile,
 
 	dm_put_live_table(md, srcu_idx);
 	return 0;
 }
 
+enum dm_wrappedkey_op {
+	DERIVE_SW_SECRET,
+	IMPORT_KEY,
+	GENERATE_KEY,
+	PREPARE_KEY,
+};
+
+struct dm_wrappedkey_op_args {
+	enum dm_wrappedkey_op op;
+	int err;
+	union {
+		struct {
+			const u8 *eph_key;
+			size_t eph_key_size;
+			u8 *sw_secret;
+		} derive_sw_secret;
+		struct {
+			const u8 *raw_key;
+			size_t raw_key_size;
+			u8 *lt_key;
+		} import_key;
+		struct {
+			u8 *lt_key;
+		} generate_key;
+		struct {
+			const u8 *lt_key;
+			size_t lt_key_size;
+			u8 *eph_key;
+		} prepare_key;
+	};
+};
+
+static int dm_wrappedkey_op_callback(struct dm_target *ti, struct dm_dev *dev,
+				     sector_t start, sector_t len, void *data)
+{
+	struct dm_wrappedkey_op_args *args = data;
+	struct block_device *bdev = dev->bdev;
+	struct blk_crypto_profile *profile =
+		bdev_get_queue(bdev)->crypto_profile;
+	int err = -EOPNOTSUPP;
+
+	if (!args->err)
+		return 0;
+
+	switch (args->op) {
+	case DERIVE_SW_SECRET:
+		err = blk_crypto_derive_sw_secret(
+					bdev,
+					args->derive_sw_secret.eph_key,
+					args->derive_sw_secret.eph_key_size,
+					args->derive_sw_secret.sw_secret);
+		break;
+	case IMPORT_KEY:
+		err = blk_crypto_import_key(profile,
+					    args->import_key.raw_key,
+					    args->import_key.raw_key_size,
+					    args->import_key.lt_key);
+		break;
+	case GENERATE_KEY:
+		err = blk_crypto_generate_key(profile,
+					      args->generate_key.lt_key);
+		break;
+	case PREPARE_KEY:
+		err = blk_crypto_prepare_key(profile,
+					     args->prepare_key.lt_key,
+					     args->prepare_key.lt_key_size,
+					     args->prepare_key.eph_key);
+		break;
+	}
+	args->err = err;
+
+	/* Try another device in case this fails. */
+	return 0;
+}
+
+static int dm_exec_wrappedkey_op(struct blk_crypto_profile *profile,
+				 struct dm_wrappedkey_op_args *args)
+{
+	struct mapped_device *md =
+		container_of(profile, struct dm_crypto_profile, profile)->md;
+	struct dm_target *ti;
+	struct dm_table *t;
+	int srcu_idx;
+	int i;
+
+	args->err = -EOPNOTSUPP;
+
+	t = dm_get_live_table(md, &srcu_idx);
+	if (!t)
+		goto out;
+
+	/*
+	 * blk-crypto currently has no support for multiple incompatible
+	 * implementations of wrapped inline crypto keys on a single system.
+	 * It was already checked earlier that support for wrapped keys was
+	 * declared on all underlying devices.  Thus, all the underlying devices
+	 * should support all wrapped key operations and they should behave
+	 * identically, i.e. work with the same keys.  So, just executing the
+	 * operation on the first device on which it works suffices for now.
+	 */
+	for (i = 0; i < t->num_targets; i++) {
+		ti = dm_table_get_target(t, i);
+		if (!ti->type->iterate_devices)
+			continue;
+		ti->type->iterate_devices(ti, dm_wrappedkey_op_callback, args);
+		if (!args->err)
+			break;
+	}
+out:
+	dm_put_live_table(md, srcu_idx);
+	return args->err;
+}
+
+static int dm_derive_sw_secret(struct blk_crypto_profile *profile,
+			       const u8 *eph_key, size_t eph_key_size,
+			       u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE])
+{
+	struct dm_wrappedkey_op_args args = {
+		.op = DERIVE_SW_SECRET,
+		.derive_sw_secret = {
+			.eph_key = eph_key,
+			.eph_key_size = eph_key_size,
+			.sw_secret = sw_secret,
+		},
+	};
+	return dm_exec_wrappedkey_op(profile, &args);
+}
+
+static int dm_import_key(struct blk_crypto_profile *profile,
+			 const u8 *raw_key, size_t raw_key_size,
+			 u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct dm_wrappedkey_op_args args = {
+		.op = IMPORT_KEY,
+		.import_key = {
+			.raw_key = raw_key,
+			.raw_key_size = raw_key_size,
+			.lt_key = lt_key,
+		},
+	};
+	return dm_exec_wrappedkey_op(profile, &args);
+}
+
+static int dm_generate_key(struct blk_crypto_profile *profile,
+			   u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct dm_wrappedkey_op_args args = {
+		.op = GENERATE_KEY,
+		.generate_key = {
+			.lt_key = lt_key,
+		},
+	};
+	return dm_exec_wrappedkey_op(profile, &args);
+}
+
+static int dm_prepare_key(struct blk_crypto_profile *profile,
+			  const u8 *lt_key, size_t lt_key_size,
+			  u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct dm_wrappedkey_op_args args = {
+		.op = PREPARE_KEY,
+		.prepare_key = {
+			.lt_key = lt_key,
+			.lt_key_size = lt_key_size,
+			.eph_key = eph_key,
+		},
+	};
+	return dm_exec_wrappedkey_op(profile, &args);
+}
+
 static int
 device_intersect_crypto_capabilities(struct dm_target *ti, struct dm_dev *dev,
 				     sector_t start, sector_t len, void *data)
 {
 	struct blk_crypto_profile *parent = data;
@@ -1263,10 +1433,17 @@ static int dm_table_construct_crypto_profile(struct dm_table *t)
 		ti->type->iterate_devices(ti,
 					  device_intersect_crypto_capabilities,
 					  profile);
 	}
 
+	if (profile->key_types_supported & BLK_CRYPTO_KEY_TYPE_HW_WRAPPED) {
+		profile->ll_ops.derive_sw_secret = dm_derive_sw_secret;
+		profile->ll_ops.import_key = dm_import_key;
+		profile->ll_ops.generate_key = dm_generate_key;
+		profile->ll_ops.prepare_key = dm_prepare_key;
+	}
+
 	if (t->md->queue &&
 	    !blk_crypto_has_capabilities(profile,
 					 t->md->queue->crypto_profile)) {
 		DMERR("Inline encryption capabilities of new DM table were more restrictive than the old table's. This is not supported!");
 		dm_destroy_crypto_profile(profile);
-- 
2.49.0

Re: [PATCH v2 2/2] dm: pass through operations on wrapped inline crypto keys

[Mikulas Patocka]

On Thu, 1 May 2025, Eric Biggers wrote:

> From: Eric Biggers <ebiggers@google.com>
> 
> Make the device-mapper layer pass through the derive_sw_secret,
> import_key, generate_key, and prepare_key blk-crypto operations when all
> underlying devices support hardware-wrapped inline crypto keys and are
> passing through inline crypto support.
> 
> Commit ebc4176551cd ("blk-crypto: add basic hardware-wrapped key
> support") already made BLK_CRYPTO_KEY_TYPE_HW_WRAPPED be passed through
> in the same way that the other crypto capabilities are.  But the wrapped
> key support also includes additional operations in blk_crypto_ll_ops,
> and the dm layer needs to implement those to pass them through.
> derive_sw_secret is needed by fscrypt, while the other operations are
> needed for the new blk-crypto ioctls to work on device-mapper devices
> and not just the raw partitions.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  drivers/md/dm-table.c | 177 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 177 insertions(+)
> 
> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
> index a937e1e12482e..0a71bedff81c5 100644
> --- a/drivers/md/dm-table.c
> +++ b/drivers/md/dm-table.c
> +
> +static int dm_exec_wrappedkey_op(struct blk_crypto_profile *profile,
> +				 struct dm_wrappedkey_op_args *args)
> +{
> +	struct mapped_device *md =
> +		container_of(profile, struct dm_crypto_profile, profile)->md;
> +	struct dm_target *ti;
> +	struct dm_table *t;
> +	int srcu_idx;
> +	int i;
> +
> +	args->err = -EOPNOTSUPP;
> +
> +	t = dm_get_live_table(md, &srcu_idx);
> +	if (!t)
> +		goto out;
> +
> +	/*
> +	 * blk-crypto currently has no support for multiple incompatible
> +	 * implementations of wrapped inline crypto keys on a single system.
> +	 * It was already checked earlier that support for wrapped keys was
> +	 * declared on all underlying devices.  Thus, all the underlying devices
> +	 * should support all wrapped key operations and they should behave
> +	 * identically, i.e. work with the same keys.  So, just executing the
> +	 * operation on the first device on which it works suffices for now.
> +	 */
> +	for (i = 0; i < t->num_targets; i++) {
> +		ti = dm_table_get_target(t, i);
> +		if (!ti->type->iterate_devices)
> +			continue;
> +		ti->type->iterate_devices(ti, dm_wrappedkey_op_callback, args);
> +		if (!args->err)
> +			break;
> +	}

I have a dumb question - if it doesn't matter through which block device 
do you set up the keys, why do you set them up through a block device at 
all?

What about making functions that set up the keys without taking block 
device as an argument, calling these functions directly and bypassing 
device mapper entirely?

Mikulas

Re: [PATCH v2 2/2] dm: pass through operations on wrapped inline crypto keys

[Eric Biggers]

On Mon, May 05, 2025 at 06:15:01PM +0200, Mikulas Patocka wrote:
> 
> 
> On Thu, 1 May 2025, Eric Biggers wrote:
> 
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Make the device-mapper layer pass through the derive_sw_secret,
> > import_key, generate_key, and prepare_key blk-crypto operations when all
> > underlying devices support hardware-wrapped inline crypto keys and are
> > passing through inline crypto support.
> > 
> > Commit ebc4176551cd ("blk-crypto: add basic hardware-wrapped key
> > support") already made BLK_CRYPTO_KEY_TYPE_HW_WRAPPED be passed through
> > in the same way that the other crypto capabilities are.  But the wrapped
> > key support also includes additional operations in blk_crypto_ll_ops,
> > and the dm layer needs to implement those to pass them through.
> > derive_sw_secret is needed by fscrypt, while the other operations are
> > needed for the new blk-crypto ioctls to work on device-mapper devices
> > and not just the raw partitions.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> >  drivers/md/dm-table.c | 177 ++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 177 insertions(+)
> > 
> > diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
> > index a937e1e12482e..0a71bedff81c5 100644
> > --- a/drivers/md/dm-table.c
> > +++ b/drivers/md/dm-table.c
> > +
> > +static int dm_exec_wrappedkey_op(struct blk_crypto_profile *profile,
> > +				 struct dm_wrappedkey_op_args *args)
> > +{
> > +	struct mapped_device *md =
> > +		container_of(profile, struct dm_crypto_profile, profile)->md;
> > +	struct dm_target *ti;
> > +	struct dm_table *t;
> > +	int srcu_idx;
> > +	int i;
> > +
> > +	args->err = -EOPNOTSUPP;
> > +
> > +	t = dm_get_live_table(md, &srcu_idx);
> > +	if (!t)
> > +		goto out;
> > +
> > +	/*
> > +	 * blk-crypto currently has no support for multiple incompatible
> > +	 * implementations of wrapped inline crypto keys on a single system.
> > +	 * It was already checked earlier that support for wrapped keys was
> > +	 * declared on all underlying devices.  Thus, all the underlying devices
> > +	 * should support all wrapped key operations and they should behave
> > +	 * identically, i.e. work with the same keys.  So, just executing the
> > +	 * operation on the first device on which it works suffices for now.
> > +	 */
> > +	for (i = 0; i < t->num_targets; i++) {
> > +		ti = dm_table_get_target(t, i);
> > +		if (!ti->type->iterate_devices)
> > +			continue;
> > +		ti->type->iterate_devices(ti, dm_wrappedkey_op_callback, args);
> > +		if (!args->err)
> > +			break;
> > +	}
> 
> I have a dumb question - if it doesn't matter through which block device 
> do you set up the keys, why do you set them up through a block device at 
> all?
> 
> What about making functions that set up the keys without taking block 
> device as an argument, calling these functions directly and bypassing 
> device mapper entirely?

Userspace needs to direct the key setup operations, so we'd need a UAPI for it
to do so.  We could add a custom syscall, or some hacked-up extension of
add_key(), and add a custom registration mechanism to allow a single
implementation of wrapped keys (e.g. from ufs-qcom) to register itself as the
system's wrapped key provider which the syscall would then use.

But it seemed cleaner to instead use block device ioctls and take advantage of
the existing blk-crypto-profile.  That already handles registering and
unregistering the implementation, and it also already handles things like
locking, and resuming the UFS controller if it's in suspend.

It also keeps the door open to supporting the case where different
wrapped-key-capable block devices don't necessarily accept the same keys, even
if that isn't the case currently.

- Eric

Re: [PATCH v2 2/2] dm: pass through operations on wrapped inline crypto keys

[Mikulas Patocka]

On Mon, 5 May 2025, Eric Biggers wrote:

> On Mon, May 05, 2025 at 06:15:01PM +0200, Mikulas Patocka wrote:
> > 
> > I have a dumb question - if it doesn't matter through which block device 
> > do you set up the keys, why do you set them up through a block device at 
> > all?
> > 
> > What about making functions that set up the keys without taking block 
> > device as an argument, calling these functions directly and bypassing 
> > device mapper entirely?
> 
> Userspace needs to direct the key setup operations, so we'd need a UAPI for it
> to do so.  We could add a custom syscall, or some hacked-up extension of
> add_key(), and add a custom registration mechanism to allow a single
> implementation of wrapped keys (e.g. from ufs-qcom) to register itself as the

What happens if there are multiple ufs-qcom controllers? Is it 
unsupported?

> system's wrapped key provider which the syscall would then use.
> 
> But it seemed cleaner to instead use block device ioctls and take advantage of
> the existing blk-crypto-profile.  That already handles registering and
> unregistering the implementation, and it also already handles things like
> locking, and resuming the UFS controller if it's in suspend.
> 
> It also keeps the door open to supporting the case where different
> wrapped-key-capable block devices don't necessarily accept the same keys, even
> if that isn't the case currently.
> 
> - Eric

I think that using ioctl on block device is ok.

But I don't see why do you need to perform the ioctl on device mapper 
device and let device mapper select a random underlying device where the 
ioctl is forwarded? You can as well select a random physical disk in your 
userspace application and call the ioctl on it.

Mikulas

Re: [PATCH v2 2/2] dm: pass through operations on wrapped inline crypto keys

[Eric Biggers]

On Mon, May 05, 2025 at 11:01:38PM +0200, Mikulas Patocka wrote:
> 
> 
> On Mon, 5 May 2025, Eric Biggers wrote:
> 
> > On Mon, May 05, 2025 at 06:15:01PM +0200, Mikulas Patocka wrote:
> > > 
> > > I have a dumb question - if it doesn't matter through which block device 
> > > do you set up the keys, why do you set them up through a block device at 
> > > all?
> > > 
> > > What about making functions that set up the keys without taking block 
> > > device as an argument, calling these functions directly and bypassing 
> > > device mapper entirely?
> > 
> > Userspace needs to direct the key setup operations, so we'd need a UAPI for it
> > to do so.  We could add a custom syscall, or some hacked-up extension of
> > add_key(), and add a custom registration mechanism to allow a single
> > implementation of wrapped keys (e.g. from ufs-qcom) to register itself as the
> 
> What happens if there are multiple ufs-qcom controllers? Is it 
> unsupported?

They would accept the same wrapped keys, I think.  But that is theoretical,
since multiple ufs-qcom hosts are currently unsupported for other reasons.

> > system's wrapped key provider which the syscall would then use.
> > 
> > But it seemed cleaner to instead use block device ioctls and take advantage of
> > the existing blk-crypto-profile.  That already handles registering and
> > unregistering the implementation, and it also already handles things like
> > locking, and resuming the UFS controller if it's in suspend.
> > 
> > It also keeps the door open to supporting the case where different
> > wrapped-key-capable block devices don't necessarily accept the same keys, even
> > if that isn't the case currently.
> > 
> > - Eric
> 
> I think that using ioctl on block device is ok.
> 
> But I don't see why do you need to perform the ioctl on device mapper 
> device and let device mapper select a random underlying device where the 
> ioctl is forwarded? You can as well select a random physical disk in your 
> userspace application and call the ioctl on it.

We have to forward derive_sw_secret anyway, since that's invoked by the
filesystem, not by the ioctls.

The other operations are for the ioctls, but I don't see a reason to make things
harder for userspace by forcing userspace to implement logic like:

    if (is_dm(blkdev))
        blkdev = underlying_device(blkdev)
    ioctl(blkdev)

The device-mapper block device has a blk-crypto profile that declares wrapped
key support.  We should just make the ioctls work on that block device, so that
upper layers don't need to care whether it's device-mapper or native.

- Eric

Re: [PATCH v2 2/2] dm: pass through operations on wrapped inline crypto keys

[Mikulas Patocka]

On Mon, 5 May 2025, Eric Biggers wrote:

> We have to forward derive_sw_secret anyway, since that's invoked by the
> filesystem, not by the ioctls.
> 
> The other operations are for the ioctls, but I don't see a reason to make things
> harder for userspace by forcing userspace to implement logic like:
> 
>     if (is_dm(blkdev))
>         blkdev = underlying_device(blkdev)
>     ioctl(blkdev)
> 
> The device-mapper block device has a blk-crypto profile that declares wrapped
> key support.  We should just make the ioctls work on that block device, so that
> upper layers don't need to care whether it's device-mapper or native.
> 
> - Eric

OK, I accepted both patches for the next merge window.

Mikulas