add support for inline encryption to device mapper

PATCH Superseded Satya Tangirala 4 participants 16 messages Feb 1, 2021 – Feb 12, 2021

Subsystems (2)

Block layer Device mapper

lore

Share & tools

lore

Satya Tangirala

author

2021-02-01 05:10 UTC #0 lore raw

v4 cover add support for inline encryption to device mapper

This patch series adds support for inline encryption to the device mapper.

Patch 1 introduces the "passthrough" keyslot manager.

The regular keyslot manager is designed for inline encryption hardware that have only a small fixed number of keyslots. A DM device itself does not actually have only a small fixed number of keyslots - it doesn't actually have any keyslots in the first place, and programming an encryption context into a DM device doesn't make much semantic sense. It is possible for a DM device to set up a keyslot manager with some "sufficiently large" number of keyslots in its request queue, so that upper layers can use the inline encryption capabilities of the DM device's underlying devices, but the memory being allocated for the DM device's keyslots is a waste since they won't actually be used by the DM device.

The passthrough keyslot manager solves this issue - when the block layer sees that a request queue has a passthrough keyslot manager, it doesn't attempt to program any encryption context into the keyslot manager. The passthrough keyslot manager only allows the device to expose its inline encryption capabilities, and a way for upper layers to evict keys if necessary.

There also exist inline encryption hardware that can handle encryption contexts directly, and allow users to pass them a data request along with the encryption context (as opposed to inline encryption hardware that require users to first program a keyslot with an encryption context, and then require the users to pass the keyslot index with the data request). Such devices can also make use of the passthrough keyslot manager.

Patch 2 introduces some keyslot manager functions useful for the device mapper.

Patch 3 introduces the changes for inline encryption support for the device mapper. A DM device only exposes the intersection of the crypto capabilities of its underlying devices. This is so that in case a bio with an encryption context is eventually mapped to an underlying device that doesn't support that encryption context, the blk-crypto-fallback's cipher tfms are allocated ahead of time by the call to blk_crypto_start_using_key.

Each DM target can now also specify the "DM_TARGET_PASSES_CRYPTO" flag in the target type features to opt-in to supporting passing through the underlying inline encryption capabilities. This flag is needed because it doesn't make much semantic sense for certain targets like dm-crypt to expose the underlying inline encryption capabilities to the upper layers. Again, the DM exposes inline encryption capabilities of the underlying devices only if all of them opt-in to passing through inline encryption support.

A keyslot manager is created for a table when it is loaded. However, the mapped device's exposed capabilities *only* updated once the table is swapped in (until the new table is swapped in, the mapped device continues to expose the old table's crypto capabilities).

This patch only allows the keyslot manager's capabilities to *expand* because of table changes. Any attempt to load a new table that doesn't support a crypto capability that the old table did is rejected.

This patch also only exposes the intersection of the underlying device's capabilities, which has the effect of causing en/decryption of a bio to fall back to the kernel crypto API (if the fallback is enabled) whenever any of the underlying devices doesn't support the encryption context of the bio - it might be possible to make the bio only fall back to the kernel crypto API if the bio's target underlying device doesn't support the bio's encryption context, but the use case may be uncommon enough in the first place not to warrant worrying about it right now.

Patch 4 makes DM evict a key from all its underlying devices when asked to evict a key.

Patch 5 makes some DM targets opt-in to passing through inline encryption support. It does not (yet) try to enable this option with dm-raid, since users can "hot add" disks to a raid device, which makes this not completely straightforward (we'll need to ensure that any "hot added" disks must have a superset of the inline encryption capabilities of the rest of the disks in the raid device, due to the way Patch 2 of this series works).

Changes v3 => v4:
- Allocate the memory for the ksm of the mapped device in dm_table_complete(), and install the ksm in the md queue in __bind() (as suggested by Mike). Also drop patch 5 from v3 since it's no longer needed.
- Some cleanups

Changes v2 => v3:
- Split up the main DM patch into 4 separate patches
- Removed the priv variable added to struct keyslot manager in v2
- Use a flag in target type features for opting-in to inline encryption support, instead of using "may_passthrough_inline_crypto"
- cleanups, improve docs and restructure code

Changes v1 => v2:
- Introduce private field to struct blk_keyslot_manager
- Allow the DM keyslot manager to expand its crypto capabilities if the table is changed.
- Make DM reject table changes that would otherwise cause crypto capabilities to be dropped.
- Allocate the DM device's keyslot manager only when at least one crypto capability is supported (since a NULL value for q->ksm represents "no crypto support" anyway).
- Remove the struct blk_keyslot_manager field from struct mapped_device. This patch now relies on just directly setting up the keyslot manager in the request queue, since each DM device is tied to only 1 queue.

Satya Tangirala (5):
block: keyslot-manager: Introduce passthrough keyslot manager
block: keyslot-manager: Introduce functions for device mapper support
dm: add support for passing through inline crypto support
dm: support key eviction from keyslot managers of underlying devices
dm: set DM_TARGET_PASSES_CRYPTO feature for some targets

 block/blk-crypto.c              |   1 +
 block/keyslot-manager.c         | 146 ++++++++++++++++++++++
 drivers/md/dm-core.h            |   5 +
 drivers/md/dm-flakey.c          |   4 +-
 drivers/md/dm-linear.c          |   5 +-
 drivers/md/dm-table.c           | 210 ++++++++++++++++++++++++++++++++
 drivers/md/dm.c                 |  18 ++-
 include/linux/device-mapper.h   |  11 ++
 include/linux/keyslot-manager.h |  11 ++
 9 files changed, 407 insertions(+), 4 deletions(-)

Signature · 6 lines

2.30.0.365.g02bc693789-goog

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Satya Tangirala

author

2021-02-01 05:11 UTC #1 lore raw

PATCH v4 1/5 block: keyslot-manager: Introduce passthrough keyslot manager

The device mapper may map over devices that have inline encryption capabilities, and to make use of those capabilities, the DM device must itself advertise those inline encryption capabilities. One way to do this would be to have the DM device set up a keyslot manager with a "sufficiently large" number of keyslots, but that would use a lot of memory. Also, the DM device itself has no "keyslots", and it doesn't make much sense to talk about "programming a key into a DM device's keyslot manager", so all that extra memory used to represent those keyslots is just wasted. All a DM device really needs to be able to do is advertise the crypto capabilities of the underlying devices in a coherent manner and expose a way to evict keys from the underlying devices.

There are also devices with inline encryption hardware that do not have a limited number of keyslots. One can send a raw encryption key along with a bio to these devices (as opposed to typical inline encryption hardware that require users to first program a raw encryption key into a keyslot, and send the index of that keyslot along with the bio). These devices also only need the same things from the keyslot manager that DM devices need - a way to advertise crypto capabilities and potentially a way to expose a function to evict keys from hardware.

So we introduce a "passthrough" keyslot manager that provides a way to represent a keyslot manager that doesn't have just a limited number of keyslots, and for which do not require keys to be programmed into keyslots. DM devices can set up a passthrough keyslot manager in their request queues, and advertise appropriate crypto capabilities based on those of the underlying devices. Blk-crypto does not attempt to program keys into any keyslots in the passthrough keyslot manager. Instead, if/when the bio is resubmitted to the underlying device, blk-crypto will try to program the key into the underlying device's keyslot manager.

Signed-off-by Satya Tangirala <[email protected]>

Reviewed-by Eric Biggers <[email protected]>

---
 block/keyslot-manager.c         | 39 +++++++++++++++++++++++++++++++++
 include/linux/keyslot-manager.h |  2 ++
 2 files changed, 41 insertions(+)

block/keyslot-manager.c +39 -0

index 86f8195d8039..ac7ce83a76e8 100644
@@ -62,6 +62,11 @@ static inline void blk_ksm_hw_exit(struct blk_keyslot_manager *ksm)
 		pm_runtime_put_sync(ksm->dev);
 }
 
