android_kernel_xiaomi_sm8450/block/keyslot-manager.c

630 lines
18 KiB
C
Raw Permalink Normal View History

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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09: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.
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* As the number of slots is limited, and programming keys is expensive on
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
* 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.
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* Upper layers will call blk_ksm_get_slot_for_key() to program a
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
* key into some slot in the inline encryption hardware.
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
#define pr_fmt(fmt) "blk-crypto: " fmt
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
#include <linux/keyslot-manager.h>
#include <linux/device.h>
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
#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 08:08:24 +09:00
#include <linux/pm_runtime.h>
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
#include <linux/wait.h>
#include <linux/blkdev.h>
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
struct blk_ksm_keyslot {
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
atomic_t slot_refs;
struct list_head idle_slot_node;
struct hlist_node hash_node;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
const struct blk_crypto_key *key;
struct blk_keyslot_manager *ksm;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
};
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
static inline void blk_ksm_hw_enter(struct blk_keyslot_manager *ksm)
{
/*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* 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 blk_ksm_reprogram_all_keys().
*/
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 08:08:24 +09:00
if (ksm->dev)
pm_runtime_get_sync(ksm->dev);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
down_write(&ksm->lock);
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 08:08:24 +09:00
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
static inline void blk_ksm_hw_exit(struct blk_keyslot_manager *ksm)
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 08:08:24 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
up_write(&ksm->lock);
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 08:08:24 +09:00
if (ksm->dev)
pm_runtime_put_sync(ksm->dev);
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
static inline bool blk_ksm_is_passthrough(struct blk_keyslot_manager *ksm)
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 08:08:24 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
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 08:08:24 +09:00
}
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_init() - Initialize a keyslot manager
* @ksm: The keyslot_manager to initialize.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
* @num_slots: The number of key slots to manage.
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* Allocate memory for keyslots and initialize a keyslot manager. Called by
* e.g. storage drivers to set up a keyslot manager in their request_queue.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* Return: 0 on success, or else a negative error code.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
int blk_ksm_init(struct blk_keyslot_manager *ksm, unsigned int num_slots)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
unsigned int slot;
unsigned int i;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
unsigned int slot_hashtable_size;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
memset(ksm, 0, sizeof(*ksm));
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (num_slots == 0)
return -EINVAL;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
ksm->slots = kvcalloc(num_slots, sizeof(ksm->slots[0]), GFP_KERNEL);
if (!ksm->slots)
return -ENOMEM;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
ksm->num_slots = num_slots;
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++) {
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
ksm->slots[slot].ksm = ksm;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
list_add_tail(&ksm->slots[slot].idle_slot_node,
&ksm->idle_slots);
}
spin_lock_init(&ksm->idle_slots_lock);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
slot_hashtable_size = roundup_pow_of_two(num_slots);
/*
* hash_ptr() assumes bits != 0, so ensure the hash table has at least 2
* buckets. This only makes a difference when there is only 1 keyslot.
*/
if (slot_hashtable_size < 2)
slot_hashtable_size = 2;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
ksm->log_slot_ht_size = ilog2(slot_hashtable_size);
ksm->slot_hashtable = kvmalloc_array(slot_hashtable_size,
sizeof(ksm->slot_hashtable[0]),
GFP_KERNEL);
if (!ksm->slot_hashtable)
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
goto err_destroy_ksm;
for (i = 0; i < slot_hashtable_size; i++)
INIT_HLIST_HEAD(&ksm->slot_hashtable[i]);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
return 0;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
err_destroy_ksm:
blk_ksm_destroy(ksm);
return -ENOMEM;
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
EXPORT_SYMBOL_GPL(blk_ksm_init);
static void blk_ksm_destroy_callback(void *ksm)
{
blk_ksm_destroy(ksm);
}
/**
* devm_blk_ksm_init() - Resource-managed blk_ksm_init()
* @dev: The device which owns the blk_keyslot_manager.
* @ksm: The blk_keyslot_manager to initialize.
* @num_slots: The number of key slots to manage.
*
* Like blk_ksm_init(), but causes blk_ksm_destroy() to be called automatically
* on driver detach.
*
* Return: 0 on success, or else a negative error code.
*/
int devm_blk_ksm_init(struct device *dev, struct blk_keyslot_manager *ksm,
unsigned int num_slots)
{
int err = blk_ksm_init(ksm, num_slots);
if (err)
return err;
return devm_add_action_or_reset(dev, blk_ksm_destroy_callback, ksm);
}
EXPORT_SYMBOL_GPL(devm_blk_ksm_init);
static inline struct hlist_head *
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_hash_bucket_for_key(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key)
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
return &ksm->slot_hashtable[hash_ptr(key, ksm->log_slot_ht_size)];
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
static void blk_ksm_remove_slot_from_lru_list(struct blk_ksm_keyslot *slot)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
struct blk_keyslot_manager *ksm = slot->ksm;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
unsigned long flags;
spin_lock_irqsave(&ksm->idle_slots_lock, flags);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
list_del(&slot->idle_slot_node);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
spin_unlock_irqrestore(&ksm->idle_slots_lock, flags);
}
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
static struct blk_ksm_keyslot *blk_ksm_find_keyslot(
struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key)
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
const struct hlist_head *head = blk_ksm_hash_bucket_for_key(ksm, key);
struct blk_ksm_keyslot *slotp;
hlist_for_each_entry(slotp, head, hash_node) {
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (slotp->key == key)
return slotp;
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
return NULL;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
static struct blk_ksm_keyslot *blk_ksm_find_and_grab_keyslot(
struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
struct blk_ksm_keyslot *slot;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
slot = blk_ksm_find_keyslot(ksm, key);
if (!slot)
return NULL;
if (atomic_inc_return(&slot->slot_refs) == 1) {
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
/* Took first reference to this slot; remove it from LRU list */
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_remove_slot_from_lru_list(slot);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
return slot;
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
unsigned int blk_ksm_get_slot_idx(struct blk_ksm_keyslot *slot)
{
return slot - slot->ksm->slots;
}
EXPORT_SYMBOL_GPL(blk_ksm_get_slot_idx);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_get_slot_for_key() - Program a key into a keyslot.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
* @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.
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* @slot_ptr: A pointer to return the pointer of the allocated keyslot.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09: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.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*
* Context: Process context. Takes and releases ksm->lock.
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* Return: BLK_STS_OK on success (and keyslot is set to the pointer of the
* allocated keyslot), or some other blk_status_t otherwise (and
* keyslot is set to NULL).
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_status_t blk_ksm_get_slot_for_key(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key,
struct blk_ksm_keyslot **slot_ptr)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
struct blk_ksm_keyslot *slot;
int slot_idx;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
int err;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
*slot_ptr = NULL;
if (blk_ksm_is_passthrough(ksm))
return BLK_STS_OK;
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-22 02:27:43 +09:00
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
down_read(&ksm->lock);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
slot = blk_ksm_find_and_grab_keyslot(ksm, key);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
up_read(&ksm->lock);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (slot)
goto success;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
for (;;) {
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_hw_enter(ksm);
slot = blk_ksm_find_and_grab_keyslot(ksm, key);
if (slot) {
blk_ksm_hw_exit(ksm);
goto success;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
/*
* 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))
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
break;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_hw_exit(ksm);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
wait_event(ksm->idle_slots_wait_queue,
!list_empty(&ksm->idle_slots));
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
slot = list_first_entry(&ksm->idle_slots, struct blk_ksm_keyslot,
idle_slot_node);
slot_idx = blk_ksm_get_slot_idx(slot);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
err = ksm->ksm_ll_ops.keyslot_program(ksm, key, slot_idx);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
if (err) {
wake_up(&ksm->idle_slots_wait_queue);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_hw_exit(ksm);
return errno_to_blk_status(err);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
/* Move this slot to the hash list for the new key. */
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (slot->key)
hlist_del(&slot->hash_node);
slot->key = key;
hlist_add_head(&slot->hash_node, blk_ksm_hash_bucket_for_key(ksm, key));
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
atomic_set(&slot->slot_refs, 1);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_remove_slot_from_lru_list(slot);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_hw_exit(ksm);
success:
*slot_ptr = slot;
return BLK_STS_OK;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_put_slot() - Release a reference to a slot
* @slot: The keyslot to release the reference of.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*
* Context: Any context.
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
void blk_ksm_put_slot(struct blk_ksm_keyslot *slot)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
struct blk_keyslot_manager *ksm;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
unsigned long flags;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (!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-22 02:27:43 +09:00
return;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
ksm = slot->ksm;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (atomic_dec_and_lock_irqsave(&slot->slot_refs,
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
&ksm->idle_slots_lock, flags)) {
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
list_add_tail(&slot->idle_slot_node, &ksm->idle_slots);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
spin_unlock_irqrestore(&ksm->idle_slots_lock, flags);
wake_up(&ksm->idle_slots_wait_queue);
}
}
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_crypto_cfg_supported() - Find out if a crypto configuration is
* supported by a ksm.
* @ksm: The keyslot manager to check
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* @cfg: The crypto configuration to check for.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* Checks for crypto_mode/data unit size/dun bytes support.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* Return: Whether or not this ksm supports the specified crypto config.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
bool blk_ksm_crypto_cfg_supported(struct blk_keyslot_manager *ksm,
const struct blk_crypto_config *cfg)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
if (!ksm)
return false;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (!(ksm->crypto_modes_supported[cfg->crypto_mode] &
cfg->data_unit_size))
return false;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (ksm->max_dun_bytes_supported < cfg->dun_bytes)
return false;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (cfg->is_hw_wrapped) {
if (!(ksm->features & BLK_CRYPTO_FEATURE_WRAPPED_KEYS))
return false;
} else {
if (!(ksm->features & BLK_CRYPTO_FEATURE_STANDARD_KEYS))
return false;
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
return true;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
2023-03-16 03:39:04 +09:00
/*
* This is an internal function that evicts a key from an inline encryption
* device that can be either a real device or the blk-crypto-fallback "device".
* It is used only by blk_crypto_evict_key(); see that function for details.
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
int blk_ksm_evict_key(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
struct blk_ksm_keyslot *slot;
2023-03-16 03:39:04 +09:00
int err;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (blk_ksm_is_passthrough(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-22 02:27:43 +09:00
if (ksm->ksm_ll_ops.keyslot_evict) {
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_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-22 02:27:43 +09:00
err = ksm->ksm_ll_ops.keyslot_evict(ksm, key, -1);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_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-22 02:27:43 +09:00
return err;
}
return 0;
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_hw_enter(ksm);
slot = blk_ksm_find_keyslot(ksm, key);
2023-03-16 03:39:04 +09:00
if (!slot) {
/*
* Not an error, since a key not in use by I/O is not guaranteed
* to be in a keyslot. There can be more keys than keyslots.
*/
err = 0;
goto out;
}
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)) {
2023-03-16 03:39:04 +09:00
/* BUG: key is still in use by I/O */
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
err = -EBUSY;
2023-03-16 03:39:04 +09:00
goto out_remove;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
err = ksm->ksm_ll_ops.keyslot_evict(ksm, key,
blk_ksm_get_slot_idx(slot));
2023-03-16 03:39:04 +09:00
out_remove:
/*
* Callers free the key even on error, so unlink the key from the hash
* table and clear slot->key even on error.
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
hlist_del(&slot->hash_node);
slot->key = NULL;
2023-03-16 03:39:04 +09:00
out:
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
blk_ksm_hw_exit(ksm);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
return err;
}
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_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.
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
void blk_ksm_reprogram_all_keys(struct blk_keyslot_manager *ksm)
{
unsigned int slot;
if (blk_ksm_is_passthrough(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-22 02:27:43 +09:00
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 08:08:24 +09:00
/* This is for device initialization, so don't resume the device */
down_write(&ksm->lock);
for (slot = 0; slot < ksm->num_slots; slot++) {
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
const struct blk_crypto_key *key = ksm->slots[slot].key;
int err;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (!key)
continue;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
err = ksm->ksm_ll_ops.keyslot_program(ksm, key, slot);
WARN_ON(err);
}
up_write(&ksm->lock);
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
EXPORT_SYMBOL_GPL(blk_ksm_reprogram_all_keys);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
void blk_ksm_destroy(struct blk_keyslot_manager *ksm)
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (!ksm)
return;
kvfree(ksm->slot_hashtable);
kvfree_sensitive(ksm->slots, sizeof(ksm->slots[0]) * ksm->num_slots);
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
memzero_explicit(ksm, sizeof(*ksm));
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
EXPORT_SYMBOL_GPL(blk_ksm_destroy);
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
bool blk_ksm_register(struct blk_keyslot_manager *ksm, struct request_queue *q)
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (blk_integrity_queue_supports_integrity(q)) {
pr_warn("Integrity and hardware inline encryption are not supported together. Disabling hardware inline encryption.\n");
return false;
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
q->ksm = ksm;
return true;
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 Ie1b77f7615d6a7a60fdc9105c7ab2200d17636a8 Change-Id: Iea1ee5a7eec46cb50d33cf1e2d20dfb7335af4ed Signed-off-by: Satya Tangirala <satyat@google.com> Link: https://patchwork.kernel.org/patch/11214713/
2019-10-25 06:44:23 +09:00
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
EXPORT_SYMBOL_GPL(blk_ksm_register);
void blk_ksm_unregister(struct request_queue *q)
{
q->ksm = NULL;
}
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-22 02:27:43 +09:00
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_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
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-22 02:27:43 +09:00
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* 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.
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-22 02:27:43 +09:00
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* Return: 0 on success, -EOPNOTSUPP if hardware-wrapped keys are unsupported,
* or another -errno code.
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-22 02:27:43 +09:00
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
int blk_ksm_derive_raw_secret(struct blk_keyslot_manager *ksm,
const u8 *wrapped_key,
unsigned int wrapped_key_size,
u8 *secret, unsigned int secret_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-22 02:27:43 +09:00
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
int err;
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-22 02:27:43 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
if (ksm->ksm_ll_ops.derive_raw_secret) {
blk_ksm_hw_enter(ksm);
err = ksm->ksm_ll_ops.derive_raw_secret(ksm, wrapped_key,
wrapped_key_size,
secret, secret_size);
blk_ksm_hw_exit(ksm);
} else {
err = -EOPNOTSUPP;
}
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-22 02:27:43 +09:00
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
return err;
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-22 02:27:43 +09:00
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
EXPORT_SYMBOL_GPL(blk_ksm_derive_raw_secret);
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-22 02:27:43 +09:00
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_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.
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
void blk_ksm_intersect_modes(struct blk_keyslot_manager *parent,
const struct blk_keyslot_manager *child)
{
if (child) {
unsigned int i;
parent->max_dun_bytes_supported =
min(parent->max_dun_bytes_supported,
child->max_dun_bytes_supported);
for (i = 0; i < ARRAY_SIZE(child->crypto_modes_supported);
i++) {
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
parent->crypto_modes_supported[i] &=
child->crypto_modes_supported[i];
}
parent->features &= child->features;
} else {
parent->max_dun_bytes_supported = 0;
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
memset(parent->crypto_modes_supported, 0,
sizeof(parent->crypto_modes_supported));
parent->features = 0;
}
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
EXPORT_SYMBOL_GPL(blk_ksm_intersect_modes);
/**
* blk_ksm_is_superset() - Check if a KSM supports a superset of crypto modes
* and DUN bytes that another KSM supports. Here,
* "superset" refers to the mathematical meaning of the
* word - i.e. if two KSMs have the *same* capabilities,
* they *are* considered supersets of each other.
* @ksm_superset: The KSM that we want to verify is a superset
* @ksm_subset: The KSM that we want to verify is a subset
*
* Return: True if @ksm_superset supports a superset of the crypto modes and DUN
* bytes that @ksm_subset supports.
*/
bool blk_ksm_is_superset(struct blk_keyslot_manager *ksm_superset,
struct blk_keyslot_manager *ksm_subset)
{
int i;
if (!ksm_subset)
return true;
if (!ksm_superset)
return false;
for (i = 0; i < ARRAY_SIZE(ksm_superset->crypto_modes_supported); i++) {
if (ksm_subset->crypto_modes_supported[i] &
(~ksm_superset->crypto_modes_supported[i])) {
return false;
}
}
if (ksm_subset->max_dun_bytes_supported >
ksm_superset->max_dun_bytes_supported) {
return false;
}
if (ksm_subset->features & ~ksm_superset->features)
return false;
return true;
}
EXPORT_SYMBOL_GPL(blk_ksm_is_superset);
/**
* blk_ksm_update_capabilities() - Update the restrictions of a KSM to those of
* another KSM
* @target_ksm: The KSM whose restrictions to update.
* @reference_ksm: The KSM to whose restrictions this function will update
* @target_ksm's restrictions to.
*
* Blk-crypto requires that crypto capabilities that were
* advertised when a bio was created continue to be supported by the
* device until that bio is ended. This is turn means that a device cannot
* shrink its advertised crypto capabilities without any explicit
* synchronization with upper layers. So if there's no such explicit
* synchronization, @reference_ksm must support all the crypto capabilities that
* @target_ksm does
* (i.e. we need blk_ksm_is_superset(@reference_ksm, @target_ksm) == true).
*
* Note also that as long as the crypto capabilities are being expanded, the
* order of updates becoming visible is not important because it's alright
* for blk-crypto to see stale values - they only cause blk-crypto to
* believe that a crypto capability isn't supported when it actually is (which
* might result in blk-crypto-fallback being used if available, or the bio being
* failed).
*/
void blk_ksm_update_capabilities(struct blk_keyslot_manager *target_ksm,
struct blk_keyslot_manager *reference_ksm)
{
memcpy(target_ksm->crypto_modes_supported,
reference_ksm->crypto_modes_supported,
sizeof(target_ksm->crypto_modes_supported));
target_ksm->max_dun_bytes_supported =
reference_ksm->max_dun_bytes_supported;
target_ksm->features = reference_ksm->features;
}
EXPORT_SYMBOL_GPL(blk_ksm_update_capabilities);
/**
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* blk_ksm_init_passthrough() - Init a passthrough keyslot manager
* @ksm: The keyslot manager to init
*
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
* 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 doesn't have the concept
* of keyslots, and for layered devices.
*/
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
void blk_ksm_init_passthrough(struct blk_keyslot_manager *ksm)
{
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
memset(ksm, 0, sizeof(*ksm));
init_rwsem(&ksm->lock);
}
FROMLIST: Update Inline Encryption from v6 to upstream version of patch series The block layer patches for inline encryption are now in upstream, so update Android to the upstream version of inline encryption. The fscrypt/f2fs/ext4 patches are also updated to the latest version sent upstream (since they can't be updated separately from the block layer patches). Changes v6 => v7: - Keyslot management is now done on a per-request basis rather than a per-bio basis. - Storage drivers can now specify the maximum number of bytes they can accept for the data unit number (DUN) for each crypto algorithm, and upper layers can specify the minimum number of bytes of DUN they want with the blk_crypto_key they send with the bio - a driver is only considered to support a blk_crypto_key if the driver supports at least as many DUN bytes as the upper layer wants. This is necessary because storage drivers may not support as many bytes as the algorithm specification dictates (for e.g. UFS only supports 8 byte DUNs for AES-256-XTS, even though the algorithm specification says DUNs are 16 bytes long). - Introduce SB_INLINECRYPT to keep track of whether inline encryption is enabled for a filesystem (instead of using an fscrypt_operation). - Expose keyslot manager declaration and embed it within ufs_hba to clean up code. - Make blk-crypto preclude blk-integrity. - Some bug fixes - Introduce UFSHCD_QUIRK_BROKEN_CRYPTO for UFS drivers that don't support inline encryption (yet) Changes v7 => v8: - Pass a struct blk_ksm_keyslot * around instead of slot numbers which simplifies some functions and passes around arguments with better types - Make bios with no encryption context avoid making calls into blk-crypto by checking for the presence of bi_crypt_context before making the call - Make blk-integrity preclude inline encryption support at probe time - Many many cleanups Changes v8 => v9: - Don't open code bio_has_crypt_ctx into callers of blk-crypto functions. - Lots of cleanups Changes v9 => v10: - Incorporate Eric's fix for allowing en/decryption to happen as usual via fscrypt in the case that hardware doesn't support the desired crypto configuration, but blk-crypto-fallback is disabled. (Introduce struct blk_crypto_config and blk_crypto_config_supported for fscrypt to call, to check that either blk-crypto-fallback is enabled or the device supports the crypto configuration). - Update docs - Lots of cleanups Changes v10 => v11: - We now allocate a new bio_crypt_ctx for each request instead of pulling and reusing the one in the bio inserted into the request. The bio_crypt_ctx of a bio is freed after the bio is ended. - Make each blk_ksm_keyslot store a pointer to the blk_crypto_key instead of a copy of the blk_crypto_key, so that each blk_crypto_key will have its own keyslot. We also won't need to compute the siphash for a blk_crypto_key anymore. - Minor cleanups Changes v11 => v12: - Inlined some fscrypt functions - Minor cleanups and improved comments Changes v12 => v13: - Updated docs - Minor cleanups - rebased onto linux-block/for-next Changes v13 => fscrypt/f2fs/ext4 upstream patch series - rename struct fscrypt_info::ci_key to ci_enc_key - set dun bytes more precisely in fscrypt - cleanups Bug: 137270441 Test: Test cuttlefish boots both with and without inlinecrypt mount option specified in fstab, while using both F2FS and EXT4 for userdata.img. Also verified ciphertext via "atest -v vts_kernel_encryption_test" Also tested by running gce-xfstests on both the auto and encrypt test groups on EXT4 and F2FS both with and without the inlinecrypt mount option. The UFS changes were tested on a Pixel 4 device. Link: https://lore.kernel.org/linux-block/20200514003727.69001-1-satyat@google.com/ Link: https://lore.kernel.org/linux-fscrypt/20200617075732.213198-1-satyat@google.com/ Link: https://lore.kernel.org/linux-scsi/20200617081841.218985-1-satyat@google.com/ Change-Id: I57c10d370bf006c9dfcf173f21a720413017761e Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-06-17 06:33:37 +09:00
EXPORT_SYMBOL_GPL(blk_ksm_init_passthrough);