From patchwork Thu Feb 11 22:53:39 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Satya Tangirala X-Patchwork-Id: 12084307 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-26.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A9CDC433E9 for ; Thu, 11 Feb 2021 22:54:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E3D3E64E55 for ; Thu, 11 Feb 2021 22:54:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229988AbhBKWyf (ORCPT ); Thu, 11 Feb 2021 17:54:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229623AbhBKWyb (ORCPT ); Thu, 11 Feb 2021 17:54:31 -0500 Received: from mail-qk1-x74a.google.com (mail-qk1-x74a.google.com [IPv6:2607:f8b0:4864:20::74a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99A91C0613D6 for ; Thu, 11 Feb 2021 14:53:51 -0800 (PST) Received: by mail-qk1-x74a.google.com with SMTP id i5so5704927qkk.22 for ; Thu, 11 Feb 2021 14:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=7AM0u1xvi8rWerhtus0gkgsr+ctRsqYSopY+7YCNCuU=; b=YHXMLWoRrs5Tga9v4ug8VhkgXuFjpIarwAkKXOSGVN9CpUwPnymZN47mdVImCVFMzS EFxeY/39D+pMo2q0iXB5AodSVZNHFA2+OVhVxnEmm0bD71USTcZ6rq5j8ZrLK68t88Om tqtRnH5mgB+O8IF/uXdak4RfijjKXjfShaCyTj9hg830vJDVRDB4mAnbG9RVLAypglLz MZ1Q5dDZff3hsRiERW+8pETHyiqbi7yxHOWhPTy/aPdKTfu3Aea3iLm6JCd6UXaJRDBf LJxqb27hVA9csvmQ7nWtvLM2nGxTLPtzjI3AvT0l+Kxrb9pehbLghCxR73b1kz1rslEa Zf9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=7AM0u1xvi8rWerhtus0gkgsr+ctRsqYSopY+7YCNCuU=; b=g+nLaBmCv2URSAaylTKRc5QlFq0AUfmRwJHSeRAjA60MmDyNnIOyAz5oy4I96wT0YT 8Ma6m3A305IvlG9ZjIpZ9kmrjplaSIXx3LqcHAgF6lGlcZlUNwJ+/Xj8O0GuJMOCI9Lg n/ojrihClzIr88DNiYgpbl2ntMNxGQu6CAgcbKZq6IM3nw0SJ2/4ldLOYj9YF2qyTjSf ol1M5pOOPRfqZYSR+qTeE5g2iVLDhqzc75KIU1zX92vEFuHfo6VDQfQ0ZnPokrKXhrZ6 I7H2/Qbujqc1aj1vFyFUXpmR+th2HrnUkzGp5FguoBs0ayIS21YhZzTzmWBv9dhseyDp aA2Q== X-Gm-Message-State: AOAM5318ZGQVD6zmSKyoi0qabKLOwQhxq1f7IITDi5RUgeUhgV8vE6Iz 8vB2nn55lx6j7e1dieaczNo5uEPfEh3mIQtv4ri2acSK826AipJ0c3prDQs8kNr6ewMTofKAk/d VTuG9YK05Fdj7ztZGnua9tGVortMTuXVqJY+szc4dpRcoMJSLbUJH9EVVgD2yoNjE9AYQ X-Google-Smtp-Source: ABdhPJwtQFk7Sp4imxBMUoJh2UPtarEaoN31R7oWcM+JFisbkGFAI60SrSiHOXgLIFdEnZappBCaiKruEHM= Sender: "satyat via sendgmr" X-Received: from satyaprateek.c.googlers.com ([fda3:e722:ac3:10:24:72f4:c0a8:1092]) (user=satyat job=sendgmr) by 2002:a0c:fd47:: with SMTP id j7mr73482qvs.22.1613084030680; Thu, 11 Feb 2021 14:53:50 -0800 (PST) Date: Thu, 11 Feb 2021 22:53:39 +0000 In-Reply-To: <20210211225343.3145732-1-satyat@google.com> Message-Id: <20210211225343.3145732-2-satyat@google.com> Mime-Version: 1.0 References: <20210211225343.3145732-1-satyat@google.com> X-Mailer: git-send-email 2.30.0.478.g8a0d178c01-goog Subject: [PATCH v5 1/5] block: keyslot-manager: Introduce passthrough keyslot manager From: Satya Tangirala To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com Cc: Jens Axboe , Alasdair Kergon , Mike Snitzer , Eric Biggers , Satya Tangirala Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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 Reviewed-by: Eric Biggers Acked-by: Jens Axboe --- block/keyslot-manager.c | 39 +++++++++++++++++++++++++++++++++ include/linux/keyslot-manager.h | 2 ++ 2 files changed, 41 insertions(+) diff --git a/block/keyslot-manager.c b/block/keyslot-manager.c index 86f8195d8039..ac7ce83a76e8 100644 --- a/block/keyslot-manager.c +++ b/block/keyslot-manager.c @@ -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); 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 */ From patchwork Thu Feb 11 22:53:40 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Satya Tangirala X-Patchwork-Id: 12084309 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-26.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CEDEC433DB for ; Thu, 11 Feb 2021 22:55:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 233AB64DD7 for ; Thu, 11 Feb 2021 22:55:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229981AbhBKWzT (ORCPT ); Thu, 11 Feb 2021 17:55:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229678AbhBKWzM (ORCPT ); Thu, 11 Feb 2021 17:55:12 -0500 Received: from mail-qt1-x849.google.com (mail-qt1-x849.google.com [IPv6:2607:f8b0:4864:20::849]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B41EC06178A for ; Thu, 11 Feb 2021 14:53:53 -0800 (PST) Received: by mail-qt1-x849.google.com with SMTP id l1so5416633qtv.2 for ; Thu, 11 Feb 2021 14:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=LEq8KQgToLHDFLukg3IA/L6jXFJZY5RJ8/C/8sWM9bg=; b=cfxPRfaeOWkFY/L/L9jNj52lieSncLRLXzemWHWWTufGS5U4atj4cLMfrds4Lffkca z5t8xUizN2KJpKzXb0gRePrKObrT1Tvpeo1rGlg5Ejo49NXLKgxvwxE6sPs+IKwTKROJ sOkvShGkJfcrA6ww9YXoHGcsU05ClCRcEKvdWYRf27uO/MVrL2yDhSeDPhonU6jRMg6q 7oT8X9+DjByk88vNjjcn/5P2E0V46OKip/ZuTP1T6AX+pFp45shzxNxcCZoedymR2Vzv 7Oxyw4RpYATCCq7kyJCa3mPpGaxe4a6IWtNpdpRgB5AQvfiGclBD1UcM/2fSuO+1EV5L wGcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=LEq8KQgToLHDFLukg3IA/L6jXFJZY5RJ8/C/8sWM9bg=; b=MitqFLv3xz4C0lRtqO+pwC+JOKzzGnex6gXgYpSY/p1WpJy3/4FvUw6/7OEfb/UHoc pPCjaXw1klR43fsmXdMCsEi4eDOYFbr2HeK/APa8G3jTl9KIjOt47gMX+9FmXQVBTdFO lST0kMi8NRxgFvmmKCYocSYeq5BNNsBzHruQaTI9ZbKLqshqoEmSnuvrAZDZKVASgMVz 5giQQlnyxGvDCMn6dyW1HBXhHhWzwwVqsVqdAwqT+g4fM+ebZ8RBsKgyJvwLXmeeGXrP Z5BTXbWtm1PHSIeklsyv5MEx2NyAbhVzmK2SmM73yLUa3KtDDHdZNcSVnf3Li77hhB6m 2BGQ== X-Gm-Message-State: AOAM530Q0f/e/I8hU3G22SNjoxEW0vkv4ljzqL+/IBkn5+zh2v+F8RSH xipM/YBLR58XYAyNvewHgQbxpMGh9NX0ndaOWDha7w2C2f99RuDoUZTrN9JEpyHgiQ2PRzL9sEO aTcrfh8fpqeqmy6jhoLcfbAPRBv1YLNobcR4g88d7IUMlUnSPjrPVogh4Lhjtp2AtWjZF X-Google-Smtp-Source: ABdhPJzU6jFScAHGFijK35P5cXMgSVrIx3//GWGgork74oEnZjzGA16Xgz8KrT+2lLzdU5IOp/ZdJhd9Et8= Sender: "satyat via sendgmr" X-Received: from satyaprateek.c.googlers.com ([fda3:e722:ac3:10:24:72f4:c0a8:1092]) (user=satyat job=sendgmr) by 2002:a05:6214:1110:: with SMTP id e16mr127390qvs.62.1613084032486; Thu, 11 Feb 2021 14:53:52 -0800 (PST) Date: Thu, 11 Feb 2021 22:53:40 +0000 In-Reply-To: <20210211225343.3145732-1-satyat@google.com> Message-Id: <20210211225343.3145732-3-satyat@google.com> Mime-Version: 1.0 References: <20210211225343.3145732-1-satyat@google.com> X-Mailer: git-send-email 2.30.0.478.g8a0d178c01-goog Subject: [PATCH v5 2/5] block: keyslot-manager: Introduce functions for device mapper support From: Satya Tangirala To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com Cc: Jens Axboe , Alasdair Kergon , Mike Snitzer , Eric Biggers , Satya Tangirala Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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 Reviewed-by: Eric Biggers Acked-by: Jens Axboe --- block/keyslot-manager.c | 107 ++++++++++++++++++++++++++++++++ include/linux/keyslot-manager.h | 9 +++ 2 files changed, 116 insertions(+) diff --git a/block/keyslot-manager.c b/block/keyslot-manager.c index ac7ce83a76e8..9f9494b80148 100644 --- a/block/keyslot-manager.c +++ b/block/keyslot-manager.c @@ -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 diff --git a/include/linux/keyslot-manager.h b/include/linux/keyslot-manager.h index 323e15dd6fa7..164568f52be7 100644 --- a/include/linux/keyslot-manager.h +++ b/include/linux/keyslot-manager.h @@ -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 */ From patchwork Thu Feb 11 22:53:41 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Satya Tangirala X-Patchwork-Id: 12084311 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-26.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A19FCC433E0 for ; Thu, 11 Feb 2021 22:55:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F90364DD7 for ; Thu, 11 Feb 2021 22:55:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230134AbhBKWzW (ORCPT ); Thu, 11 Feb 2021 17:55:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229777AbhBKWzO (ORCPT ); Thu, 11 Feb 2021 17:55:14 -0500 Received: from mail-qk1-x749.google.com (mail-qk1-x749.google.com [IPv6:2607:f8b0:4864:20::749]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 340F6C06178C for ; Thu, 11 Feb 2021 14:53:55 -0800 (PST) Received: by mail-qk1-x749.google.com with SMTP id r15so5766045qke.5 for ; Thu, 11 Feb 2021 14:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=nMk2rpCCOeT8dI5UTilvWQY64g/eZhRKWUUyT5Ql4No=; b=C8iBF1ueyOKFu2vl33L9zFcRuhPmqdByeBFr8XrUOKKYRy5p8LQjoVwgzqb7sfnMmO na8mDZX/jZ2S6pzYjdQkyI9mfjNAMk/PpaiJhrJTCn3VWpX+vxrSThxDjyLBwi8RYV+z jNbpjp62GHsgVR/bPjgBuhccwnwqBV0rJHn1+d6B3c5rz6w7V1QJ2NU0rmYe4468xmaC 2JUSyS2zwc1xTd18HCCrun8Qp/nnEGIJrcPttdn9dYC2mqtXSFSYL8RKBJXi+h+Fs/SP /fDU614hXvW4xJygc/EpqElZg/o9YeMFb5mYKHpx8+NCQFC3cAveULBTzuFel76DcSba 2vRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=nMk2rpCCOeT8dI5UTilvWQY64g/eZhRKWUUyT5Ql4No=; b=jEfmJTgGjZfn3RU+rJCJ51fKZ0KntXLsBwtpZ1LeGiWyMAGKqV2+y5ZpK2tj5I9k9W IcTQrRv2m/FpVfU+vwnWlV2rwWz3HGnihHGIEPEcoLZECmRCMKS/ypWeu8AeO6+rC2pZ iDhe9hI1AJWS8rBxrTYkQRtY88FH28sKMAvaPLyONJhnfcX8ggCgX8Jp8cMlfv+4A9aU SuuUzYVs/MiFn4bHCuc7M65UIm2qQaMrhaVAO8hPA2VFcp1+ufV1O9Lxgcncez34pZnY piXlykEN+Ercqru7x3Tvg4FqNFYgih5tT8TQEX+I7xYULx28JHhKj/lq6ekYDeXgabDW EYWw== X-Gm-Message-State: AOAM533rXxgxcxLBtW5Hw00j7P2rsLLINDuKBnTMigwluC+DQqtBwwsP HQw9RqrHmQIsg2Z3fax3I41uKOTvcFDxs4eaHyB1pIjum/HTey0wJ44jkZtweUqpCRG/4kAuujf iuPXL6NEaQhOt+/Zz9dv73tdSCG/grfJ88NpLItRP3ZpJLMTzzWqLftl0djFTps81JXlD X-Google-Smtp-Source: ABdhPJyG32mdUz4eBbKeGyy/PmmHbi/ttUKwroKRd3kbGS67NKnukMk6VMjhAKDuY6XFP1/8km2XyBVIT2o= Sender: "satyat via sendgmr" X-Received: from satyaprateek.c.googlers.com ([fda3:e722:ac3:10:24:72f4:c0a8:1092]) (user=satyat job=sendgmr) by 2002:a05:6214:574:: with SMTP id cj20mr185686qvb.37.1613084034268; Thu, 11 Feb 2021 14:53:54 -0800 (PST) Date: Thu, 11 Feb 2021 22:53:41 +0000 In-Reply-To: <20210211225343.3145732-1-satyat@google.com> Message-Id: <20210211225343.3145732-4-satyat@google.com> Mime-Version: 1.0 References: <20210211225343.3145732-1-satyat@google.com> X-Mailer: git-send-email 2.30.0.478.g8a0d178c01-goog Subject: [PATCH v5 3/5] dm: add support for passing through inline crypto support From: Satya Tangirala To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com Cc: Jens Axboe , Alasdair Kergon , Mike Snitzer , Eric Biggers , Satya Tangirala Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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 Signed-off-by: Eric Biggers Signed-off-by: Satya Tangirala Reviewed-by: Eric Biggers --- drivers/md/dm-core.h | 12 +++ drivers/md/dm-table.c | 159 ++++++++++++++++++++++++++++++++++ drivers/md/dm.c | 18 +++- include/linux/device-mapper.h | 12 +++ 4 files changed, 200 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-core.h b/drivers/md/dm-core.h index 086d293c2b03..f4196ecd6132 100644 --- a/drivers/md/dm-core.h +++ b/drivers/md/dm-core.h @@ -13,6 +13,7 @@ #include #include #include +#include #include @@ -162,6 +163,17 @@ struct dm_table { void *event_context; struct dm_md_mempools *mempools; + +#ifdef CONFIG_BLK_INLINE_ENCRYPTION + /* + * Keyslot manager representing the crypto capabilities of this table. + * This field is only set temporarily, while the table is loaded but + * not swapped in. When the table is swapped in, this field is set to + * NULL after the capabilities are transferred to the request queue of + * the device. + */ + struct blk_keyslot_manager *ksm; +#endif }; static inline struct completion *dm_get_completion_from_kobject(struct kobject *kobj) diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 4acf2342f7ad..fbaadfc6eed9 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -187,6 +187,8 @@ static void free_devices(struct list_head *devices, struct mapped_device *md) } } +static void dm_table_destroy_keyslot_manager(struct dm_table *t); + void dm_table_destroy(struct dm_table *t) { unsigned int i; @@ -215,6 +217,8 @@ void dm_table_destroy(struct dm_table *t) dm_free_md_mempools(t->mempools); + dm_table_destroy_keyslot_manager(t); + kfree(t); } @@ -1203,6 +1207,154 @@ static int dm_table_register_integrity(struct dm_table *t) return 0; } +#ifdef CONFIG_BLK_INLINE_ENCRYPTION + +struct dm_keyslot_manager { + struct blk_keyslot_manager ksm; + struct mapped_device *md; +}; + +static int device_intersect_crypto_modes(struct dm_target *ti, + struct dm_dev *dev, sector_t start, + sector_t len, void *data) +{ + struct blk_keyslot_manager *parent = data; + struct blk_keyslot_manager *child = bdev_get_queue(dev->bdev)->ksm; + + blk_ksm_intersect_modes(parent, child); + return 0; +} + +void dm_destroy_keyslot_manager(struct blk_keyslot_manager *ksm) +{ + struct dm_keyslot_manager *dksm = container_of(ksm, + struct dm_keyslot_manager, + ksm); + + if (!ksm) + return; + + blk_ksm_destroy(ksm); + kfree(dksm); +} + +static void dm_table_destroy_keyslot_manager(struct dm_table *t) +{ + dm_destroy_keyslot_manager(t->ksm); + t->ksm = NULL; +} + +/* + * Initializes t->ksm with a keyslot manager that represents the common set of + * 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 set @t->ksm to NULL + * (since a NULL ksm represents support for no capabilities) and returns 0 + * (representing success). + */ +static int +dm_table_construct_keyslot_manager(struct dm_table *t) +{ + struct dm_keyslot_manager *dksm; + struct blk_keyslot_manager *ksm; + struct dm_target *ti; + unsigned int i; + bool ksm_is_empty = true; + + dksm = kmalloc(sizeof(*dksm), GFP_KERNEL); + if (!dksm) + return -ENOMEM; + dksm->md = t->md; + + ksm = &dksm->ksm; + blk_ksm_init_passthrough(ksm); + ksm->max_dun_bytes_supported = UINT_MAX; + memset(ksm->crypto_modes_supported, 0xFF, + sizeof(ksm->crypto_modes_supported)); + + for (i = 0; i < dm_table_get_num_targets(t); i++) { + ti = dm_table_get_target(t, i); + + if (!dm_target_passes_crypto(ti->type)) { + blk_ksm_intersect_modes(ksm, NULL); + break; + } + if (!ti->type->iterate_devices) + continue; + ti->type->iterate_devices(ti, device_intersect_crypto_modes, + ksm); + } + + if (t->md->queue && !blk_ksm_is_superset(ksm, t->md->queue->ksm)) { + DMWARN("Inline encryption capabilities of new DM table were more restrictive than the old table's. This is not supported!"); + dm_destroy_keyslot_manager(ksm); + return -EINVAL; + } + + /* + * If the new KSM doesn't actually support any crypto modes, we may as + * well represent it with a NULL ksm. + */ + ksm_is_empty = true; + for (i = 0; i < ARRAY_SIZE(ksm->crypto_modes_supported); i++) { + if (ksm->crypto_modes_supported[i]) { + ksm_is_empty = false; + break; + } + } + + if (ksm_is_empty) { + dm_destroy_keyslot_manager(ksm); + ksm = NULL; + } + + t->ksm = ksm; + + return 0; +} + +static void dm_update_keyslot_manager(struct request_queue *q, + struct dm_table *t) +{ + if (!t->ksm) + return; + + /* Make the ksm less restrictive */ + if (!q->ksm) { + blk_ksm_register(t->ksm, q); + } else { + blk_ksm_update_capabilities(q->ksm, t->ksm); + dm_destroy_keyslot_manager(t->ksm); + } + t->ksm = NULL; +} + +#else /* CONFIG_BLK_INLINE_ENCRYPTION */ + +static int +dm_table_construct_keyslot_manager(struct dm_table *t) +{ + return 0; +} + +void dm_destroy_keyslot_manager(struct blk_keyslot_manager *ksm) +{ +} + +static void dm_table_destroy_keyslot_manager(struct dm_table *t) +{ +} + +static void dm_update_keyslot_manager(struct request_queue *q, + struct dm_table *t) +{ +} + +#endif /* !CONFIG_BLK_INLINE_ENCRYPTION */ + /* * Prepares the table for use by building the indices, * setting the type, and allocating mempools. @@ -1229,6 +1381,12 @@ int dm_table_complete(struct dm_table *t) return r; } + r = dm_table_construct_keyslot_manager(t); + if (r) { + DMERR("could not construct keyslot manager."); + return r; + } + r = dm_table_alloc_md_mempools(t, t->md); if (r) DMERR("unable to allocate mempools"); @@ -1891,6 +2049,7 @@ void dm_table_set_restrictions(struct dm_table *t, struct request_queue *q, } #endif + dm_update_keyslot_manager(q, t); blk_queue_update_readahead(q); } diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 7bac564f3faa..ee0434764941 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -28,6 +28,7 @@ #include #include #include +#include #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); diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h index 61a66fb8ebb3..f7198b492fea 100644 --- a/include/linux/device-mapper.h +++ b/include/linux/device-mapper.h @@ -257,6 +257,13 @@ struct target_type { #define DM_TARGET_NOWAIT 0x00000080 #define dm_target_supports_nowait(type) ((type)->features & DM_TARGET_NOWAIT) +/* + * The target supports exposing the underlying device's inline encryption + * capabilities + */ +#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 +540,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. */ From patchwork Thu Feb 11 22:53:42 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Satya Tangirala X-Patchwork-Id: 12084313 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-26.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49336C433E6 for ; Thu, 11 Feb 2021 22:55:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1078964E44 for ; Thu, 11 Feb 2021 22:55:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229777AbhBKWzX (ORCPT ); Thu, 11 Feb 2021 17:55:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229943AbhBKWzO (ORCPT ); Thu, 11 Feb 2021 17:55:14 -0500 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA0CCC061794 for ; Thu, 11 Feb 2021 14:53:56 -0800 (PST) Received: by mail-pg1-x549.google.com with SMTP id v16so5727944pgl.23 for ; Thu, 11 Feb 2021 14:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=PzZ3HqYXXMl4x2ko2AkyE6044tKsCbJJ6g3BR1Cqc4U=; b=VMR9fwBw+N+vaWHcFXK3rnI3ZsKDRmCwOY3WpZeIPfakOWfkpzv6nTp2m4BxJougLu A2yAYOJhIUSD1hhs64JoQjmNyH5A7WJs05SQcL2sC+vkVM6hkRrlA7AC+xgoKHv9bKI8 YzAMCxey9+mHDKWIlO1Ctl660ve7MgD+1YLon2hGTuxrUayqc+WMtU4lDCROP4+wG+Lu YBoY5jq97Wl+F7sgPnG8xifCNHHNfTxsCaUrN+DvVeP/A9Rx+Zvmw3Km8fmcXLKK0kR2 WpbHlT9IroRY7+RWkcuqD5mrI5R3952W27wss+dOUNgkiPFSUFxYT3QoaJdsGeE56ahJ 4Qng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=PzZ3HqYXXMl4x2ko2AkyE6044tKsCbJJ6g3BR1Cqc4U=; b=uUQgJ5E/jskeUH/fzKRjTUwKrcH8f/AJb9ORBtLZhpnGnhuD9bSYFeu7L9oOwRdeRx BNNA+Nfp+M/8UaDr4EBheE2/3yw7WjNq+SgvHOatFTOH77iz8yA2musX16clnYzoC2rA E/yRFjGHPzuiMb0rrA9nufRraO+i+fWSln91O80EtpXBOcLCDU5qwiSqDCMoVhRH06Mj KDQIKrlnSOZzoTVD69w6DFGzRsVVZue9yVo3s6GfC05KGovDO1hcS9afAC//SL+57Osh f7yT/aKoBdF9JBVUnsJveL15gn0wOMZLmyQYtUq5EBv8x3IJCu71zPdzoiC4Vzt9ZvSM TGsQ== X-Gm-Message-State: AOAM530A1H5pQOnG6WbvjYHkyziGVAIvl91BNTc1rfqGb0csN1+QNnXg 5inZUQwW5D87ClBiTjH3f2HhGYVXzRlKaIj5hGrLsyNrXijNr2BY/pdQHp2uUQjawmpZtGUHhlo teHNjeZgdd32xhgYxl90k4e2q3Dr5pW8eVOTcrnfPBz/1rXhGTlMD9cPBJog2El7Io6ia X-Google-Smtp-Source: ABdhPJxr7Lu0fj77ZerbVC8vr9ZFlGLKh5WjfVS661/jKvtGrdEM4EOTjautbcR2338CpJZzoQ2SJIKLixQ= Sender: "satyat via sendgmr" X-Received: from satyaprateek.c.googlers.com ([fda3:e722:ac3:10:24:72f4:c0a8:1092]) (user=satyat job=sendgmr) by 2002:a17:90b:1217:: with SMTP id gl23mr5924163pjb.163.1613084036078; Thu, 11 Feb 2021 14:53:56 -0800 (PST) Date: Thu, 11 Feb 2021 22:53:42 +0000 In-Reply-To: <20210211225343.3145732-1-satyat@google.com> Message-Id: <20210211225343.3145732-5-satyat@google.com> Mime-Version: 1.0 References: <20210211225343.3145732-1-satyat@google.com> X-Mailer: git-send-email 2.30.0.478.g8a0d178c01-goog Subject: [PATCH v5 4/5] dm: support key eviction from keyslot managers of underlying devices From: Satya Tangirala To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com Cc: Jens Axboe , Alasdair Kergon , Mike Snitzer , Eric Biggers , Satya Tangirala Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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 Signed-off-by: Eric Biggers Signed-off-by: Satya Tangirala Reviewed-by: Eric Biggers --- block/blk-crypto.c | 1 + drivers/md/dm-table.c | 53 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+) diff --git a/block/blk-crypto.c b/block/blk-crypto.c index 5da43f0973b4..c2be8f15006c 100644 --- a/block/blk-crypto.c +++ b/block/blk-crypto.c @@ -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); diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index fbaadfc6eed9..b036a349aaad 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -1214,6 +1214,58 @@ struct dm_keyslot_manager { struct mapped_device *md; }; +struct dm_keyslot_evict_args { + const struct blk_crypto_key *key; + int err; +}; + +static int dm_keyslot_evict_callback(struct dm_target *ti, struct dm_dev *dev, + sector_t start, sector_t len, void *data) +{ + struct dm_keyslot_evict_args *args = data; + int err; + + err = blk_crypto_evict_key(bdev_get_queue(dev->bdev), args->key); + if (!args->err) + args->err = err; + /* Always try to evict the key from all devices. */ + return 0; +} + +/* + * When an inline encryption key is evicted from a device-mapper device, evict + * it from all the underlying devices. + */ +static int dm_keyslot_evict(struct blk_keyslot_manager *ksm, + const struct blk_crypto_key *key, unsigned int slot) +{ + struct dm_keyslot_manager *dksm = container_of(ksm, + struct dm_keyslot_manager, + ksm); + struct mapped_device *md = dksm->md; + struct dm_keyslot_evict_args args = { key }; + struct dm_table *t; + int srcu_idx; + int i; + struct dm_target *ti; + + t = dm_get_live_table(md, &srcu_idx); + if (!t) + return 0; + for (i = 0; i < dm_table_get_num_targets(t); i++) { + ti = dm_table_get_target(t, i); + if (!ti->type->iterate_devices) + continue; + ti->type->iterate_devices(ti, dm_keyslot_evict_callback, &args); + } + dm_put_live_table(md, srcu_idx); + return args.err; +} + +static struct blk_ksm_ll_ops dm_ksm_ll_ops = { + .keyslot_evict = dm_keyslot_evict, +}; + static int device_intersect_crypto_modes(struct dm_target *ti, struct dm_dev *dev, sector_t start, sector_t len, void *data) @@ -1271,6 +1323,7 @@ dm_table_construct_keyslot_manager(struct dm_table *t) ksm = &dksm->ksm; blk_ksm_init_passthrough(ksm); + ksm->ksm_ll_ops = dm_ksm_ll_ops; ksm->max_dun_bytes_supported = UINT_MAX; memset(ksm->crypto_modes_supported, 0xFF, sizeof(ksm->crypto_modes_supported)); From patchwork Thu Feb 11 22:53:43 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Satya Tangirala X-Patchwork-Id: 12084315 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-26.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54EFFC433DB for ; Thu, 11 Feb 2021 22:55:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 115CF64E42 for ; Thu, 11 Feb 2021 22:55:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230150AbhBKWzX (ORCPT ); Thu, 11 Feb 2021 17:55:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229946AbhBKWzP (ORCPT ); Thu, 11 Feb 2021 17:55:15 -0500 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C311AC0617A7 for ; Thu, 11 Feb 2021 14:53:58 -0800 (PST) Received: by mail-yb1-xb4a.google.com with SMTP id i2so7728814ybl.16 for ; Thu, 11 Feb 2021 14:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=PxM9IT9eyGUZNP1LzuDRc/mngpIW4AQ9SBaT5vWfza8=; b=Ucglw7ZkrxpuhIWFGcDbMTMcG+6MYu5YOUu80nYNxay54B1uHqiuqCk1Qi8vWIzCBE gspPnFYy8NosLiC3gpvQJJPsGEwQLooMncjiDV24kf0b85qB2u/DqJ481HBQyjlKYKoe PRoym98ZiZRSORjEzkCqqkjGBMKGGv0J786/ccj+f79WfOZ+XKM2e0u76uQMfDjXO/36 8PySDt9wc0r28i2GymYPEmEwEQnWynLeL7qMnNdR3a+E/OUDMFSoUNRDBOe24DdQVlwz LoMDhNNiYezk2MO4sPOMTVRmNJesB1d2e+Ft4TFy+dDbQacaFsvM5CUsdG5rW60f2vlx Wmcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=PxM9IT9eyGUZNP1LzuDRc/mngpIW4AQ9SBaT5vWfza8=; b=jeZq61mgW3+1tbpJOx4VKYr47dTs8WAXeiujolOJTQchPSqaNs7lPfW1zDoUg1ebiw bMqOPNcdnp22DwwQ9phIim9vs8p7qEJ6EtncK5h0MmsikQ1hBCnlr30rTINT1WiKncBp sHXeckU1esmp318t1hAWJWlZTTRALOc56eLnl857/d/vSH7OBlYowsEGoj9HMgbrFPWJ 6vRk0B41OXVb337JRKbIZhqis8stJv9+K7SZjB9CBzo8aY6MWoG6KXycg3+tjLiPqfBd 1Ft4ffsAA+cmiloGV/FFxZdgR8rKO1YdaaJlVyZa6n/lUb/ADayObwyFGqpypEUyBajX yZew== X-Gm-Message-State: AOAM530dT5Z4KhxJ+KMqGDLuJoUWbdtXJ8SSV9bqb+OBQMyImnG2Dy8R oyPrgy/F11igGpfuDGRcTh7dkQ/9PfabaYVSxajGfPaz6dIrwnSoiY8CFW8WJe2DoZMclr9eGv9 1XzLjzFEhaDPgK7t8dFQoyMMOJ3RKIMVm0dphVh6Qk9u+vrLVrWxPDPQhGt6/BzHA+zAo X-Google-Smtp-Source: ABdhPJyCcEkUUWB8T8w/MJOUbhtPs5xiGKEOUKflHC1JDKFUsf7YIQuwF9tUmiR7CFT6Wa50/QpxaMDywZM= Sender: "satyat via sendgmr" X-Received: from satyaprateek.c.googlers.com ([fda3:e722:ac3:10:24:72f4:c0a8:1092]) (user=satyat job=sendgmr) by 2002:a25:b749:: with SMTP id e9mr170105ybm.457.1613084037955; Thu, 11 Feb 2021 14:53:57 -0800 (PST) Date: Thu, 11 Feb 2021 22:53:43 +0000 In-Reply-To: <20210211225343.3145732-1-satyat@google.com> Message-Id: <20210211225343.3145732-6-satyat@google.com> Mime-Version: 1.0 References: <20210211225343.3145732-1-satyat@google.com> X-Mailer: git-send-email 2.30.0.478.g8a0d178c01-goog Subject: [PATCH v5 5/5] dm: set DM_TARGET_PASSES_CRYPTO feature for some targets From: Satya Tangirala To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com Cc: Jens Axboe , Alasdair Kergon , Mike Snitzer , Eric Biggers , Satya Tangirala Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org dm-linear and dm-flakey obviously can pass through inline crypto support. Co-developed-by: Eric Biggers Signed-off-by: Eric Biggers Signed-off-by: Satya Tangirala Reviewed-by: Eric Biggers --- drivers/md/dm-flakey.c | 4 +++- drivers/md/dm-linear.c | 5 +++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/md/dm-flakey.c b/drivers/md/dm-flakey.c index a2cc9e45cbba..30c6bc151213 100644 --- a/drivers/md/dm-flakey.c +++ b/drivers/md/dm-flakey.c @@ -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, diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c index 00774b5d7668..fc9c4272c10d 100644 --- a/drivers/md/dm-linear.c +++ b/drivers/md/dm-linear.c @@ -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,