+static inline bool blk_ksm_is_passthrough(struct blk_keyslot_manager *ksm)
+{
+	return ksm->num_slots == 0;
+}
+
 /**
  * blk_ksm_init() - Initialize a keyslot manager
  * @ksm: The keyslot_manager to initialize.

@@ -205,6 +210,10 @@ blk_status_t blk_ksm_get_slot_for_key(struct blk_keyslot_manager *ksm,
 	int err;
 
 	*slot_ptr = NULL;
+
+	if (blk_ksm_is_passthrough(ksm))
+		return BLK_STS_OK;
+
 	down_read(&ksm->lock);
 	slot = blk_ksm_find_and_grab_keyslot(ksm, key);
 	up_read(&ksm->lock);

@@ -325,6 +334,16 @@ int blk_ksm_evict_key(struct blk_keyslot_manager *ksm,
 	struct blk_ksm_keyslot *slot;
 	int err = 0;
 
+	if (blk_ksm_is_passthrough(ksm)) {
+		if (ksm->ksm_ll_ops.keyslot_evict) {
+			blk_ksm_hw_enter(ksm);
+			err = ksm->ksm_ll_ops.keyslot_evict(ksm, key, -1);
+			blk_ksm_hw_exit(ksm);
+			return err;
+		}
+		return 0;
+	}
+
 	blk_ksm_hw_enter(ksm);
 	slot = blk_ksm_find_keyslot(ksm, key);
 	if (!slot)

@@ -360,6 +379,9 @@ void blk_ksm_reprogram_all_keys(struct blk_keyslot_manager *ksm)
 {
 	unsigned int slot;
 
+	if (blk_ksm_is_passthrough(ksm))
+		return;
+
 	/* This is for device initialization, so don't resume the device */
 	down_write(&ksm->lock);
 	for (slot = 0; slot < ksm->num_slots; slot++) {

@@ -401,3 +423,20 @@ void blk_ksm_unregister(struct request_queue *q)
 {
 	q->ksm = NULL;
 }
+
+/**
+ * blk_ksm_init_passthrough() - Init a passthrough keyslot manager
+ * @ksm: The keyslot manager to init
+ *
+ * Initialize a passthrough keyslot manager.
+ * Called by e.g. storage drivers to set up a keyslot manager in their
+ * request_queue, when the storage driver wants to manage its keys by itself.
+ * This is useful for inline encryption hardware that doesn't have the concept
+ * of keyslots, and for layered devices.
+ */
+void blk_ksm_init_passthrough(struct blk_keyslot_manager *ksm)
+{
+	memset(ksm, 0, sizeof(*ksm));
+	init_rwsem(&ksm->lock);
+}
+EXPORT_SYMBOL_GPL(blk_ksm_init_passthrough);

include/linux/keyslot-manager.h +2 -0

index 18f3f5346843..323e15dd6fa7 100644
@@ -103,4 +103,6 @@ void blk_ksm_reprogram_all_keys(struct blk_keyslot_manager *ksm);
 
 void blk_ksm_destroy(struct blk_keyslot_manager *ksm);
 
+void blk_ksm_init_passthrough(struct blk_keyslot_manager *ksm);
+
 #endif /* __LINUX_KEYSLOT_MANAGER_H */

Signature · 1 line

2.30.0.365.g02bc693789-goog

Satya Tangirala

author

2021-02-01 05:11 UTC #2 lore raw

PATCH v4 2/5 block: keyslot-manager: Introduce functions for device mapper support

In reply to Satya Tangirala

Introduce blk_ksm_update_capabilities() to update the capabilities of a keyslot manager (ksm) in-place. The pointer to a ksm in a device's request queue may not be easily replaced, because upper layers like the filesystem might access it (e.g. for programming keys/checking capabilities) at the same time the device wants to replace that request queue's ksm (and free the old ksm's memory). This function allows the device to update the capabilities of the ksm in its request queue directly. Devices can safely update the ksm this way without any synchronization with upper layers *only* if the updated (new) ksm continues to support all the crypto capabilities that the old ksm did (see description below for blk_ksm_is_superset() for why this is so).

Also introduce blk_ksm_is_superset() which checks whether one ksm's capabilities are a (not necessarily strict) superset of another ksm's. The blk-crypto framework requires that crypto capabilities that were advertised when a bio was created continue to be supported by the device until that bio is ended - in practice this probably means that a device's advertised crypto capabilities can *never* "shrink" (since there's no synchronization between bio creation and when a device may want to change its advertised capabilities) - so a previously advertised crypto capability must always continue to be supported. This function can be used to check that a new ksm is a valid replacement for an old ksm.

Signed-off-by Satya Tangirala <[email protected]>

---
 block/keyslot-manager.c         | 107 ++++++++++++++++++++++++++++++++
 include/linux/keyslot-manager.h |   9 +++
 2 files changed, 116 insertions(+)

block/keyslot-manager.c +107 -0

index ac7ce83a76e8..9f9494b80148 100644
@@ -424,6 +424,113 @@ void blk_ksm_unregister(struct request_queue *q)
 	q->ksm = NULL;
 }
 
+/**
+ * blk_ksm_intersect_modes() - restrict supported modes by child device
+ * @parent: The keyslot manager for parent device
+ * @child: The keyslot manager for child device, or NULL
+ *
+ * Clear any crypto mode support bits in @parent that aren't set in @child.
+ * If @child is NULL, then all parent bits are cleared.
+ *
+ * Only use this when setting up the keyslot manager for a layered device,
+ * before it's been exposed yet.
+ */
+void blk_ksm_intersect_modes(struct blk_keyslot_manager *parent,
+			     const struct blk_keyslot_manager *child)
+{
+	if (child) {
+		unsigned int i;
+
+		parent->max_dun_bytes_supported =
+			min(parent->max_dun_bytes_supported,
+			    child->max_dun_bytes_supported);
+		for (i = 0; i < ARRAY_SIZE(child->crypto_modes_supported);
+		     i++) {
+			parent->crypto_modes_supported[i] &=
+				child->crypto_modes_supported[i];
+		}
+	} else {
+		parent->max_dun_bytes_supported = 0;
+		memset(parent->crypto_modes_supported, 0,
+		       sizeof(parent->crypto_modes_supported));
+	}
+}
+EXPORT_SYMBOL_GPL(blk_ksm_intersect_modes);
+
+/**
+ * blk_ksm_is_superset() - Check if a KSM supports a superset of crypto modes
+ *			   and DUN bytes that another KSM supports. Here,
+ *			   "superset" refers to the mathematical meaning of the
+ *			   word - i.e. if two KSMs have the *same* capabilities,
+ *			   they *are* considered supersets of each other.
+ * @ksm_superset: The KSM that we want to verify is a superset
+ * @ksm_subset: The KSM that we want to verify is a subset
+ *
+ * Return: True if @ksm_superset supports a superset of the crypto modes and DUN
+ *	   bytes that @ksm_subset supports.
+ */
+bool blk_ksm_is_superset(struct blk_keyslot_manager *ksm_superset,
+			 struct blk_keyslot_manager *ksm_subset)
+{
+	int i;
+
+	if (!ksm_subset)
+		return true;
+
+	if (!ksm_superset)
+		return false;
+
+	for (i = 0; i < ARRAY_SIZE(ksm_superset->crypto_modes_supported); i++) {
+		if (ksm_subset->crypto_modes_supported[i] &
+		    (~ksm_superset->crypto_modes_supported[i])) {
+			return false;
+		}
+	}
+
+	if (ksm_subset->max_dun_bytes_supported >
+	    ksm_superset->max_dun_bytes_supported) {
+		return false;
+	}
+
+	return true;
+}
+EXPORT_SYMBOL_GPL(blk_ksm_is_superset);
+
+/**
+ * blk_ksm_update_capabilities() - Update the restrictions of a KSM to those of
+ *				   another KSM
+ * @target_ksm: The KSM whose restrictions to update.
+ * @reference_ksm: The KSM to whose restrictions this function will update
+ *		   @target_ksm's restrictions to.
+ *
+ * Blk-crypto requires that crypto capabilities that were
+ * advertised when a bio was created continue to be supported by the
+ * device until that bio is ended. This is turn means that a device cannot
+ * shrink its advertised crypto capabilities without any explicit
+ * synchronization with upper layers. So if there's no such explicit
+ * synchronization, @reference_ksm must support all the crypto capabilities that
+ * @target_ksm does
+ * (i.e. we need blk_ksm_is_superset(@reference_ksm, @target_ksm) == true).
+ *
+ * Note also that as long as the crypto capabilities are being expanded, the
+ * order of updates becoming visible is not important because it's alright
+ * for blk-crypto to see stale values - they only cause blk-crypto to
+ * believe that a crypto capability isn't supported when it actually is (which
+ * might result in blk-crypto-fallback being used if available, or the bio being
+ * failed).
+ */
+void blk_ksm_update_capabilities(struct blk_keyslot_manager *target_ksm,
+				 struct blk_keyslot_manager *reference_ksm)
+{
+	memcpy(target_ksm->crypto_modes_supported,
+	       reference_ksm->crypto_modes_supported,
+	       sizeof(target_ksm->crypto_modes_supported));
+
+	target_ksm->max_dun_bytes_supported =
+				reference_ksm->max_dun_bytes_supported;
+}
+EXPORT_SYMBOL_GPL(blk_ksm_update_capabilities);
+
 /**
  * blk_ksm_init_passthrough() - Init a passthrough keyslot manager
  * @ksm: The keyslot manager to init

include/linux/keyslot-manager.h +9 -0

index 323e15dd6fa7..164568f52be7 100644
@@ -103,6 +103,15 @@ void blk_ksm_reprogram_all_keys(struct blk_keyslot_manager *ksm);
 
 void blk_ksm_destroy(struct blk_keyslot_manager *ksm);
 
+void blk_ksm_intersect_modes(struct blk_keyslot_manager *parent,
+			     const struct blk_keyslot_manager *child);
+
 void blk_ksm_init_passthrough(struct blk_keyslot_manager *ksm);
 
+bool blk_ksm_is_superset(struct blk_keyslot_manager *ksm_superset,
+			 struct blk_keyslot_manager *ksm_subset);
+
+void blk_ksm_update_capabilities(struct blk_keyslot_manager *target_ksm,
+				 struct blk_keyslot_manager *reference_ksm);
+
 #endif /* __LINUX_KEYSLOT_MANAGER_H */

