2020-07-06 20:04:13 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
|
/*
|
|
|
|
|
* Copyright 2019 Google LLC
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _UFSHCD_CRYPTO_H
|
|
|
|
|
#define _UFSHCD_CRYPTO_H
|
|
|
|
|
|
2022-04-19 15:58:08 -07:00
|
|
|
#include <scsi/scsi_cmnd.h>
|
2022-05-11 14:25:52 -07:00
|
|
|
#include <ufs/ufshcd.h>
|
2022-04-19 15:58:09 -07:00
|
|
|
#include "ufshcd-priv.h"
|
2022-05-11 14:25:52 -07:00
|
|
|
#include <ufs/ufshci.h>
|
2022-04-19 15:58:08 -07:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_SCSI_UFS_CRYPTO
|
2020-07-06 20:04:13 +00:00
|
|
|
|
2020-07-06 20:04:14 +00:00
|
|
|
static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
|
|
|
|
|
struct ufshcd_lrb *lrbp)
|
|
|
|
|
{
|
|
|
|
|
if (!rq || !rq->crypt_keyslot) {
|
|
|
|
|
lrbp->crypto_key_slot = -1;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots. It actually does several different things:
- Contains the crypto capabilities of the device.
- Provides functions to control the inline encryption hardware.
Originally these were just for programming/evicting keyslots;
however, new functionality (hardware-wrapped keys) will require new
functions here which are unrelated to keyslots. Moreover,
device-mapper devices already (ab)use "keyslot_evict" to pass key
eviction requests to their underlying devices even though
device-mapper devices don't have any keyslots themselves (so it
really should be "evict_key", not "keyslot_evict").
- Sometimes (but not always!) it manages keyslots. Originally it
always did, but device-mapper devices don't have keyslots
themselves, so they use a "passthrough keyslot manager" which
doesn't actually manage keyslots. This hack works, but the
terminology is unnatural. Also, some hardware doesn't have keyslots
and thus also uses a "passthrough keyslot manager" (support for such
hardware is yet to be upstreamed, but it will happen eventually).
Let's stop having keyslot managers which don't actually manage keyslots.
Instead, rename blk_keyslot_manager to blk_crypto_profile.
This is a fairly big change, since for consistency it also has to update
keyslot manager-related function names, variable names, and comments --
not just the actual struct name. However it's still a fairly
straightforward change, as it doesn't change any actual functionality.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-18 11:04:52 -07:00
|
|
|
lrbp->crypto_key_slot = blk_crypto_keyslot_index(rq->crypt_keyslot);
|
2020-07-06 20:04:14 +00:00
|
|
|
lrbp->data_unit_num = rq->crypt_ctx->bc_dun[0];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
2023-07-27 12:41:23 -07:00
|
|
|
ufshcd_prepare_req_desc_hdr_crypto(struct ufshcd_lrb *lrbp,
|
|
|
|
|
struct request_desc_header *h)
|
2020-07-06 20:04:14 +00:00
|
|
|
{
|
2023-07-27 12:41:23 -07:00
|
|
|
if (lrbp->crypto_key_slot < 0)
|
|
|
|
|
return;
|
|
|
|
|
h->enable_crypto = 1;
|
|
|
|
|
h->cci = lrbp->crypto_key_slot;
|
|
|
|
|
h->dunl = cpu_to_le32(lower_32_bits(lrbp->data_unit_num));
|
|
|
|
|
h->dunu = cpu_to_le32(upper_32_bits(lrbp->data_unit_num));
|
2020-07-06 20:04:14 +00:00
|
|
|
}
|
|
|
|
|
|
2024-07-08 16:53:28 -07:00
|
|
|
static inline int ufshcd_crypto_fill_prdt(struct ufs_hba *hba,
|
|
|
|
|
struct ufshcd_lrb *lrbp)
|
|
|
|
|
{
|
|
|
|
|
struct scsi_cmnd *cmd = lrbp->cmd;
|
|
|
|
|
const struct bio_crypt_ctx *crypt_ctx = scsi_cmd_to_rq(cmd)->crypt_ctx;
|
|
|
|
|
|
|
|
|
|
if (crypt_ctx && hba->vops && hba->vops->fill_crypto_prdt)
|
|
|
|
|
return hba->vops->fill_crypto_prdt(hba, crypt_ctx,
|
|
|
|
|
lrbp->ucd_prdt_ptr,
|
|
|
|
|
scsi_sg_count(cmd));
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-08 16:53:29 -07:00
|
|
|
static inline void ufshcd_crypto_clear_prdt(struct ufs_hba *hba,
|
|
|
|
|
struct ufshcd_lrb *lrbp)
|
|
|
|
|
{
|
|
|
|
|
if (!(hba->quirks & UFSHCD_QUIRK_KEYS_IN_PRDT))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!(scsi_cmd_to_rq(lrbp->cmd)->crypt_ctx))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* Zeroize the PRDT because it can contain cryptographic keys. */
|
|
|
|
|
memzero_explicit(lrbp->ucd_prdt_ptr,
|
|
|
|
|
ufshcd_sg_entry_size(hba) * scsi_sg_count(lrbp->cmd));
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-06 20:04:13 +00:00
|
|
|
bool ufshcd_crypto_enable(struct ufs_hba *hba);
|
|
|
|
|
|
|
|
|
|
int ufshcd_hba_init_crypto_capabilities(struct ufs_hba *hba);
|
|
|
|
|
|
|
|
|
|
void ufshcd_init_crypto(struct ufs_hba *hba);
|
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots. It actually does several different things:
- Contains the crypto capabilities of the device.
- Provides functions to control the inline encryption hardware.
Originally these were just for programming/evicting keyslots;
however, new functionality (hardware-wrapped keys) will require new
functions here which are unrelated to keyslots. Moreover,
device-mapper devices already (ab)use "keyslot_evict" to pass key
eviction requests to their underlying devices even though
device-mapper devices don't have any keyslots themselves (so it
really should be "evict_key", not "keyslot_evict").
- Sometimes (but not always!) it manages keyslots. Originally it
always did, but device-mapper devices don't have keyslots
themselves, so they use a "passthrough keyslot manager" which
doesn't actually manage keyslots. This hack works, but the
terminology is unnatural. Also, some hardware doesn't have keyslots
and thus also uses a "passthrough keyslot manager" (support for such
hardware is yet to be upstreamed, but it will happen eventually).
Let's stop having keyslot managers which don't actually manage keyslots.
Instead, rename blk_keyslot_manager to blk_crypto_profile.
This is a fairly big change, since for consistency it also has to update
keyslot manager-related function names, variable names, and comments --
not just the actual struct name. However it's still a fairly
straightforward change, as it doesn't change any actual functionality.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-18 11:04:52 -07:00
|
|
|
void ufshcd_crypto_register(struct ufs_hba *hba, struct request_queue *q);
|
2020-07-06 20:04:13 +00:00
|
|
|
|
|
|
|
|
#else /* CONFIG_SCSI_UFS_CRYPTO */
|
|
|
|
|
|
2020-07-06 20:04:14 +00:00
|
|
|
static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
|
|
|
|
|
struct ufshcd_lrb *lrbp) { }
|
|
|
|
|
|
|
|
|
|
static inline void
|
2023-07-27 12:41:23 -07:00
|
|
|
ufshcd_prepare_req_desc_hdr_crypto(struct ufshcd_lrb *lrbp,
|
|
|
|
|
struct request_desc_header *h) { }
|
2020-07-06 20:04:14 +00:00
|
|
|
|
2024-07-08 16:53:28 -07:00
|
|
|
static inline int ufshcd_crypto_fill_prdt(struct ufs_hba *hba,
|
|
|
|
|
struct ufshcd_lrb *lrbp)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-08 16:53:29 -07:00
|
|
|
static inline void ufshcd_crypto_clear_prdt(struct ufs_hba *hba,
|
|
|
|
|
struct ufshcd_lrb *lrbp) { }
|
|
|
|
|
|
2020-07-06 20:04:13 +00:00
|
|
|
static inline bool ufshcd_crypto_enable(struct ufs_hba *hba)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int ufshcd_hba_init_crypto_capabilities(struct ufs_hba *hba)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void ufshcd_init_crypto(struct ufs_hba *hba) { }
|
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots. It actually does several different things:
- Contains the crypto capabilities of the device.
- Provides functions to control the inline encryption hardware.
Originally these were just for programming/evicting keyslots;
however, new functionality (hardware-wrapped keys) will require new
functions here which are unrelated to keyslots. Moreover,
device-mapper devices already (ab)use "keyslot_evict" to pass key
eviction requests to their underlying devices even though
device-mapper devices don't have any keyslots themselves (so it
really should be "evict_key", not "keyslot_evict").
- Sometimes (but not always!) it manages keyslots. Originally it
always did, but device-mapper devices don't have keyslots
themselves, so they use a "passthrough keyslot manager" which
doesn't actually manage keyslots. This hack works, but the
terminology is unnatural. Also, some hardware doesn't have keyslots
and thus also uses a "passthrough keyslot manager" (support for such
hardware is yet to be upstreamed, but it will happen eventually).
Let's stop having keyslot managers which don't actually manage keyslots.
Instead, rename blk_keyslot_manager to blk_crypto_profile.
This is a fairly big change, since for consistency it also has to update
keyslot manager-related function names, variable names, and comments --
not just the actual struct name. However it's still a fairly
straightforward change, as it doesn't change any actual functionality.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-18 11:04:52 -07:00
|
|
|
static inline void ufshcd_crypto_register(struct ufs_hba *hba,
|
|
|
|
|
struct request_queue *q) { }
|
2020-07-06 20:04:13 +00:00
|
|
|
|
|
|
|
|
#endif /* CONFIG_SCSI_UFS_CRYPTO */
|
|
|
|
|
|
|
|
|
|
#endif /* _UFSHCD_CRYPTO_H */
|