| Message ID | 20210721154738.3966463-1-ebiggers@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | mmc: store pointer to bio_crypt_ctx in mmc_request | expand |
On Wed, 21 Jul 2021 at 17:48, Eric Biggers <ebiggers@kernel.org> wrote: > > From: Eric Biggers <ebiggers@google.com> > > Make 'struct mmc_request' contain a pointer to the request's > 'struct bio_crypt_ctx' directly, instead of extracting a 32-bit DUN from > it which is a cqhci-crypto specific detail. > > This keeps the cqhci crypto specific details in the cqhci module, and it > makes mmc_core and mmc_block ready for MMC crypto hardware that accepts > the DUN and/or key in a way that is more flexible than that which will > be specified by the eMMC v5.2 standard. Exynos SoCs are an example of > such hardware, as their inline encryption hardware takes keys directly > (it has no concept of keyslots) and supports 128-bit DUNs. > > Note that the 32-bit DUN length specified by the standard is very > restrictive, so it is likely that more hardware will support longer DUNs > despite it not following the standard. Thus, limiting the scope of the > 32-bit DUN assumption to the place that actually needs it is warranted. > > Signed-off-by: Eric Biggers <ebiggers@google.com> Applied for next, thanks! Kind regards Uffe > --- > > This patch is already being carried in the Android Common Kernels, due > to it being needed by Exynos SoCs. Unfortunately I have no way to > upstream Exynos eMMC inline encryption support at the moment, so this > patch isn't strictly required upstream at the moment. But it may be > worthwhile as a cleanup regardless; it arguably fixes a layering > violation (mmc_core knowing about the details of cqhci crypto). > > drivers/mmc/core/crypto.c | 15 ++++----------- > drivers/mmc/host/cqhci-crypto.h | 7 +++++-- > include/linux/mmc/core.h | 3 +-- > 3 files changed, 10 insertions(+), 15 deletions(-) > > diff --git a/drivers/mmc/core/crypto.c b/drivers/mmc/core/crypto.c > index 419a368f8402..67557808cada 100644 > --- a/drivers/mmc/core/crypto.c > +++ b/drivers/mmc/core/crypto.c > @@ -31,18 +31,11 @@ void mmc_crypto_prepare_req(struct mmc_queue_req *mqrq) > struct request *req = mmc_queue_req_to_req(mqrq); > struct mmc_request *mrq = &mqrq->brq.mrq; > > - if (!req->crypt_keyslot) > + if (!req->crypt_ctx) > return; > > - mrq->crypto_enabled = true; > - mrq->crypto_key_slot = blk_ksm_get_slot_idx(req->crypt_keyslot); > - > - /* > - * For now we assume that all MMC drivers set max_dun_bytes_supported=4, > - * which is the limit for CQHCI crypto. So all DUNs should be 32-bit. > - */ > - WARN_ON_ONCE(req->crypt_ctx->bc_dun[0] > U32_MAX); > - > - mrq->data_unit_num = req->crypt_ctx->bc_dun[0]; > + mrq->crypto_ctx = req->crypt_ctx; > + if (req->crypt_keyslot) > + mrq->crypto_key_slot = blk_ksm_get_slot_idx(req->crypt_keyslot); > } > EXPORT_SYMBOL_GPL(mmc_crypto_prepare_req); > diff --git a/drivers/mmc/host/cqhci-crypto.h b/drivers/mmc/host/cqhci-crypto.h > index 60b58ee0e625..d7fb084f563b 100644 > --- a/drivers/mmc/host/cqhci-crypto.h > +++ b/drivers/mmc/host/cqhci-crypto.h > @@ -22,12 +22,15 @@ int cqhci_crypto_init(struct cqhci_host *host); > */ > static inline u64 cqhci_crypto_prep_task_desc(struct mmc_request *mrq) > { > - if (!mrq->crypto_enabled) > + if (!mrq->crypto_ctx) > return 0; > > + /* We set max_dun_bytes_supported=4, so all DUNs should be 32-bit. */ > + WARN_ON_ONCE(mrq->crypto_ctx->bc_dun[0] > U32_MAX); > + > return CQHCI_CRYPTO_ENABLE_BIT | > CQHCI_CRYPTO_KEYSLOT(mrq->crypto_key_slot) | > - mrq->data_unit_num; > + mrq->crypto_ctx->bc_dun[0]; > } > > #else /* CONFIG_MMC_CRYPTO */ > diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h > index ab19245e9945..71101d1ec825 100644 > --- a/include/linux/mmc/core.h > +++ b/include/linux/mmc/core.h > @@ -164,9 +164,8 @@ struct mmc_request { > int tag; > > #ifdef CONFIG_MMC_CRYPTO > - bool crypto_enabled; > + const struct bio_crypt_ctx *crypto_ctx; > int crypto_key_slot; > - u32 data_unit_num; > #endif > }; > > -- > 2.32.0.402.g57bb445576-goog >
diff --git a/drivers/mmc/core/crypto.c b/drivers/mmc/core/crypto.c index 419a368f8402..67557808cada 100644 --- a/drivers/mmc/core/crypto.c +++ b/drivers/mmc/core/crypto.c @@ -31,18 +31,11 @@ void mmc_crypto_prepare_req(struct mmc_queue_req *mqrq) struct request *req = mmc_queue_req_to_req(mqrq); struct mmc_request *mrq = &mqrq->brq.mrq; - if (!req->crypt_keyslot) + if (!req->crypt_ctx) return; - mrq->crypto_enabled = true; - mrq->crypto_key_slot = blk_ksm_get_slot_idx(req->crypt_keyslot); - - /* - * For now we assume that all MMC drivers set max_dun_bytes_supported=4, - * which is the limit for CQHCI crypto. So all DUNs should be 32-bit. - */ - WARN_ON_ONCE(req->crypt_ctx->bc_dun[0] > U32_MAX); - - mrq->data_unit_num = req->crypt_ctx->bc_dun[0]; + mrq->crypto_ctx = req->crypt_ctx; + if (req->crypt_keyslot) + mrq->crypto_key_slot = blk_ksm_get_slot_idx(req->crypt_keyslot); } EXPORT_SYMBOL_GPL(mmc_crypto_prepare_req); diff --git a/drivers/mmc/host/cqhci-crypto.h b/drivers/mmc/host/cqhci-crypto.h index 60b58ee0e625..d7fb084f563b 100644 --- a/drivers/mmc/host/cqhci-crypto.h +++ b/drivers/mmc/host/cqhci-crypto.h @@ -22,12 +22,15 @@ int cqhci_crypto_init(struct cqhci_host *host); */ static inline u64 cqhci_crypto_prep_task_desc(struct mmc_request *mrq) { - if (!mrq->crypto_enabled) + if (!mrq->crypto_ctx) return 0; + /* We set max_dun_bytes_supported=4, so all DUNs should be 32-bit. */ + WARN_ON_ONCE(mrq->crypto_ctx->bc_dun[0] > U32_MAX); + return CQHCI_CRYPTO_ENABLE_BIT | CQHCI_CRYPTO_KEYSLOT(mrq->crypto_key_slot) | - mrq->data_unit_num; + mrq->crypto_ctx->bc_dun[0]; } #else /* CONFIG_MMC_CRYPTO */ diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h index ab19245e9945..71101d1ec825 100644 --- a/include/linux/mmc/core.h +++ b/include/linux/mmc/core.h @@ -164,9 +164,8 @@ struct mmc_request { int tag; #ifdef CONFIG_MMC_CRYPTO - bool crypto_enabled; + const struct bio_crypt_ctx *crypto_ctx; int crypto_key_slot; - u32 data_unit_num; #endif };