2020-07-06 23:04:13 +03:00
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright 2019 Google LLC
*/
# ifndef _UFSHCD_CRYPTO_H
# define _UFSHCD_CRYPTO_H
2022-04-20 01:58:08 +03:00
# include <scsi/scsi_cmnd.h>
2022-05-12 00:25:52 +03:00
# include <ufs/ufshcd.h>
2022-04-20 01:58:09 +03:00
# include "ufshcd-priv.h"
2022-05-12 00:25:52 +03:00
# include <ufs/ufshci.h>
2022-04-20 01:58:08 +03:00
# ifdef CONFIG_SCSI_UFS_CRYPTO
2020-07-06 23:04:13 +03:00
2020-07-06 23:04:14 +03: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 21:04:52 +03:00
lrbp - > crypto_key_slot = blk_crypto_keyslot_index ( rq - > crypt_keyslot ) ;
2020-07-06 23:04:14 +03:00
lrbp - > data_unit_num = rq - > crypt_ctx - > bc_dun [ 0 ] ;
}
static inline void
ufshcd_prepare_req_desc_hdr_crypto ( struct ufshcd_lrb * lrbp , u32 * dword_0 ,
u32 * dword_1 , u32 * dword_3 )
{
if ( lrbp - > crypto_key_slot > = 0 ) {
* dword_0 | = UTP_REQ_DESC_CRYPTO_ENABLE_CMD ;
* dword_0 | = lrbp - > crypto_key_slot ;
* dword_1 = lower_32_bits ( lrbp - > data_unit_num ) ;
* dword_3 = upper_32_bits ( lrbp - > data_unit_num ) ;
}
}
2020-07-06 23:04:13 +03: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 21:04:52 +03:00
void ufshcd_crypto_register ( struct ufs_hba * hba , struct request_queue * q ) ;
2020-07-06 23:04:13 +03:00
# else /* CONFIG_SCSI_UFS_CRYPTO */
2020-07-06 23:04:14 +03:00
static inline void ufshcd_prepare_lrbp_crypto ( struct request * rq ,
struct ufshcd_lrb * lrbp ) { }
static inline void
ufshcd_prepare_req_desc_hdr_crypto ( struct ufshcd_lrb * lrbp , u32 * dword_0 ,
u32 * dword_1 , u32 * dword_3 ) { }
2020-07-06 23:04:13 +03: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 21:04:52 +03:00
static inline void ufshcd_crypto_register ( struct ufs_hba * hba ,
struct request_queue * q ) { }
2020-07-06 23:04:13 +03:00
# endif /* CONFIG_SCSI_UFS_CRYPTO */
# endif /* _UFSHCD_CRYPTO_H */
