From: Mike Snitzer <snitzer@redhat.com>
To: Satya Tangirala <satyat@google.com>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
dm-devel@redhat.com, Jens Axboe <axboe@kernel.dk>,
Alasdair Kergon <agk@redhat.com>,
Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH v3 2/6] block: keyslot-manager: Introduce functions for device mapper support
Date: Thu, 14 Jan 2021 11:06:29 -0500 [thread overview]
Message-ID: <20210114160628.GA26178@redhat.com> (raw)
In-Reply-To: <20201229085524.2795331-3-satyat@google.com>
On Tue, Dec 29 2020 at 3:55am -0500,
Satya Tangirala <satyat@google.com> wrote:
> 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.
>
> 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 <satyat@google.com>
> ---
> block/keyslot-manager.c | 91 +++++++++++++++++++++++++++++++++
> include/linux/keyslot-manager.h | 9 ++++
> 2 files changed, 100 insertions(+)
>
> diff --git a/block/keyslot-manager.c b/block/keyslot-manager.c
> index ac7ce83a76e8..f13ab7410eca 100644
> --- a/block/keyslot-manager.c
> +++ b/block/keyslot-manager.c
> @@ -424,6 +424,97 @@ 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,
> + */
> +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);
> +
Given the patch header's preamble about FS possibly accessing/checking
the existing ksm: without any locking or other coordination how is
blk_ksm_update_capabilities() safe?
Please document any assumptions about the caller (e.g. DM) that enables
blk_ksm_update_capabilities() to be used safely.
Mike
> /**
> * 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 */
> --
> 2.29.2.729.g45daf8777d-goog
>
next prev parent reply other threads:[~2021-01-14 16:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-29 8:55 [PATCH v3 0/6] add support for inline encryption to device mapper Satya Tangirala
2020-12-29 8:55 ` [PATCH v3 1/6] block: keyslot-manager: Introduce passthrough keyslot manager Satya Tangirala
2020-12-29 8:55 ` [PATCH v3 2/6] block: keyslot-manager: Introduce functions for device mapper support Satya Tangirala
2021-01-14 16:06 ` Mike Snitzer [this message]
2020-12-29 8:55 ` [PATCH v3 3/6] dm: add support for passing through inline crypto support Satya Tangirala
2021-01-14 18:00 ` Mike Snitzer
2021-02-01 5:22 ` Satya Tangirala
2020-12-29 8:55 ` [PATCH v3 4/6] dm: Support key eviction from keyslot managers of underlying devices Satya Tangirala
2020-12-29 8:55 ` [PATCH v3 5/6] dm: Verify inline encryption capabilities of new table when it is loaded Satya Tangirala
2021-01-14 18:04 ` Mike Snitzer
2020-12-29 8:55 ` [PATCH v3 6/6] dm: set DM_TARGET_PASSES_CRYPTO feature for some targets Satya Tangirala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210114160628.GA26178@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=ebiggers@google.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=satyat@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox