android_kernel_motorola_sm6225/block/keyslot-manager.c

664 lines
19 KiB
C
Raw Normal View History

BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2019 Google LLC
*/
/**
* DOC: The Keyslot Manager
*
* Many devices with inline encryption support have a limited number of "slots"
* into which encryption contexts may be programmed, and requests can be tagged
* with a slot number to specify the key to use for en/decryption.
*
* As the number of slots are limited, and programming keys is expensive on
* many inline encryption hardware, we don't want to program the same key into
* multiple slots - if multiple requests are using the same key, we want to
* program just one slot with that key and use that slot for all requests.
*
* The keyslot manager manages these keyslots appropriately, and also acts as
* an abstraction between the inline encryption hardware and the upper layers.
*
* Lower layer devices will set up a keyslot manager in their request queue
* and tell it how to perform device specific operations like programming/
* evicting keys from keyslots.
*
* Upper layers will call keyslot_manager_get_slot_for_key() to program a
* key into some slot in the inline encryption hardware.
*/
#include <crypto/algapi.h>
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
#include <linux/keyslot-manager.h>
#include <linux/atomic.h>
#include <linux/mutex.h>
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
#include <linux/pm_runtime.h>
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
#include <linux/wait.h>
#include <linux/blkdev.h>
struct keyslot {
atomic_t slot_refs;
struct list_head idle_slot_node;
struct hlist_node hash_node;
struct blk_crypto_key key;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
};
struct keyslot_manager {
unsigned int num_slots;
struct keyslot_mgmt_ll_ops ksm_ll_ops;
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
unsigned int features;
unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX];
unsigned int max_dun_bytes_supported;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
void *ll_priv_data;
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
#ifdef CONFIG_PM
/* Device for runtime power management (NULL if none) */
struct device *dev;
#endif
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
/* Protects programming and evicting keys from the device */
struct rw_semaphore lock;
/* List of idle slots, with least recently used slot at front */
wait_queue_head_t idle_slots_wait_queue;
struct list_head idle_slots;
spinlock_t idle_slots_lock;
/*
* Hash table which maps key hashes to keyslots, so that we can find a
* key's keyslot in O(1) time rather than O(num_slots). Protected by
* 'lock'. A cryptographic hash function is used so that timing attacks
* can't leak information about the raw keys.
*/
struct hlist_head *slot_hashtable;
unsigned int slot_hashtable_size;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
/* Per-keyslot data */
struct keyslot slots[];
};
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
static inline bool keyslot_manager_is_passthrough(struct keyslot_manager *ksm)
{
return ksm->num_slots == 0;
}
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
#ifdef CONFIG_PM
static inline void keyslot_manager_set_dev(struct keyslot_manager *ksm,
struct device *dev)
{
ksm->dev = dev;
}
/* If there's an underlying device and it's suspended, resume it. */
static inline void keyslot_manager_pm_get(struct keyslot_manager *ksm)
{
if (ksm->dev)
pm_runtime_get_sync(ksm->dev);
}
static inline void keyslot_manager_pm_put(struct keyslot_manager *ksm)
{
if (ksm->dev)
pm_runtime_put_sync(ksm->dev);
}
#else /* CONFIG_PM */
static inline void keyslot_manager_set_dev(struct keyslot_manager *ksm,
struct device *dev)
{
}
static inline void keyslot_manager_pm_get(struct keyslot_manager *ksm)
{
}
static inline void keyslot_manager_pm_put(struct keyslot_manager *ksm)
{
}
#endif /* !CONFIG_PM */
static inline void keyslot_manager_hw_enter(struct keyslot_manager *ksm)
{
/*
* Calling into the driver requires ksm->lock held and the device
* resumed. But we must resume the device first, since that can acquire
* and release ksm->lock via keyslot_manager_reprogram_all_keys().
*/
keyslot_manager_pm_get(ksm);
down_write(&ksm->lock);
}
static inline void keyslot_manager_hw_exit(struct keyslot_manager *ksm)
{
up_write(&ksm->lock);
keyslot_manager_pm_put(ksm);
}
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
/**
* keyslot_manager_create() - Create a keyslot manager
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
* @dev: Device for runtime power management (NULL if none)
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
* @num_slots: The number of key slots to manage.
* @ksm_ll_ops: The struct keyslot_mgmt_ll_ops for the device that this keyslot
* manager will use to perform operations like programming and
* evicting keys.
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
* @features: The supported features as a bitmask of BLK_CRYPTO_FEATURE_* flags.
* Most drivers should set BLK_CRYPTO_FEATURE_STANDARD_KEYS here.
* @crypto_mode_supported: Array of size BLK_ENCRYPTION_MODE_MAX of
* bitmasks that represents whether a crypto mode
* and data unit size are supported. The i'th bit
* of crypto_mode_supported[crypto_mode] is set iff
* a data unit size of (1 << i) is supported. We
* only support data unit sizes that are powers of
* 2.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
* @ll_priv_data: Private data passed as is to the functions in ksm_ll_ops.
*
* Allocate memory for and initialize a keyslot manager. Called by e.g.
* storage drivers to set up a keyslot manager in their request_queue.
*
* Context: May sleep
* Return: Pointer to constructed keyslot manager or NULL on error.
*/
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
struct keyslot_manager *keyslot_manager_create(
struct device *dev,
unsigned int num_slots,
const struct keyslot_mgmt_ll_ops *ksm_ll_ops,
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
unsigned int features,
const unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX],
void *ll_priv_data)
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
{
struct keyslot_manager *ksm;
unsigned int slot;
unsigned int i;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (num_slots == 0)
return NULL;
/* Check that all ops are specified */
if (ksm_ll_ops->keyslot_program == NULL ||
ksm_ll_ops->keyslot_evict == NULL)
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
return NULL;
ksm = kvzalloc(struct_size(ksm, slots, num_slots), GFP_KERNEL);
if (!ksm)
return NULL;
ksm->num_slots = num_slots;
ksm->ksm_ll_ops = *ksm_ll_ops;
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
ksm->features = features;
memcpy(ksm->crypto_mode_supported, crypto_mode_supported,
sizeof(ksm->crypto_mode_supported));
ksm->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
ksm->ll_priv_data = ll_priv_data;
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_set_dev(ksm, dev);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
init_rwsem(&ksm->lock);
init_waitqueue_head(&ksm->idle_slots_wait_queue);
INIT_LIST_HEAD(&ksm->idle_slots);
for (slot = 0; slot < num_slots; slot++) {
list_add_tail(&ksm->slots[slot].idle_slot_node,
&ksm->idle_slots);
}
spin_lock_init(&ksm->idle_slots_lock);
ksm->slot_hashtable_size = roundup_pow_of_two(num_slots);
ksm->slot_hashtable = kvmalloc_array(ksm->slot_hashtable_size,
sizeof(ksm->slot_hashtable[0]),
GFP_KERNEL);
if (!ksm->slot_hashtable)
goto err_free_ksm;
for (i = 0; i < ksm->slot_hashtable_size; i++)
INIT_HLIST_HEAD(&ksm->slot_hashtable[i]);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
return ksm;
err_free_ksm:
keyslot_manager_destroy(ksm);
return NULL;
}
EXPORT_SYMBOL_GPL(keyslot_manager_create);
void keyslot_manager_set_max_dun_bytes(struct keyslot_manager *ksm,
unsigned int max_dun_bytes)
{
ksm->max_dun_bytes_supported = max_dun_bytes;
}
EXPORT_SYMBOL_GPL(keyslot_manager_set_max_dun_bytes);
static inline struct hlist_head *
hash_bucket_for_key(struct keyslot_manager *ksm,
const struct blk_crypto_key *key)
{
return &ksm->slot_hashtable[blk_crypto_key_hash(key) &
(ksm->slot_hashtable_size - 1)];
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
}
static void remove_slot_from_lru_list(struct keyslot_manager *ksm, int slot)
{
unsigned long flags;
spin_lock_irqsave(&ksm->idle_slots_lock, flags);
list_del(&ksm->slots[slot].idle_slot_node);
spin_unlock_irqrestore(&ksm->idle_slots_lock, flags);
}
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
static int find_keyslot(struct keyslot_manager *ksm,
const struct blk_crypto_key *key)
{
const struct hlist_head *head = hash_bucket_for_key(ksm, key);
const struct keyslot *slotp;
hlist_for_each_entry(slotp, head, hash_node) {
if (slotp->key.hash == key->hash &&
slotp->key.crypto_mode == key->crypto_mode &&
slotp->key.size == key->size &&
slotp->key.data_unit_size == key->data_unit_size &&
!crypto_memneq(slotp->key.raw, key->raw, key->size))
return slotp - ksm->slots;
}
return -ENOKEY;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
}
static int find_and_grab_keyslot(struct keyslot_manager *ksm,
const struct blk_crypto_key *key)
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
{
int slot;
slot = find_keyslot(ksm, key);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (slot < 0)
return slot;
if (atomic_inc_return(&ksm->slots[slot].slot_refs) == 1) {
/* Took first reference to this slot; remove it from LRU list */
remove_slot_from_lru_list(ksm, slot);
}
return slot;
}
/**
* keyslot_manager_get_slot_for_key() - Program a key into a keyslot.
* @ksm: The keyslot manager to program the key into.
* @key: Pointer to the key object to program, including the raw key, crypto
* mode, and data unit size.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*
* Get a keyslot that's been programmed with the specified key. If one already
* exists, return it with incremented refcount. Otherwise, wait for a keyslot
* to become idle and program it.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*
* Context: Process context. Takes and releases ksm->lock.
* Return: The keyslot on success, else a -errno value.
*/
int keyslot_manager_get_slot_for_key(struct keyslot_manager *ksm,
const struct blk_crypto_key *key)
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
{
int slot;
int err;
struct keyslot *idle_slot;
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
if (keyslot_manager_is_passthrough(ksm))
return 0;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
down_read(&ksm->lock);
slot = find_and_grab_keyslot(ksm, key);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
up_read(&ksm->lock);
if (slot != -ENOKEY)
return slot;
for (;;) {
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_enter(ksm);
slot = find_and_grab_keyslot(ksm, key);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (slot != -ENOKEY) {
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_exit(ksm);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
return slot;
}
/*
* If we're here, that means there wasn't a slot that was
* already programmed with the key. So try to program it.
*/
if (!list_empty(&ksm->idle_slots))
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
break;
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_exit(ksm);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
wait_event(ksm->idle_slots_wait_queue,
!list_empty(&ksm->idle_slots));
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
}
idle_slot = list_first_entry(&ksm->idle_slots, struct keyslot,
idle_slot_node);
slot = idle_slot - ksm->slots;
err = ksm->ksm_ll_ops.keyslot_program(ksm, key, slot);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (err) {
wake_up(&ksm->idle_slots_wait_queue);
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_exit(ksm);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
return err;
}
/* Move this slot to the hash list for the new key. */
if (idle_slot->key.crypto_mode != BLK_ENCRYPTION_MODE_INVALID)
hlist_del(&idle_slot->hash_node);
hlist_add_head(&idle_slot->hash_node, hash_bucket_for_key(ksm, key));
atomic_set(&idle_slot->slot_refs, 1);
idle_slot->key = *key;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
remove_slot_from_lru_list(ksm, slot);
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_exit(ksm);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
return slot;
}
/**
* keyslot_manager_get_slot() - Increment the refcount on the specified slot.
* @ksm: The keyslot manager that we want to modify.
* @slot: The slot to increment the refcount of.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*
* This function assumes that there is already an active reference to that slot
* and simply increments the refcount. This is useful when cloning a bio that
* already has a reference to a keyslot, and we want the cloned bio to also have
* its own reference.
*
* Context: Any context.
*/
void keyslot_manager_get_slot(struct keyslot_manager *ksm, unsigned int slot)
{
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
if (keyslot_manager_is_passthrough(ksm))
return;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (WARN_ON(slot >= ksm->num_slots))
return;
WARN_ON(atomic_inc_return(&ksm->slots[slot].slot_refs) < 2);
}
/**
* keyslot_manager_put_slot() - Release a reference to a slot
* @ksm: The keyslot manager to release the reference from.
* @slot: The slot to release the reference from.
*
* Context: Any context.
*/
void keyslot_manager_put_slot(struct keyslot_manager *ksm, unsigned int slot)
{
unsigned long flags;
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
if (keyslot_manager_is_passthrough(ksm))
return;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (WARN_ON(slot >= ksm->num_slots))
return;
if (atomic_dec_and_lock_irqsave(&ksm->slots[slot].slot_refs,
&ksm->idle_slots_lock, flags)) {
list_add_tail(&ksm->slots[slot].idle_slot_node,
&ksm->idle_slots);
spin_unlock_irqrestore(&ksm->idle_slots_lock, flags);
wake_up(&ksm->idle_slots_wait_queue);
}
}
/**
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
* keyslot_manager_crypto_mode_supported() - Find out if a crypto_mode /
* data unit size / is_hw_wrapped_key
* combination is supported by a ksm.
* @ksm: The keyslot manager to check
* @crypto_mode: The crypto mode to check for.
* @dun_bytes: The number of bytes that will be used to specify the DUN
* @data_unit_size: The data_unit_size for the mode.
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
* @is_hw_wrapped_key: Whether a hardware-wrapped key will be used.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*
* Calls and returns the result of the crypto_mode_supported function specified
* by the ksm.
*
* Context: Process context.
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
* Return: Whether or not this ksm supports the specified crypto settings.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*/
bool keyslot_manager_crypto_mode_supported(struct keyslot_manager *ksm,
enum blk_crypto_mode_num crypto_mode,
unsigned int dun_bytes,
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
unsigned int data_unit_size,
bool is_hw_wrapped_key)
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
{
if (!ksm)
return false;
if (WARN_ON(crypto_mode >= BLK_ENCRYPTION_MODE_MAX))
return false;
if (WARN_ON(!is_power_of_2(data_unit_size)))
return false;
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
if (is_hw_wrapped_key) {
if (!(ksm->features & BLK_CRYPTO_FEATURE_WRAPPED_KEYS))
return false;
} else {
if (!(ksm->features & BLK_CRYPTO_FEATURE_STANDARD_KEYS))
return false;
}
if (!(ksm->crypto_mode_supported[crypto_mode] & data_unit_size))
return false;
return ksm->max_dun_bytes_supported >= dun_bytes;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
}
/**
* keyslot_manager_evict_key() - Evict a key from the lower layer device.
* @ksm: The keyslot manager to evict from
* @key: The key to evict
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*
* Find the keyslot that the specified key was programmed into, and evict that
* slot from the lower layer device if that slot is not currently in use.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*
* Context: Process context. Takes and releases ksm->lock.
* Return: 0 on success, -EBUSY if the key is still in use, or another
* -errno value on other error.
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
*/
int keyslot_manager_evict_key(struct keyslot_manager *ksm,
const struct blk_crypto_key *key)
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
{
int slot;
int err;
struct keyslot *slotp;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
if (keyslot_manager_is_passthrough(ksm)) {
if (ksm->ksm_ll_ops.keyslot_evict) {
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_enter(ksm);
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
err = ksm->ksm_ll_ops.keyslot_evict(ksm, key, -1);
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_exit(ksm);
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
return err;
}
return 0;
}
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_enter(ksm);
slot = find_keyslot(ksm, key);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (slot < 0) {
err = slot;
goto out_unlock;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
}
slotp = &ksm->slots[slot];
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
if (atomic_read(&slotp->slot_refs) != 0) {
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
err = -EBUSY;
goto out_unlock;
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
}
err = ksm->ksm_ll_ops.keyslot_evict(ksm, key, slot);
if (err)
goto out_unlock;
hlist_del(&slotp->hash_node);
memzero_explicit(&slotp->key, sizeof(slotp->key));
err = 0;
out_unlock:
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_exit(ksm);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
return err;
}
/**
* keyslot_manager_reprogram_all_keys() - Re-program all keyslots.
* @ksm: The keyslot manager
*
* Re-program all keyslots that are supposed to have a key programmed. This is
* intended only for use by drivers for hardware that loses its keys on reset.
*
* Context: Process context. Takes and releases ksm->lock.
*/
void keyslot_manager_reprogram_all_keys(struct keyslot_manager *ksm)
{
unsigned int slot;
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
if (WARN_ON(keyslot_manager_is_passthrough(ksm)))
return;
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
/* This is for device initialization, so don't resume the device */
down_write(&ksm->lock);
for (slot = 0; slot < ksm->num_slots; slot++) {
const struct keyslot *slotp = &ksm->slots[slot];
int err;
if (slotp->key.crypto_mode == BLK_ENCRYPTION_MODE_INVALID)
continue;
err = ksm->ksm_ll_ops.keyslot_program(ksm, &slotp->key, slot);
WARN_ON(err);
}
up_write(&ksm->lock);
}
EXPORT_SYMBOL_GPL(keyslot_manager_reprogram_all_keys);
/**
* keyslot_manager_private() - return the private data stored with ksm
* @ksm: The keyslot manager
*
* Returns the private data passed to the ksm when it was created.
*/
void *keyslot_manager_private(struct keyslot_manager *ksm)
{
return ksm->ll_priv_data;
}
EXPORT_SYMBOL_GPL(keyslot_manager_private);
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
void keyslot_manager_destroy(struct keyslot_manager *ksm)
{
if (ksm) {
kvfree(ksm->slot_hashtable);
memzero_explicit(ksm, struct_size(ksm, slots, ksm->num_slots));
kvfree(ksm);
}
BACKPORT: FROMLIST: block: Keyslot Manager for Inline Encryption Inline Encryption hardware allows software to specify an encryption context (an encryption key, crypto algorithm, data unit num, data unit size, etc.) along with a data transfer request to a storage device, and the inline encryption hardware will use that context to en/decrypt the data. The inline encryption hardware is part of the storage device, and it conceptually sits on the data path between system memory and the storage device. Inline Encryption hardware implementations often function around the concept of "keyslots". These implementations often have a limited number of "keyslots", each of which can hold an encryption context (we say that an encryption context can be "programmed" into a keyslot). Requests made to the storage device may have a keyslot associated with them, and the inline encryption hardware will en/decrypt the data in the requests using the encryption context programmed into that associated keyslot. As keyslots are limited, and programming keys may be expensive in many implementations, and multiple requests may use exactly the same encryption contexts, we introduce a Keyslot Manager to efficiently manage keyslots. The keyslot manager also functions as the interface that upper layers will use to program keys into inline encryption hardware. For more information on the Keyslot Manager, refer to documentation found in block/keyslot-manager.c and linux/keyslot-manager.h. Bug: 137270441 Test: tested as series; see I26aac0ac7845a9064f28bb1421eb2522828a6dec Change-Id: I9a2dc72d61d5a3c64af379a97dd46155b41193eb Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-24 23:44:23 +02:00
}
EXPORT_SYMBOL_GPL(keyslot_manager_destroy);
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
/**
* keyslot_manager_create_passthrough() - Create a passthrough keyslot manager
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
* @dev: Device for runtime power management (NULL if none)
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
* @ksm_ll_ops: The struct keyslot_mgmt_ll_ops
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
* @features: Bitmask of BLK_CRYPTO_FEATURE_* flags
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
* @crypto_mode_supported: Bitmasks for supported encryption modes
* @ll_priv_data: Private data passed as is to the functions in ksm_ll_ops.
*
* Allocate memory for and initialize a passthrough keyslot manager.
* Called by e.g. storage drivers to set up a keyslot manager in their
* request_queue, when the storage driver wants to manage its keys by itself.
* This is useful for inline encryption hardware that don't have a small fixed
* number of keyslots, and for layered devices.
*
* See keyslot_manager_create() for more details about the parameters.
*
* Context: This function may sleep
* Return: Pointer to constructed keyslot manager or NULL on error.
*/
struct keyslot_manager *keyslot_manager_create_passthrough(
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
struct device *dev,
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
const struct keyslot_mgmt_ll_ops *ksm_ll_ops,
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
unsigned int features,
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
const unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX],
void *ll_priv_data)
{
struct keyslot_manager *ksm;
ksm = kzalloc(sizeof(*ksm), GFP_KERNEL);
if (!ksm)
return NULL;
ksm->ksm_ll_ops = *ksm_ll_ops;
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
ksm->features = features;
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
memcpy(ksm->crypto_mode_supported, crypto_mode_supported,
sizeof(ksm->crypto_mode_supported));
ksm->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE;
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
ksm->ll_priv_data = ll_priv_data;
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_set_dev(ksm, dev);
ANDROID: block: Introduce passthrough keyslot manager The regular keyslot manager is designed for devices that have a small number of keyslots that need to be programmed with keys ahead of time, and bios that are sent to the device need to be tagged with a keyslot index. Some inline encryption hardware may not have any limitations on the number of keyslot, and may instead allow each bio to be tagged with a raw key, data unit number, etc. rather than a pre-programmed keyslot's index. These devices don't need any sort of keyslot management, and it's better for these devices not to have to allocate a regular keyslot manager with some fixed number of keyslots. These devices can instead set up a passthrough keyslot manager in their request queue, which require less resources than regular keyslot managers, as they simply do no-ops when trying to program keys into slots. Separately, the device mapper may map over devices that have inline encryption hardware, and it wants to pass the key along to the underlying hardware. While the DM layer can expose inline encryption capabilities by setting up a regular keyslot manager with some fixed number of keyslots in the dm device's request queue, this only wastes memory since the keys programmed into the dm device's request queue will never be used. Instead, it's better to set up a passthrough keyslot manager for dm devices. Bug: 137270441 Bug: 147814592 Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234 Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-21 18:27:43 +01:00
init_rwsem(&ksm->lock);
return ksm;
}
EXPORT_SYMBOL_GPL(keyslot_manager_create_passthrough);
/**
* keyslot_manager_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 keyslot_manager_intersect_modes(struct keyslot_manager *parent,
const struct keyslot_manager *child)
{
if (child) {
unsigned int i;
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
parent->features &= child->features;
parent->max_dun_bytes_supported =
min(parent->max_dun_bytes_supported,
child->max_dun_bytes_supported);
for (i = 0; i < ARRAY_SIZE(child->crypto_mode_supported); i++) {
parent->crypto_mode_supported[i] &=
child->crypto_mode_supported[i];
}
} else {
ANDROID: block: require drivers to declare supported crypto key type(s) We need a way to tell which type of keys the inline crypto hardware supports (standard, wrapped, or both), so that fallbacks can be used when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto). We can't simply assume that keyslot_mgmt_ll_ops::derive_raw_secret == NULL means only standard keys are supported and that keyslot_mgmt_ll_ops::derive_raw_secret != NULL means that only wrapped keys are supported, because device-mapper devices always implement this method. Also, hardware might support both types of keys. Therefore, add a field keyslot_manager::features which contains a bitmask of flags which indicate the supported types of keys. Drivers will need to fill this in. This patch makes the UFS standard crypto code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead. Then, make keyslot_manager_crypto_mode_supported() take the key type into account. Bug: 137270441 Bug: 151100202 Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the inline crypto patches backported, and also on Cuttlefish. Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005 Signed-off-by: Eric Biggers <ebiggers@google.com> Git-commit: 8f078b1b3aae280f240a75d27457e5e76dd0a92a Git-repo: https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19 [neersoni@codeaurora.org: key capability parameter added for ufs and emmc] Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-04-03 21:06:11 +02:00
parent->features = 0;
parent->max_dun_bytes_supported = 0;
memset(parent->crypto_mode_supported, 0,
sizeof(parent->crypto_mode_supported));
}
}
EXPORT_SYMBOL_GPL(keyslot_manager_intersect_modes);
/**
* keyslot_manager_derive_raw_secret() - Derive software secret from wrapped key
* @ksm: The keyslot manager
* @wrapped_key: The wrapped key
* @wrapped_key_size: Size of the wrapped key in bytes
* @secret: (output) the software secret
* @secret_size: (output) the number of secret bytes to derive
*
* Given a hardware-wrapped key, ask the hardware to derive a secret which
* software can use for cryptographic tasks other than inline encryption. The
* derived secret is guaranteed to be cryptographically isolated from the key
* with which any inline encryption with this wrapped key would actually be
* done. I.e., both will be derived from the unwrapped key.
*
* Return: 0 on success, -EOPNOTSUPP if hardware-wrapped keys are unsupported,
* or another -errno code.
*/
int keyslot_manager_derive_raw_secret(struct keyslot_manager *ksm,
const u8 *wrapped_key,
unsigned int wrapped_key_size,
u8 *secret, unsigned int secret_size)
{
int err;
if (ksm->ksm_ll_ops.derive_raw_secret) {
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_enter(ksm);
err = ksm->ksm_ll_ops.derive_raw_secret(ksm, wrapped_key,
wrapped_key_size,
secret, secret_size);
ANDROID: ufs, block: fix crypto power management and move into block layer The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock because it waits for the UFS controller to be resumed, but it can itself be reached while resuming the UFS controller via: - ufshcd_runtime_resume() - ufshcd_resume() - ufshcd_reset_and_restore() - ufshcd_host_reset_and_restore() - ufshcd_hba_enable() - ufshcd_hba_execute_hce() - ufshcd_hba_start() - ufshcd_crypto_enable() - keyslot_manager_reprogram_all_keys() - ufshcd_crypto_keyslot_program() - ufshcd_program_key() But pm_runtime_get_sync() *is* needed when evicting a key. Also, on pre-4.20 kernels it's needed when programming a keyslot for a bio since the block layer used to resume the device in a different place. Thus, it's hard for drivers to know what to do in .keyslot_program() and .keyslot_evict(). In old kernels it may even be impossible unless we were to pass more information down from the keyslot_manager. There's also another possible deadlock: keyslot programming and eviction take ksm->lock for write and then resume the device, which may result in ksm->lock being taken again via the above call stack. To fix this, we should resume the device before taking ksm->lock. Fix these problems by moving to a better design where the block layer (namely, the keyslot manager) handles runtime power management instead of drivers. This is analogous to the block layer's existing runtime power management support (blk-pm), which handles resuming devices when bios are submitted to them so that drivers don't need to handle it. Test: Tested on coral with: echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl sleep 30 touch /data && sync # hangs before this fix Also verified via kvm-xfstests that blk-crypto-fallback continues to work both with and without CONFIG_PM=y. Bug: 137270441 Bug: 149368295 Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-02-14 00:08:24 +01:00
keyslot_manager_hw_exit(ksm);
} else {
err = -EOPNOTSUPP;
}
return err;
}
EXPORT_SYMBOL_GPL(keyslot_manager_derive_raw_secret);