aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/keyslot-manager.h
diff options
context:
space:
mode:
authorSatya Tangirala <satyat@google.com>2021-02-01 05:10:15 +0000
committerMike Snitzer <snitzer@redhat.com>2021-02-11 09:45:23 -0500
commit7bdcc48f4e80b01fd6057dfd382236a5b8123b61 (patch)
treeea0e672ff5dce33cbc7aa23ff6163be5db431848 /include/linux/keyslot-manager.h
parentdm era: only resize metadata in preresume (diff)
downloadlinux-dev-7bdcc48f4e80b01fd6057dfd382236a5b8123b61.tar.xz
linux-dev-7bdcc48f4e80b01fd6057dfd382236a5b8123b61.zip
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 <satyat@google.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Acked-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Diffstat (limited to 'include/linux/keyslot-manager.h')
-rw-r--r--include/linux/keyslot-manager.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/include/linux/keyslot-manager.h b/include/linux/keyslot-manager.h
index 18f3f5346843..323e15dd6fa7 100644
--- a/include/linux/keyslot-manager.h
+++ b/include/linux/keyslot-manager.h
@@ -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 */