Signature · 6 lines

2.30.0.365.g02bc693789-goog

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Eric Biggers

Reviewed-by on v4 2/5

2021-02-10 19:56 UTC #3 lore raw

Re: [PATCH v4 2/5] block: keyslot-manager: Introduce functions for device mapper support

Quoted 24 lines · Satya Tangirala

Introduce blk_ksm_update_capabilities() to update the capabilities of a keyslot manager (ksm) in-place. The pointer to a ksm in a device's request queue may not be easily replaced, because upper layers like the filesystem might access it (e.g. for programming keys/checking capabilities) at the same time the device wants to replace that request queue's ksm (and free the old ksm's memory). This function allows the device to update the capabilities of the ksm in its request queue directly. Devices can safely update the ksm this way without any synchronization with upper layers *only* if the updated (new) ksm continues to support all the crypto capabilities that the old ksm did (see description below for blk_ksm_is_superset() for why this is so).
Also introduce blk_ksm_is_superset() which checks whether one ksm's capabilities are a (not necessarily strict) superset of another ksm's. The blk-crypto framework requires that crypto capabilities that were advertised when a bio was created continue to be supported by the device until that bio is ended - in practice this probably means that a device's advertised crypto capabilities can *never* "shrink" (since there's no synchronization between bio creation and when a device may want to change its advertised capabilities) - so a previously advertised crypto capability must always continue to be supported. This function can be used to check that a new ksm is a valid replacement for an old ksm.

Quoted 1 line

Signed-off-by Satya Tangirala <[email protected]>

Looks good, you can add:

Reviewed-by Eric Biggers <[email protected]>

Satya Tangirala

author

2021-02-01 05:11 UTC #4 lore raw

PATCH v4 3/5 dm: add support for passing through inline crypto support

In reply to Satya Tangirala

Update the device-mapper core to support exposing the inline crypto support of the underlying device(s) through the device-mapper device.

This works by creating a "passthrough keyslot manager" for the dm device, which declares support for encryption settings which all underlying devices support. When a supported setting is used, the bio cloning code handles cloning the crypto context to the bios for all the underlying devices. When an unsupported setting is used, the blk-crypto fallback is used as usual.

Crypto support on each underlying device is ignored unless the corresponding dm target opts into exposing it. This is needed because for inline crypto to semantically operate on the original bio, the data must not be transformed by the dm target. Thus, targets like dm-linear can expose crypto support of the underlying device, but targets like dm-crypt can't. (dm-crypt could use inline crypto itself, though.)

A DM device's table can only be changed if the "new" inline encryption capabilities are a (*not* necessarily strict) superset of the "old" inline encryption capabilities. Attempts to make changes to the table that result in some inline encryption capability becoming no longer supported will be rejected.

For the sake of clarity, key eviction from underlying devices will be handled in a future patch.

Co-developed-by Eric Biggers <[email protected]>

Signed-off-by Eric Biggers <[email protected]>

Signed-off-by Satya Tangirala <[email protected]>

---
 drivers/md/dm-core.h          |   5 ++
 drivers/md/dm-table.c         | 157 ++++++++++++++++++++++++++++++++++
 drivers/md/dm.c               |  18 +++-
 include/linux/device-mapper.h |  11 +++
 4 files changed, 190 insertions(+), 1 deletion(-)

drivers/md/dm-core.h +5 -0

index 086d293c2b03..bf3e66f39a4a 100644
@@ -13,6 +13,7 @@
 #include <linux/ktime.h>
 #include <linux/genhd.h>
 #include <linux/blk-mq.h>
+#include <linux/keyslot-manager.h>
 
 #include <trace/events/block.h>

@@ -162,6 +163,10 @@ struct dm_table {
 	void *event_context;
 
 	struct dm_md_mempools *mempools;
+
+#ifdef CONFIG_BLK_INLINE_ENCRYPTION
+	struct blk_keyslot_manager *ksm;
+#endif
 };
 
 static inline struct completion *dm_get_completion_from_kobject(struct kobject *kobj)

drivers/md/dm-table.c +157 -0

187 lines not on this page · raw message

drivers/md/dm.c +17 -1

index 7bac564f3faa..ee0434764941 100644
@@ -28,6 +28,7 @@
 #include <linux/refcount.h>
 #include <linux/part_stat.h>
 #include <linux/blk-crypto.h>
+#include <linux/keyslot-manager.h>
 
 #define DM_MSG_PREFIX "core"

@@ -1718,6 +1719,19 @@ static const struct dax_operations dm_dax_ops;
 
 static void dm_wq_work(struct work_struct *work);
 
+#ifdef CONFIG_BLK_INLINE_ENCRYPTION
+static void dm_queue_destroy_keyslot_manager(struct request_queue *q)
+{
+	dm_destroy_keyslot_manager(q->ksm);
+}
+
+#else /* CONFIG_BLK_INLINE_ENCRYPTION */
+
+static inline void dm_queue_destroy_keyslot_manager(struct request_queue *q)
+{
+}
+#endif /* !CONFIG_BLK_INLINE_ENCRYPTION */
+
 static void cleanup_mapped_device(struct mapped_device *md)
 {
 	if (md->wq)

@@ -1739,8 +1753,10 @@ static void cleanup_mapped_device(struct mapped_device *md)
 		put_disk(md->disk);
 	}
 
-	if (md->queue)
+	if (md->queue) {
+		dm_queue_destroy_keyslot_manager(md->queue);
 		blk_cleanup_queue(md->queue);
+	}
 
 	cleanup_srcu_struct(&md->io_barrier);

include/linux/device-mapper.h +11 -0

