2020-07-06 23:04:13 +03:00
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2019 Google LLC
*/
2022-05-12 00:25:52 +03:00
# include <ufs/ufshcd.h>
2020-07-06 23:04:13 +03:00
# include "ufshcd-crypto.h"
/* Blk-crypto modes supported by UFS crypto */
static const struct ufs_crypto_alg_entry {
enum ufs_crypto_alg ufs_alg ;
enum ufs_crypto_key_size ufs_key_size ;
} ufs_crypto_algs [ BLK_ENCRYPTION_MODE_MAX ] = {
[ BLK_ENCRYPTION_MODE_AES_256_XTS ] = {
. ufs_alg = UFS_CRYPTO_ALG_AES_XTS ,
. ufs_key_size = UFS_CRYPTO_KEY_SIZE_256 ,
} ,
} ;
2020-07-10 10:20:11 +03:00
static int ufshcd_program_key ( struct ufs_hba * hba ,
const union ufs_crypto_cfg_entry * cfg , int slot )
2020-07-06 23:04:13 +03:00
{
int i ;
u32 slot_offset = hba - > crypto_cfg_register + slot * sizeof ( * cfg ) ;
2020-07-10 10:20:11 +03:00
int err = 0 ;
2020-07-06 23:04:13 +03:00
2023-05-29 23:26:40 +03:00
ufshcd_hold ( hba ) ;
2020-07-10 10:20:11 +03:00
if ( hba - > vops & & hba - > vops - > program_key ) {
err = hba - > vops - > program_key ( hba , cfg , slot ) ;
goto out ;
}
2020-07-06 23:04:13 +03:00
/* Ensure that CFGE is cleared before programming the key */
ufshcd_writel ( hba , 0 , slot_offset + 16 * sizeof ( cfg - > reg_val [ 0 ] ) ) ;
for ( i = 0 ; i < 16 ; i + + ) {
ufshcd_writel ( hba , le32_to_cpu ( cfg - > reg_val [ i ] ) ,
slot_offset + i * sizeof ( cfg - > reg_val [ 0 ] ) ) ;
}
/* Write dword 17 */
ufshcd_writel ( hba , le32_to_cpu ( cfg - > reg_val [ 17 ] ) ,
slot_offset + 17 * sizeof ( cfg - > reg_val [ 0 ] ) ) ;
/* Dword 16 must be written last */
ufshcd_writel ( hba , le32_to_cpu ( cfg - > reg_val [ 16 ] ) ,
slot_offset + 16 * sizeof ( cfg - > reg_val [ 0 ] ) ) ;
2020-07-10 10:20:11 +03:00
out :
2020-07-06 23:04:13 +03:00
ufshcd_release ( hba ) ;
2020-07-10 10:20:11 +03:00
return err ;
2020-07-06 23:04:13 +03:00
}
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 int ufshcd_crypto_keyslot_program ( struct blk_crypto_profile * profile ,
2020-07-06 23:04:13 +03:00
const struct blk_crypto_key * key ,
unsigned int slot )
{
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
struct ufs_hba * hba =
container_of ( profile , struct ufs_hba , crypto_profile ) ;
2020-07-06 23:04:13 +03:00
const union ufs_crypto_cap_entry * ccap_array = hba - > crypto_cap_array ;
const struct ufs_crypto_alg_entry * alg =
& ufs_crypto_algs [ key - > crypto_cfg . crypto_mode ] ;
u8 data_unit_mask = key - > crypto_cfg . data_unit_size / 512 ;
int i ;
int cap_idx = - 1 ;
2020-10-02 09:35:38 +03:00
union ufs_crypto_cfg_entry cfg = { } ;
2020-07-10 10:20:11 +03:00
int err ;
2020-07-06 23:04:13 +03:00
BUILD_BUG_ON ( UFS_CRYPTO_KEY_SIZE_INVALID ! = 0 ) ;
for ( i = 0 ; i < hba - > crypto_capabilities . num_crypto_cap ; i + + ) {
if ( ccap_array [ i ] . algorithm_id = = alg - > ufs_alg & &
ccap_array [ i ] . key_size = = alg - > ufs_key_size & &
( ccap_array [ i ] . sdus_mask & data_unit_mask ) ) {
cap_idx = i ;
break ;
}
}
if ( WARN_ON ( cap_idx < 0 ) )
return - EOPNOTSUPP ;
cfg . data_unit_size = data_unit_mask ;
cfg . crypto_cap_idx = cap_idx ;
cfg . config_enable = UFS_CRYPTO_CONFIGURATION_ENABLE ;
if ( ccap_array [ cap_idx ] . algorithm_id = = UFS_CRYPTO_ALG_AES_XTS ) {
/* In XTS mode, the blk_crypto_key's size is already doubled */
memcpy ( cfg . crypto_key , key - > raw , key - > size / 2 ) ;
memcpy ( cfg . crypto_key + UFS_CRYPTO_KEY_MAX_SIZE / 2 ,
key - > raw + key - > size / 2 , key - > size / 2 ) ;
} else {
memcpy ( cfg . crypto_key , key - > raw , key - > size ) ;
}
2020-07-10 10:20:11 +03:00
err = ufshcd_program_key ( hba , & cfg , slot ) ;
2020-07-06 23:04:13 +03:00
memzero_explicit ( & cfg , sizeof ( cfg ) ) ;
2020-07-10 10:20:11 +03:00
return err ;
2020-07-06 23:04:13 +03:00
}
2020-07-10 10:20:11 +03:00
static int ufshcd_clear_keyslot ( struct ufs_hba * hba , int slot )
2020-07-06 23:04:13 +03:00
{
/*
* Clear the crypto cfg on the device . Clearing CFGE
* might not be sufficient , so just clear the entire cfg .
*/
2020-10-02 09:35:38 +03:00
union ufs_crypto_cfg_entry cfg = { } ;
2020-07-06 23:04:13 +03:00
2020-07-10 10:20:11 +03:00
return ufshcd_program_key ( hba , & cfg , slot ) ;
2020-07-06 23:04:13 +03:00
}
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 int ufshcd_crypto_keyslot_evict ( struct blk_crypto_profile * profile ,
2020-07-06 23:04:13 +03:00
const struct blk_crypto_key * key ,
unsigned int slot )
{
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
struct ufs_hba * hba =
container_of ( profile , struct ufs_hba , crypto_profile ) ;
2020-07-06 23:04:13 +03:00
2020-07-10 10:20:11 +03:00
return ufshcd_clear_keyslot ( hba , slot ) ;
2020-07-06 23:04:13 +03:00
}
bool ufshcd_crypto_enable ( struct ufs_hba * hba )
{
if ( ! ( hba - > caps & UFSHCD_CAP_CRYPTO ) )
return false ;
/* Reset might clear all keys, so reprogram all the keys. */
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
blk_crypto_reprogram_all_keys ( & hba - > crypto_profile ) ;
2020-07-06 23:04:13 +03:00
return true ;
}
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 const struct blk_crypto_ll_ops ufshcd_crypto_ops = {
2020-07-06 23:04:13 +03:00
. keyslot_program = ufshcd_crypto_keyslot_program ,
. keyslot_evict = ufshcd_crypto_keyslot_evict ,
} ;
static enum blk_crypto_mode_num
ufshcd_find_blk_crypto_mode ( union ufs_crypto_cap_entry cap )
{
int i ;
for ( i = 0 ; i < ARRAY_SIZE ( ufs_crypto_algs ) ; i + + ) {
BUILD_BUG_ON ( UFS_CRYPTO_KEY_SIZE_INVALID ! = 0 ) ;
if ( ufs_crypto_algs [ i ] . ufs_alg = = cap . algorithm_id & &
ufs_crypto_algs [ i ] . ufs_key_size = = cap . key_size ) {
return i ;
}
}
return BLK_ENCRYPTION_MODE_INVALID ;
}
/**
* ufshcd_hba_init_crypto_capabilities - Read crypto capabilities , init crypto
* fields in hba
* @ hba : Per adapter instance
*
* Return : 0 if crypto was initialized or is not supported , else a - errno value .
*/
int ufshcd_hba_init_crypto_capabilities ( struct ufs_hba * hba )
{
int cap_idx ;
int err = 0 ;
enum blk_crypto_mode_num blk_mode_num ;
/*
* Don ' t use crypto if either the hardware doesn ' t advertise the
* standard crypto capability bit * or * if the vendor specific driver
* hasn ' t advertised that crypto is supported .
*/
if ( ! ( hba - > capabilities & MASK_CRYPTO_SUPPORT ) | |
! ( hba - > caps & UFSHCD_CAP_CRYPTO ) )
goto out ;
hba - > crypto_capabilities . reg_val =
cpu_to_le32 ( ufshcd_readl ( hba , REG_UFS_CCAP ) ) ;
hba - > crypto_cfg_register =
( u32 ) hba - > crypto_capabilities . config_array_ptr * 0x100 ;
hba - > crypto_cap_array =
devm_kcalloc ( hba - > dev , hba - > crypto_capabilities . num_crypto_cap ,
sizeof ( hba - > crypto_cap_array [ 0 ] ) , GFP_KERNEL ) ;
if ( ! hba - > crypto_cap_array ) {
err = - ENOMEM ;
goto out ;
}
/* The actual number of configurations supported is (CFGC+1) */
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
err = devm_blk_crypto_profile_init (
hba - > dev , & hba - > crypto_profile ,
hba - > crypto_capabilities . config_count + 1 ) ;
2020-07-06 23:04:13 +03:00
if ( err )
2021-01-12 12:21:28 +03:00
goto out ;
2020-07-06 23:04:13 +03:00
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
hba - > crypto_profile . ll_ops = ufshcd_crypto_ops ;
2020-07-06 23:04:13 +03:00
/* UFS only supports 8 bytes for any DUN */
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
hba - > crypto_profile . max_dun_bytes_supported = 8 ;
hba - > crypto_profile . dev = hba - > dev ;
2020-07-06 23:04:13 +03:00
/*
* Cache all the UFS crypto capabilities and advertise the supported
* crypto modes and data unit sizes to the block layer .
*/
for ( cap_idx = 0 ; cap_idx < hba - > crypto_capabilities . num_crypto_cap ;
cap_idx + + ) {
hba - > crypto_cap_array [ cap_idx ] . reg_val =
cpu_to_le32 ( ufshcd_readl ( hba ,
REG_UFS_CRYPTOCAP +
cap_idx * sizeof ( __le32 ) ) ) ;
blk_mode_num = ufshcd_find_blk_crypto_mode (
hba - > crypto_cap_array [ cap_idx ] ) ;
if ( blk_mode_num ! = BLK_ENCRYPTION_MODE_INVALID )
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
hba - > crypto_profile . modes_supported [ blk_mode_num ] | =
2020-07-06 23:04:13 +03:00
hba - > crypto_cap_array [ cap_idx ] . sdus_mask * 512 ;
}
return 0 ;
out :
/* Indicate that init failed by clearing UFSHCD_CAP_CRYPTO */
hba - > caps & = ~ UFSHCD_CAP_CRYPTO ;
return err ;
}
/**
* ufshcd_init_crypto - Initialize crypto hardware
* @ hba : Per adapter instance
*/
void ufshcd_init_crypto ( struct ufs_hba * hba )
{
int slot ;
if ( ! ( hba - > caps & UFSHCD_CAP_CRYPTO ) )
return ;
/* Clear all keyslots - the number of keyslots is (CFGC + 1) */
for ( slot = 0 ; slot < hba - > crypto_capabilities . config_count + 1 ; slot + + )
ufshcd_clear_keyslot ( hba , slot ) ;
}
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
{
if ( hba - > caps & UFSHCD_CAP_CRYPTO )
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
blk_crypto_register ( & hba - > crypto_profile , q ) ;
2020-07-06 23:04:13 +03:00
}