index 61a66fb8ebb3..d2142f5a82a7 100644
@@ -257,6 +257,12 @@ struct target_type {
 #define DM_TARGET_NOWAIT		0x00000080
 #define dm_target_supports_nowait(type) ((type)->features & DM_TARGET_NOWAIT)
 
+/*
+ *
+ */
+#define DM_TARGET_PASSES_CRYPTO		0x00000100
+#define dm_target_passes_crypto(type) ((type)->features & DM_TARGET_PASSES_CRYPTO)
+
 struct dm_target {
 	struct dm_table *table;
 	struct target_type *type;

@@ -533,6 +539,11 @@ void dm_table_run_md_queue_async(struct dm_table *t);
 struct dm_table *dm_swap_table(struct mapped_device *md,
 			       struct dm_table *t);
 
+/*
+ * Table keyslot manager functions
+ */
+void dm_destroy_keyslot_manager(struct blk_keyslot_manager *ksm);
+
 /*
  * A wrapper around vmalloc.
  */

Signature · 6 lines

2.30.0.365.g02bc693789-goog

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Eric Biggers

Reviewed-by on v4 3/5

2021-02-10 20:18 UTC #5 lore raw

Re: [PATCH v4 3/5] dm: add support for passing through inline crypto support

Quoted 23 lines · Satya Tangirala

Update the device-mapper core to support exposing the inline crypto support of the underlying device(s) through the device-mapper device.
This works by creating a "passthrough keyslot manager" for the dm device, which declares support for encryption settings which all underlying devices support. When a supported setting is used, the bio cloning code handles cloning the crypto context to the bios for all the underlying devices. When an unsupported setting is used, the blk-crypto fallback is used as usual.
Crypto support on each underlying device is ignored unless the corresponding dm target opts into exposing it. This is needed because for inline crypto to semantically operate on the original bio, the data must not be transformed by the dm target. Thus, targets like dm-linear can expose crypto support of the underlying device, but targets like dm-crypt can't. (dm-crypt could use inline crypto itself, though.)
A DM device's table can only be changed if the "new" inline encryption capabilities are a (*not* necessarily strict) superset of the "old" inline encryption capabilities. Attempts to make changes to the table that result in some inline encryption capability becoming no longer supported will be rejected.

Quoted 6 lines

For the sake of clarity, key eviction from underlying devices will be handled in a future patch.
Co-developed-by Eric Biggers <[email protected]>
Signed-off-by Eric Biggers <[email protected]>
Signed-off-by Satya Tangirala <[email protected]>

I don't see any obvious issues with this latest version. I assume you've tested it on real hardware?

If it's needed despite my Co-developed-by, feel free to add:

Reviewed-by Eric Biggers <[email protected]>

A few nits about comments, in case you resend:

Quoted 13 lines

drivers/md/dm-core.h +1 -0

index 086d293c2b03..bf3e66f39a4a 100644
@@ -13,6 +13,7 @@
 #include <linux/ktime.h>
 #include <linux/genhd.h>
 #include <linux/blk-mq.h>
+#include <linux/keyslot-manager.h>
 
 #include <trace/events/block.h>

drivers/md/dm-core.h struct dm_table { · line 170

Quoted 8 lines

drivers/md/dm-core.h +4 -0

@@ -162,6 +163,10 @@ struct dm_table {
 	void *event_context;
 
 	struct dm_md_mempools *mempools;
+
+#ifdef CONFIG_BLK_INLINE_ENCRYPTION
+	struct blk_keyslot_manager *ksm;
+#endif
 };

It might be helpful if there was a brief comment here that explained that this field is only set temporarily while the table is being set up, and it gets set to NULL after the capabilities have been transferred to the request_queue. I.e., it's not something that stays around here while the dm device is active.

drivers/md/dm-core.h struct dm_table {

Quoted 11 lines

drivers/md/dm-core.h +11 -0

+/*
+ * Constructs and returns a keyslot manager that represents the crypto
+ * capabilities of the devices described by the dm_table. However, if the
+ * constructed keyslot manager does not support a superset of the crypto
+ * capabilities supported by the current keyslot manager of the mapped_device,
+ * it returns an error instead, since we don't support restricting crypto
+ * capabilities on table changes. Finally, if the constructed keyslot manager
+ * doesn't actually support any crypto modes at all, it just returns NULL.
+ */
+static int
+dm_table_construct_keyslot_manager(struct dm_table *t)

This doesn't "return" the keyslot manager anymore, but rather assigns it to t->ksm. It would also be helpful if the comment explicitly mentioned that the goal is to find the capabilities that all the devices have in common.

E.g. "Initializes t->ksm with a keyslot manager that represents the common set of crypto capabilities of the devices described by the dm_table.".

include/linux/device-mapper.h struct target_type { · line 264

Quoted 13 lines

include/linux/device-mapper.h +5 -0

index 61a66fb8ebb3..d2142f5a82a7 100644
@@ -257,6 +257,12 @@ struct target_type {
 #define DM_TARGET_NOWAIT		0x00000080
 #define dm_target_supports_nowait(type) ((type)->features & DM_TARGET_NOWAIT)
 
+/*
+ *
+ */
+#define DM_TARGET_PASSES_CRYPTO		0x00000100
+#define dm_target_passes_crypto(type) ((type)->features & DM_TARGET_PASSES_CRYPTO)

The above comment isn't very useful :-)

- Eric

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Satya Tangirala

author

2021-02-11 22:59 UTC #6 lore raw

Re: [PATCH v4 3/5] dm: add support for passing through inline crypto support

Quoted 31 lines · Eric Biggers

Quoted 23 lines · Satya Tangirala
Update the device-mapper core to support exposing the inline crypto support of the underlying device(s) through the device-mapper device.
This works by creating a "passthrough keyslot manager" for the dm device, which declares support for encryption settings which all underlying devices support. When a supported setting is used, the bio cloning code handles cloning the crypto context to the bios for all the underlying devices. When an unsupported setting is used, the blk-crypto fallback is used as usual.
Crypto support on each underlying device is ignored unless the corresponding dm target opts into exposing it. This is needed because for inline crypto to semantically operate on the original bio, the data must not be transformed by the dm target. Thus, targets like dm-linear can expose crypto support of the underlying device, but targets like dm-crypt can't. (dm-crypt could use inline crypto itself, though.)
A DM device's table can only be changed if the "new" inline encryption capabilities are a (*not* necessarily strict) superset of the "old" inline encryption capabilities. Attempts to make changes to the table that result in some inline encryption capability becoming no longer supported will be rejected.
Quoted 6 lines
For the sake of clarity, key eviction from underlying devices will be handled in a future patch.
Co-developed-by Eric Biggers <[email protected]>
Signed-off-by Eric Biggers <[email protected]>
Signed-off-by Satya Tangirala <[email protected]>

Quoted 9 lines

I don't see any obvious issues with this latest version. I assume you've tested it on real hardware?
If it's needed despite my Co-developed-by, feel free to add:
Reviewed-by Eric Biggers <[email protected]>
A few nits about comments, in case you resend:

Thanks! I addressed the nits, added acked/reviewed-bys and resent v5.

Satya Tangirala

author

2021-02-01 05:10 UTC #7 lore raw

PATCH v4 4/5 dm: support key eviction from keyslot managers of underlying devices

In reply to Satya Tangirala

Now that device mapper supports inline encryption, add the ability to evict keys from all underlying devices. When an upper layer requests a key eviction, we simply iterate through all underlying devices and evict that key from each device.

Co-developed-by Eric Biggers <[email protected]>

Signed-off-by Eric Biggers <[email protected]>

Signed-off-by Satya Tangirala <[email protected]>

---
 block/blk-crypto.c    |  1 +
 drivers/md/dm-table.c | 53 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+)

block/blk-crypto.c +1 -0

index 5da43f0973b4..c2be8f15006c 100644
@@ -409,3 +409,4 @@ int blk_crypto_evict_key(struct request_queue *q,
 	 */
 	return blk_crypto_fallback_evict_key(key);
 }
+EXPORT_SYMBOL_GPL(blk_crypto_evict_key);

drivers/md/dm-table.c +53 -0

65 lines not on this page · raw message

Signature · 6 lines

2.30.0.365.g02bc693789-goog

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Eric Biggers

Reviewed-by on v4 4/5

2021-02-10 20:20 UTC #8 lore raw

Re: [PATCH v4 4/5] dm: support key eviction from keyslot managers of underlying devices

Quoted 8 lines · Satya Tangirala

Now that device mapper supports inline encryption, add the ability to evict keys from all underlying devices. When an upper layer requests a key eviction, we simply iterate through all underlying devices and evict that key from each device.
Co-developed-by Eric Biggers <[email protected]>
Signed-off-by Eric Biggers <[email protected]>
Signed-off-by Satya Tangirala <[email protected]>

This latest version looks good to me. If it's needed despite my Co-developed-by, feel free to add:

Reviewed-by Eric Biggers <[email protected]>

- Eric

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Satya Tangirala

author

2021-02-01 05:10 UTC #9 lore raw

PATCH v4 5/5 dm: set DM_TARGET_PASSES_CRYPTO feature for some targets

In reply to Satya Tangirala

dm-linear and dm-flakey obviously can pass through inline crypto support.

Co-developed-by Eric Biggers <[email protected]>

Signed-off-by Eric Biggers <[email protected]>

Signed-off-by Satya Tangirala <[email protected]>

---
 drivers/md/dm-flakey.c | 4 +++-
 drivers/md/dm-linear.c | 5 +++--
 2 files changed, 6 insertions(+), 3 deletions(-)

drivers/md/dm-flakey.c +3 -1

index a2cc9e45cbba..30c6bc151213 100644
@@ -482,8 +482,10 @@ static struct target_type flakey_target = {
 	.name   = "flakey",
 	.version = {1, 5, 0},
 #ifdef CONFIG_BLK_DEV_ZONED
-	.features = DM_TARGET_ZONED_HM,
+	.features = DM_TARGET_ZONED_HM | DM_TARGET_PASSES_CRYPTO,
 	.report_zones = flakey_report_zones,
+#else
+	.features = DM_TARGET_PASSES_CRYPTO,
 #endif
 	.module = THIS_MODULE,
 	.ctr    = flakey_ctr,

drivers/md/dm-linear.c +3 -2

index 00774b5d7668..fc9c4272c10d 100644
@@ -229,10 +229,11 @@ static struct target_type linear_target = {
 	.version = {1, 4, 0},
 #ifdef CONFIG_BLK_DEV_ZONED
 	.features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_NOWAIT |
-		    DM_TARGET_ZONED_HM,
+		    DM_TARGET_ZONED_HM | DM_TARGET_PASSES_CRYPTO,
 	.report_zones = linear_report_zones,
 #else
-	.features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_NOWAIT,
+	.features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_NOWAIT |
+		    DM_TARGET_PASSES_CRYPTO,
 #endif
 	.module = THIS_MODULE,
 	.ctr    = linear_ctr,

Signature · 6 lines

2.30.0.365.g02bc693789-goog

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Eric Biggers

Reviewed-by on v4 5/5

2021-02-10 20:25 UTC #10 lore raw

Re: [PATCH v4 5/5] dm: set DM_TARGET_PASSES_CRYPTO feature for some targets

Quoted 35 lines · Satya Tangirala

dm-linear and dm-flakey obviously can pass through inline crypto support.

Co-developed-by Eric Biggers <[email protected]>

Signed-off-by Eric Biggers <[email protected]>

Signed-off-by Satya Tangirala <[email protected]>

---
 drivers/md/dm-flakey.c | 4 +++-
 drivers/md/dm-linear.c | 5 +++--
 2 files changed, 6 insertions(+), 3 deletions(-)

drivers/md/dm-flakey.c +3 -1

index a2cc9e45cbba..30c6bc151213 100644
@@ -482,8 +482,10 @@ static struct target_type flakey_target = {
 	.name   = "flakey",
 	.version = {1, 5, 0},
 #ifdef CONFIG_BLK_DEV_ZONED
-	.features = DM_TARGET_ZONED_HM,
+	.features = DM_TARGET_ZONED_HM | DM_TARGET_PASSES_CRYPTO,
 	.report_zones = flakey_report_zones,
+#else
+	.features = DM_TARGET_PASSES_CRYPTO,
 #endif
 	.module = THIS_MODULE,
 	.ctr    = flakey_ctr,

drivers/md/dm-linear.c +0 -0

index 00774b5d7668..fc9c4272c10d 100644
@@ -229,10 +229,11 @@ static struct target_type linear_target = {
 	.version = {1, 4, 0},
 #ifdef CONFIG_BLK_DEV_ZONED
 	.features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_NOWAIT |

drivers/md/dm-linear.c static struct target_type linear_target = { · line 239

Quoted 10 lines

drivers/md/dm-linear.c +3 -2

-		    DM_TARGET_ZONED_HM,
+		    DM_TARGET_ZONED_HM | DM_TARGET_PASSES_CRYPTO,
 	.report_zones = linear_report_zones,
 #else
-	.features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_NOWAIT,
+	.features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_NOWAIT |
+		    DM_TARGET_PASSES_CRYPTO,
 #endif
 	.module = THIS_MODULE,
 	.ctr    = linear_ctr,

This latest version looks good to me. If it's needed despite my Co-developed-by, feel free to add:

Reviewed-by Eric Biggers <[email protected]>

BTW, the #ifdef for CONFIG_BLK_DEV_ZONED is error-prone (though it's a pre-existing issue). I wonder if DM_TARGET_ZONED_HM should be defined to 0 when !CONFIG_BLK_DEV_ZONED, which would avoid the need for the #ifdef on .features.

- Eric

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Mike Snitzer

2021-02-10 19:33 UTC #11 lore raw

In reply to Satya Tangirala

Quoted 110 lines · Satya Tangirala

This patch series adds support for inline encryption to the device mapper.
Patch 1 introduces the "passthrough" keyslot manager.
The regular keyslot manager is designed for inline encryption hardware that have only a small fixed number of keyslots. A DM device itself does not actually have only a small fixed number of keyslots - it doesn't actually have any keyslots in the first place, and programming an encryption context into a DM device doesn't make much semantic sense. It is possible for a DM device to set up a keyslot manager with some "sufficiently large" number of keyslots in its request queue, so that upper layers can use the inline encryption capabilities of the DM device's underlying devices, but the memory being allocated for the DM device's keyslots is a waste since they won't actually be used by the DM device.
The passthrough keyslot manager solves this issue - when the block layer sees that a request queue has a passthrough keyslot manager, it doesn't attempt to program any encryption context into the keyslot manager. The passthrough keyslot manager only allows the device to expose its inline encryption capabilities, and a way for upper layers to evict keys if necessary.
There also exist inline encryption hardware that can handle encryption contexts directly, and allow users to pass them a data request along with the encryption context (as opposed to inline encryption hardware that require users to first program a keyslot with an encryption context, and then require the users to pass the keyslot index with the data request). Such devices can also make use of the passthrough keyslot manager.
Patch 2 introduces some keyslot manager functions useful for the device mapper.
Patch 3 introduces the changes for inline encryption support for the device mapper. A DM device only exposes the intersection of the crypto capabilities of its underlying devices. This is so that in case a bio with an encryption context is eventually mapped to an underlying device that doesn't support that encryption context, the blk-crypto-fallback's cipher tfms are allocated ahead of time by the call to blk_crypto_start_using_key.
Each DM target can now also specify the "DM_TARGET_PASSES_CRYPTO" flag in the target type features to opt-in to supporting passing through the underlying inline encryption capabilities. This flag is needed because it doesn't make much semantic sense for certain targets like dm-crypt to expose the underlying inline encryption capabilities to the upper layers. Again, the DM exposes inline encryption capabilities of the underlying devices only if all of them opt-in to passing through inline encryption support.
A keyslot manager is created for a table when it is loaded. However, the mapped device's exposed capabilities *only* updated once the table is swapped in (until the new table is swapped in, the mapped device continues to expose the old table's crypto capabilities).
This patch only allows the keyslot manager's capabilities to *expand* because of table changes. Any attempt to load a new table that doesn't support a crypto capability that the old table did is rejected.
This patch also only exposes the intersection of the underlying device's capabilities, which has the effect of causing en/decryption of a bio to fall back to the kernel crypto API (if the fallback is enabled) whenever any of the underlying devices doesn't support the encryption context of the bio - it might be possible to make the bio only fall back to the kernel crypto API if the bio's target underlying device doesn't support the bio's encryption context, but the use case may be uncommon enough in the first place not to warrant worrying about it right now.
Patch 4 makes DM evict a key from all its underlying devices when asked to evict a key.
Patch 5 makes some DM targets opt-in to passing through inline encryption support. It does not (yet) try to enable this option with dm-raid, since users can "hot add" disks to a raid device, which makes this not completely straightforward (we'll need to ensure that any "hot added" disks must have a superset of the inline encryption capabilities of the rest of the disks in the raid device, due to the way Patch 2 of this series works).
Changes v3 => v4:
- Allocate the memory for the ksm of the mapped device in dm_table_complete(), and install the ksm in the md queue in __bind() (as suggested by Mike). Also drop patch 5 from v3 since it's no longer needed.
- Some cleanups
Changes v2 => v3:
- Split up the main DM patch into 4 separate patches
- Removed the priv variable added to struct keyslot manager in v2
- Use a flag in target type features for opting-in to inline encryption support, instead of using "may_passthrough_inline_crypto"
- cleanups, improve docs and restructure code
Changes v1 => v2:
- Introduce private field to struct blk_keyslot_manager
- Allow the DM keyslot manager to expand its crypto capabilities if the table is changed.
- Make DM reject table changes that would otherwise cause crypto capabilities to be dropped.
- Allocate the DM device's keyslot manager only when at least one crypto capability is supported (since a NULL value for q->ksm represents "no crypto support" anyway).
- Remove the struct blk_keyslot_manager field from struct mapped_device. This patch now relies on just directly setting up the keyslot manager in the request queue, since each DM device is tied to only 1 queue.
Satya Tangirala (5):
block: keyslot-manager: Introduce passthrough keyslot manager
block: keyslot-manager: Introduce functions for device mapper support
dm: add support for passing through inline crypto support
dm: support key eviction from keyslot managers of underlying devices
dm: set DM_TARGET_PASSES_CRYPTO feature for some targets

Quoted 14 lines

 block/blk-crypto.c              |   1 +
 block/keyslot-manager.c         | 146 ++++++++++++++++++++++
 drivers/md/dm-core.h            |   5 +
 drivers/md/dm-flakey.c          |   4 +-
 drivers/md/dm-linear.c          |   5 +-
 drivers/md/dm-table.c           | 210 ++++++++++++++++++++++++++++++++
 drivers/md/dm.c                 |  18 ++-
 include/linux/device-mapper.h   |  11 ++
 include/linux/keyslot-manager.h |  11 ++
 9 files changed, 407 insertions(+), 4 deletions(-)

Signature · 1 line

2.30.0.365.g02bc693789-goog

This set looks good to me now.

To avoid DM needing another rebase on block: Jens (and others), would you like to review patches 1 and 2 (and reply with your Reviewed-by) so I could pickup the DM required keyslot-manager changes along with patches 3-5?

Thanks,
Mike

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Jens Axboe

maintainer

2021-02-10 20:00 UTC #12 lore raw

Quoted 128 lines · Mike Snitzer

Quoted 110 lines · Satya Tangirala
This patch series adds support for inline encryption to the device mapper.
Patch 1 introduces the "passthrough" keyslot manager.
The regular keyslot manager is designed for inline encryption hardware that have only a small fixed number of keyslots. A DM device itself does not actually have only a small fixed number of keyslots - it doesn't actually have any keyslots in the first place, and programming an encryption context into a DM device doesn't make much semantic sense. It is possible for a DM device to set up a keyslot manager with some "sufficiently large" number of keyslots in its request queue, so that upper layers can use the inline encryption capabilities of the DM device's underlying devices, but the memory being allocated for the DM device's keyslots is a waste since they won't actually be used by the DM device.
The passthrough keyslot manager solves this issue - when the block layer sees that a request queue has a passthrough keyslot manager, it doesn't attempt to program any encryption context into the keyslot manager. The passthrough keyslot manager only allows the device to expose its inline encryption capabilities, and a way for upper layers to evict keys if necessary.
There also exist inline encryption hardware that can handle encryption contexts directly, and allow users to pass them a data request along with the encryption context (as opposed to inline encryption hardware that require users to first program a keyslot with an encryption context, and then require the users to pass the keyslot index with the data request). Such devices can also make use of the passthrough keyslot manager.
Patch 2 introduces some keyslot manager functions useful for the device mapper.
Patch 3 introduces the changes for inline encryption support for the device mapper. A DM device only exposes the intersection of the crypto capabilities of its underlying devices. This is so that in case a bio with an encryption context is eventually mapped to an underlying device that doesn't support that encryption context, the blk-crypto-fallback's cipher tfms are allocated ahead of time by the call to blk_crypto_start_using_key.
Each DM target can now also specify the "DM_TARGET_PASSES_CRYPTO" flag in the target type features to opt-in to supporting passing through the underlying inline encryption capabilities. This flag is needed because it doesn't make much semantic sense for certain targets like dm-crypt to expose the underlying inline encryption capabilities to the upper layers. Again, the DM exposes inline encryption capabilities of the underlying devices only if all of them opt-in to passing through inline encryption support.
A keyslot manager is created for a table when it is loaded. However, the mapped device's exposed capabilities *only* updated once the table is swapped in (until the new table is swapped in, the mapped device continues to expose the old table's crypto capabilities).
This patch only allows the keyslot manager's capabilities to *expand* because of table changes. Any attempt to load a new table that doesn't support a crypto capability that the old table did is rejected.
This patch also only exposes the intersection of the underlying device's capabilities, which has the effect of causing en/decryption of a bio to fall back to the kernel crypto API (if the fallback is enabled) whenever any of the underlying devices doesn't support the encryption context of the bio - it might be possible to make the bio only fall back to the kernel crypto API if the bio's target underlying device doesn't support the bio's encryption context, but the use case may be uncommon enough in the first place not to warrant worrying about it right now.
Patch 4 makes DM evict a key from all its underlying devices when asked to evict a key.
Patch 5 makes some DM targets opt-in to passing through inline encryption support. It does not (yet) try to enable this option with dm-raid, since users can "hot add" disks to a raid device, which makes this not completely straightforward (we'll need to ensure that any "hot added" disks must have a superset of the inline encryption capabilities of the rest of the disks in the raid device, due to the way Patch 2 of this series works).
Changes v3 => v4:
- Allocate the memory for the ksm of the mapped device in dm_table_complete(), and install the ksm in the md queue in __bind() (as suggested by Mike). Also drop patch 5 from v3 since it's no longer needed.
- Some cleanups
Changes v2 => v3:
- Split up the main DM patch into 4 separate patches
- Removed the priv variable added to struct keyslot manager in v2
- Use a flag in target type features for opting-in to inline encryption support, instead of using "may_passthrough_inline_crypto"
- cleanups, improve docs and restructure code
Changes v1 => v2:
- Introduce private field to struct blk_keyslot_manager
- Allow the DM keyslot manager to expand its crypto capabilities if the table is changed.
- Make DM reject table changes that would otherwise cause crypto capabilities to be dropped.
- Allocate the DM device's keyslot manager only when at least one crypto capability is supported (since a NULL value for q->ksm represents "no crypto support" anyway).
- Remove the struct blk_keyslot_manager field from struct mapped_device. This patch now relies on just directly setting up the keyslot manager in the request queue, since each DM device is tied to only 1 queue.
Satya Tangirala (5):
block: keyslot-manager: Introduce passthrough keyslot manager
block: keyslot-manager: Introduce functions for device mapper support
dm: add support for passing through inline crypto support
dm: support key eviction from keyslot managers of underlying devices
dm: set DM_TARGET_PASSES_CRYPTO feature for some targets
Quoted 14 lines
 block/blk-crypto.c              |   1 +
 block/keyslot-manager.c         | 146 ++++++++++++++++++++++
 drivers/md/dm-core.h            |   5 +
 drivers/md/dm-flakey.c          |   4 +-
 drivers/md/dm-linear.c          |   5 +-
 drivers/md/dm-table.c           | 210 ++++++++++++++++++++++++++++++++
 drivers/md/dm.c                 |  18 ++-
 include/linux/device-mapper.h   |  11 ++
 include/linux/keyslot-manager.h |  11 ++
 9 files changed, 407 insertions(+), 4 deletions(-)
Signature · 1 line
2.30.0.365.g02bc693789-goog

Quoted 6 lines

This set looks good to me now.
To avoid DM needing another rebase on block: Jens (and others), would you like to review patches 1 and 2 (and reply with your Reviewed-by) so I could pickup the DM required keyslot-manager changes along with patches 3-5?

You can add my acked-by to 1+2 and queue it up.

Signature · 6 lines

Jens Axboe

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Satya Tangirala

author

2021-02-11 23:01 UTC #13 lore raw

Quoted 129 lines · Jens Axboe

Quoted 128 lines · Mike Snitzer
Quoted 124 lines · Satya Tangirala
This patch series adds support for inline encryption to the device mapper.
Patch 1 introduces the "passthrough" keyslot manager.
The regular keyslot manager is designed for inline encryption hardware that have only a small fixed number of keyslots. A DM device itself does not actually have only a small fixed number of keyslots - it doesn't actually have any keyslots in the first place, and programming an encryption context into a DM device doesn't make much semantic sense. It is possible for a DM device to set up a keyslot manager with some "sufficiently large" number of keyslots in its request queue, so that upper layers can use the inline encryption capabilities of the DM device's underlying devices, but the memory being allocated for the DM device's keyslots is a waste since they won't actually be used by the DM device.
The passthrough keyslot manager solves this issue - when the block layer sees that a request queue has a passthrough keyslot manager, it doesn't attempt to program any encryption context into the keyslot manager. The passthrough keyslot manager only allows the device to expose its inline encryption capabilities, and a way for upper layers to evict keys if necessary.
There also exist inline encryption hardware that can handle encryption contexts directly, and allow users to pass them a data request along with the encryption context (as opposed to inline encryption hardware that require users to first program a keyslot with an encryption context, and then require the users to pass the keyslot index with the data request). Such devices can also make use of the passthrough keyslot manager.
Patch 2 introduces some keyslot manager functions useful for the device mapper.
Patch 3 introduces the changes for inline encryption support for the device mapper. A DM device only exposes the intersection of the crypto capabilities of its underlying devices. This is so that in case a bio with an encryption context is eventually mapped to an underlying device that doesn't support that encryption context, the blk-crypto-fallback's cipher tfms are allocated ahead of time by the call to blk_crypto_start_using_key.
Each DM target can now also specify the "DM_TARGET_PASSES_CRYPTO" flag in the target type features to opt-in to supporting passing through the underlying inline encryption capabilities. This flag is needed because it doesn't make much semantic sense for certain targets like dm-crypt to expose the underlying inline encryption capabilities to the upper layers. Again, the DM exposes inline encryption capabilities of the underlying devices only if all of them opt-in to passing through inline encryption support.
A keyslot manager is created for a table when it is loaded. However, the mapped device's exposed capabilities *only* updated once the table is swapped in (until the new table is swapped in, the mapped device continues to expose the old table's crypto capabilities).
This patch only allows the keyslot manager's capabilities to *expand* because of table changes. Any attempt to load a new table that doesn't support a crypto capability that the old table did is rejected.
This patch also only exposes the intersection of the underlying device's capabilities, which has the effect of causing en/decryption of a bio to fall back to the kernel crypto API (if the fallback is enabled) whenever any of the underlying devices doesn't support the encryption context of the bio - it might be possible to make the bio only fall back to the kernel crypto API if the bio's target underlying device doesn't support the bio's encryption context, but the use case may be uncommon enough in the first place not to warrant worrying about it right now.
Patch 4 makes DM evict a key from all its underlying devices when asked to evict a key.
Patch 5 makes some DM targets opt-in to passing through inline encryption support. It does not (yet) try to enable this option with dm-raid, since users can "hot add" disks to a raid device, which makes this not completely straightforward (we'll need to ensure that any "hot added" disks must have a superset of the inline encryption capabilities of the rest of the disks in the raid device, due to the way Patch 2 of this series works).
Changes v3 => v4:
- Allocate the memory for the ksm of the mapped device in dm_table_complete(), and install the ksm in the md queue in __bind() (as suggested by Mike). Also drop patch 5 from v3 since it's no longer needed.
- Some cleanups
Changes v2 => v3:
- Split up the main DM patch into 4 separate patches
- Removed the priv variable added to struct keyslot manager in v2
- Use a flag in target type features for opting-in to inline encryption support, instead of using "may_passthrough_inline_crypto"
- cleanups, improve docs and restructure code
Changes v1 => v2:
- Introduce private field to struct blk_keyslot_manager
- Allow the DM keyslot manager to expand its crypto capabilities if the table is changed.
- Make DM reject table changes that would otherwise cause crypto capabilities to be dropped.
- Allocate the DM device's keyslot manager only when at least one crypto capability is supported (since a NULL value for q->ksm represents "no crypto support" anyway).
- Remove the struct blk_keyslot_manager field from struct mapped_device. This patch now relies on just directly setting up the keyslot manager in the request queue, since each DM device is tied to only 1 queue.
Satya Tangirala (5):
block: keyslot-manager: Introduce passthrough keyslot manager
block: keyslot-manager: Introduce functions for device mapper support
dm: add support for passing through inline crypto support
dm: support key eviction from keyslot managers of underlying devices
dm: set DM_TARGET_PASSES_CRYPTO feature for some targets
 block/blk-crypto.c              |   1 +
 block/keyslot-manager.c         | 146 ++++++++++++++++++++++
 drivers/md/dm-core.h            |   5 +
 drivers/md/dm-flakey.c          |   4 +-
 drivers/md/dm-linear.c          |   5 +-
 drivers/md/dm-table.c           | 210 ++++++++++++++++++++++++++++++++
 drivers/md/dm.c                 |  18 ++-
 include/linux/device-mapper.h   |  11 ++
 include/linux/keyslot-manager.h |  11 ++
 9 files changed, 407 insertions(+), 4 deletions(-)
Signature · 1 line
2.30.0.365.g02bc693789-goog

Quoted 9 lines

Quoted 6 lines
This set looks good to me now.
To avoid DM needing another rebase on block: Jens (and others), would you like to review patches 1 and 2 (and reply with your Reviewed-by) so I could pickup the DM required keyslot-manager changes along with patches 3-5?
You can add my acked-by to 1+2 and queue it up.

I resent the series (as v5) while addressing the comments Eric had on Patch 3 (the changes were only to comments, so no functional changes). I also added the acked/reviewed-bys.

Quoted 3 lines

Signature · 1 line
Jens Axboe

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Mike Snitzer

2021-02-11 23:05 UTC #14 lore raw

Quoted 137 lines · Satya Tangirala

Quoted 136 lines · Jens Axboe
Quoted 134 lines · Mike Snitzer
Quoted 110 lines · Satya Tangirala
This patch series adds support for inline encryption to the device mapper.
Patch 1 introduces the "passthrough" keyslot manager.
The regular keyslot manager is designed for inline encryption hardware that have only a small fixed number of keyslots. A DM device itself does not actually have only a small fixed number of keyslots - it doesn't actually have any keyslots in the first place, and programming an encryption context into a DM device doesn't make much semantic sense. It is possible for a DM device to set up a keyslot manager with some "sufficiently large" number of keyslots in its request queue, so that upper layers can use the inline encryption capabilities of the DM device's underlying devices, but the memory being allocated for the DM device's keyslots is a waste since they won't actually be used by the DM device.
The passthrough keyslot manager solves this issue - when the block layer sees that a request queue has a passthrough keyslot manager, it doesn't attempt to program any encryption context into the keyslot manager. The passthrough keyslot manager only allows the device to expose its inline encryption capabilities, and a way for upper layers to evict keys if necessary.
There also exist inline encryption hardware that can handle encryption contexts directly, and allow users to pass them a data request along with the encryption context (as opposed to inline encryption hardware that require users to first program a keyslot with an encryption context, and then require the users to pass the keyslot index with the data request). Such devices can also make use of the passthrough keyslot manager.
Patch 2 introduces some keyslot manager functions useful for the device mapper.
Patch 3 introduces the changes for inline encryption support for the device mapper. A DM device only exposes the intersection of the crypto capabilities of its underlying devices. This is so that in case a bio with an encryption context is eventually mapped to an underlying device that doesn't support that encryption context, the blk-crypto-fallback's cipher tfms are allocated ahead of time by the call to blk_crypto_start_using_key.
Each DM target can now also specify the "DM_TARGET_PASSES_CRYPTO" flag in the target type features to opt-in to supporting passing through the underlying inline encryption capabilities. This flag is needed because it doesn't make much semantic sense for certain targets like dm-crypt to expose the underlying inline encryption capabilities to the upper layers. Again, the DM exposes inline encryption capabilities of the underlying devices only if all of them opt-in to passing through inline encryption support.
A keyslot manager is created for a table when it is loaded. However, the mapped device's exposed capabilities *only* updated once the table is swapped in (until the new table is swapped in, the mapped device continues to expose the old table's crypto capabilities).
This patch only allows the keyslot manager's capabilities to *expand* because of table changes. Any attempt to load a new table that doesn't support a crypto capability that the old table did is rejected.
This patch also only exposes the intersection of the underlying device's capabilities, which has the effect of causing en/decryption of a bio to fall back to the kernel crypto API (if the fallback is enabled) whenever any of the underlying devices doesn't support the encryption context of the bio - it might be possible to make the bio only fall back to the kernel crypto API if the bio's target underlying device doesn't support the bio's encryption context, but the use case may be uncommon enough in the first place not to warrant worrying about it right now.
Patch 4 makes DM evict a key from all its underlying devices when asked to evict a key.
Patch 5 makes some DM targets opt-in to passing through inline encryption support. It does not (yet) try to enable this option with dm-raid, since users can "hot add" disks to a raid device, which makes this not completely straightforward (we'll need to ensure that any "hot added" disks must have a superset of the inline encryption capabilities of the rest of the disks in the raid device, due to the way Patch 2 of this series works).
Changes v3 => v4:
- Allocate the memory for the ksm of the mapped device in dm_table_complete(), and install the ksm in the md queue in __bind() (as suggested by Mike). Also drop patch 5 from v3 since it's no longer needed.
- Some cleanups
Changes v2 => v3:
- Split up the main DM patch into 4 separate patches
- Removed the priv variable added to struct keyslot manager in v2
- Use a flag in target type features for opting-in to inline encryption support, instead of using "may_passthrough_inline_crypto"
- cleanups, improve docs and restructure code
Changes v1 => v2:
- Introduce private field to struct blk_keyslot_manager
- Allow the DM keyslot manager to expand its crypto capabilities if the table is changed.
- Make DM reject table changes that would otherwise cause crypto capabilities to be dropped.
- Allocate the DM device's keyslot manager only when at least one crypto capability is supported (since a NULL value for q->ksm represents "no crypto support" anyway).
- Remove the struct blk_keyslot_manager field from struct mapped_device. This patch now relies on just directly setting up the keyslot manager in the request queue, since each DM device is tied to only 1 queue.
Satya Tangirala (5):
block: keyslot-manager: Introduce passthrough keyslot manager
block: keyslot-manager: Introduce functions for device mapper support
dm: add support for passing through inline crypto support
dm: support key eviction from keyslot managers of underlying devices
dm: set DM_TARGET_PASSES_CRYPTO feature for some targets
Quoted 14 lines
 block/blk-crypto.c              |   1 +
 block/keyslot-manager.c         | 146 ++++++++++++++++++++++
 drivers/md/dm-core.h            |   5 +
 drivers/md/dm-flakey.c          |   4 +-
 drivers/md/dm-linear.c          |   5 +-
 drivers/md/dm-table.c           | 210 ++++++++++++++++++++++++++++++++
 drivers/md/dm.c                 |  18 ++-
 include/linux/device-mapper.h   |  11 ++
 include/linux/keyslot-manager.h |  11 ++
 9 files changed, 407 insertions(+), 4 deletions(-)
Signature · 1 line
2.30.0.365.g02bc693789-goog
This set looks good to me now.
To avoid DM needing another rebase on block: Jens (and others), would you like to review patches 1 and 2 (and reply with your Reviewed-by) so I could pickup the DM required keyslot-manager changes along with patches 3-5?

Quoted 5 lines

Quoted 2 lines
You can add my acked-by to 1+2 and queue it up.
I resent the series (as v5) while addressing the comments Eric had on Patch 3 (the changes were only to comments, so no functional changes). I also added the acked/reviewed-bys.

I took care of Eric's comments.
And I already staged these changes in linux-next for dm-5.12, see:

https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-5.12

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

Satya Tangirala

author

2021-02-12 00:47 UTC #15 lore raw

Quoted 142 lines · Mike Snitzer

Quoted 139 lines · Satya Tangirala
Quoted 138 lines · Jens Axboe
Quoted 128 lines · Mike Snitzer
Quoted 110 lines · Satya Tangirala
This patch series adds support for inline encryption to the device mapper.
Patch 1 introduces the "passthrough" keyslot manager.
The regular keyslot manager is designed for inline encryption hardware that have only a small fixed number of keyslots. A DM device itself does not actually have only a small fixed number of keyslots - it doesn't actually have any keyslots in the first place, and programming an encryption context into a DM device doesn't make much semantic sense. It is possible for a DM device to set up a keyslot manager with some "sufficiently large" number of keyslots in its request queue, so that upper layers can use the inline encryption capabilities of the DM device's underlying devices, but the memory being allocated for the DM device's keyslots is a waste since they won't actually be used by the DM device.
The passthrough keyslot manager solves this issue - when the block layer sees that a request queue has a passthrough keyslot manager, it doesn't attempt to program any encryption context into the keyslot manager. The passthrough keyslot manager only allows the device to expose its inline encryption capabilities, and a way for upper layers to evict keys if necessary.
There also exist inline encryption hardware that can handle encryption contexts directly, and allow users to pass them a data request along with the encryption context (as opposed to inline encryption hardware that require users to first program a keyslot with an encryption context, and then require the users to pass the keyslot index with the data request). Such devices can also make use of the passthrough keyslot manager.
Patch 2 introduces some keyslot manager functions useful for the device mapper.
Patch 3 introduces the changes for inline encryption support for the device mapper. A DM device only exposes the intersection of the crypto capabilities of its underlying devices. This is so that in case a bio with an encryption context is eventually mapped to an underlying device that doesn't support that encryption context, the blk-crypto-fallback's cipher tfms are allocated ahead of time by the call to blk_crypto_start_using_key.
Each DM target can now also specify the "DM_TARGET_PASSES_CRYPTO" flag in the target type features to opt-in to supporting passing through the underlying inline encryption capabilities. This flag is needed because it doesn't make much semantic sense for certain targets like dm-crypt to expose the underlying inline encryption capabilities to the upper layers. Again, the DM exposes inline encryption capabilities of the underlying devices only if all of them opt-in to passing through inline encryption support.
A keyslot manager is created for a table when it is loaded. However, the mapped device's exposed capabilities *only* updated once the table is swapped in (until the new table is swapped in, the mapped device continues to expose the old table's crypto capabilities).
This patch only allows the keyslot manager's capabilities to *expand* because of table changes. Any attempt to load a new table that doesn't support a crypto capability that the old table did is rejected.
This patch also only exposes the intersection of the underlying device's capabilities, which has the effect of causing en/decryption of a bio to fall back to the kernel crypto API (if the fallback is enabled) whenever any of the underlying devices doesn't support the encryption context of the bio - it might be possible to make the bio only fall back to the kernel crypto API if the bio's target underlying device doesn't support the bio's encryption context, but the use case may be uncommon enough in the first place not to warrant worrying about it right now.
Patch 4 makes DM evict a key from all its underlying devices when asked to evict a key.
Patch 5 makes some DM targets opt-in to passing through inline encryption support. It does not (yet) try to enable this option with dm-raid, since users can "hot add" disks to a raid device, which makes this not completely straightforward (we'll need to ensure that any "hot added" disks must have a superset of the inline encryption capabilities of the rest of the disks in the raid device, due to the way Patch 2 of this series works).
Changes v3 => v4:
- Allocate the memory for the ksm of the mapped device in dm_table_complete(), and install the ksm in the md queue in __bind() (as suggested by Mike). Also drop patch 5 from v3 since it's no longer needed.
- Some cleanups
Changes v2 => v3:
- Split up the main DM patch into 4 separate patches
- Removed the priv variable added to struct keyslot manager in v2
- Use a flag in target type features for opting-in to inline encryption support, instead of using "may_passthrough_inline_crypto"
- cleanups, improve docs and restructure code
Changes v1 => v2:
- Introduce private field to struct blk_keyslot_manager
- Allow the DM keyslot manager to expand its crypto capabilities if the table is changed.
- Make DM reject table changes that would otherwise cause crypto capabilities to be dropped.
- Allocate the DM device's keyslot manager only when at least one crypto capability is supported (since a NULL value for q->ksm represents "no crypto support" anyway).
- Remove the struct blk_keyslot_manager field from struct mapped_device. This patch now relies on just directly setting up the keyslot manager in the request queue, since each DM device is tied to only 1 queue.
Satya Tangirala (5):
block: keyslot-manager: Introduce passthrough keyslot manager
block: keyslot-manager: Introduce functions for device mapper support
dm: add support for passing through inline crypto support
dm: support key eviction from keyslot managers of underlying devices
dm: set DM_TARGET_PASSES_CRYPTO feature for some targets
Quoted 14 lines
 block/blk-crypto.c              |   1 +
 block/keyslot-manager.c         | 146 ++++++++++++++++++++++
 drivers/md/dm-core.h            |   5 +
 drivers/md/dm-flakey.c          |   4 +-
 drivers/md/dm-linear.c          |   5 +-
 drivers/md/dm-table.c           | 210 ++++++++++++++++++++++++++++++++
 drivers/md/dm.c                 |  18 ++-
 include/linux/device-mapper.h   |  11 ++
 include/linux/keyslot-manager.h |  11 ++
 9 files changed, 407 insertions(+), 4 deletions(-)
Signature · 1 line
2.30.0.365.g02bc693789-goog
Quoted 6 lines
This set looks good to me now.
To avoid DM needing another rebase on block: Jens (and others), would you like to review patches 1 and 2 (and reply with your Reviewed-by) so I could pickup the DM required keyslot-manager changes along with patches 3-5?
You can add my acked-by to 1+2 and queue it up.

Quoted 9 lines

Quoted 3 lines
I resent the series (as v5) while addressing the comments Eric had on Patch 3 (the changes were only to comments, so no functional changes). I also added the acked/reviewed-bys.
I took care of Eric's comments.
And I already staged these changes in linux-next for dm-5.12, see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-5.12

Ah, I didn't see that till a little while ago. Thanks!

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel