android_kernel_xiaomi_sm8450/block/blk-crypto-fallback.c

661 lines
18 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2019 Google LLC
*/
/*
* Refer to Documentation/block/inline-encryption.rst for detailed explanation.
*/
#define pr_fmt(fmt) "blk-crypto-fallback: " fmt
#include <crypto/skcipher.h>
#include <linux/blk-cgroup.h>
#include <linux/blk-crypto.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
#include <linux/blkdev.h>
#include <linux/crypto.h>
#include <linux/keyslot-manager.h>
#include <linux/mempool.h>
#include <linux/module.h>
#include <linux/random.h>
#include "blk-crypto-internal.h"
static unsigned int num_prealloc_bounce_pg = 32;
module_param(num_prealloc_bounce_pg, uint, 0);
MODULE_PARM_DESC(num_prealloc_bounce_pg,
"Number of preallocated bounce pages for the blk-crypto crypto API fallback");
static unsigned int blk_crypto_num_keyslots = 100;
module_param_named(num_keyslots, blk_crypto_num_keyslots, uint, 0);
MODULE_PARM_DESC(num_keyslots,
"Number of keyslots for the blk-crypto crypto API fallback");
static unsigned int num_prealloc_fallback_crypt_ctxs = 128;
module_param(num_prealloc_fallback_crypt_ctxs, uint, 0);
MODULE_PARM_DESC(num_prealloc_crypt_fallback_ctxs,
"Number of preallocated bio fallback crypto contexts for blk-crypto to use during crypto API fallback");
struct bio_fallback_crypt_ctx {
struct bio_crypt_ctx crypt_ctx;
/*
* Copy of the bvec_iter when this bio was submitted.
* We only want to en/decrypt the part of the bio as described by the
* bvec_iter upon submission because bio might be split before being
* resubmitted
*/
struct bvec_iter crypt_iter;
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
union {
struct {
struct work_struct work;
struct bio *bio;
};
struct {
void *bi_private_orig;
bio_end_io_t *bi_end_io_orig;
};
};
};
static struct kmem_cache *bio_fallback_crypt_ctx_cache;
static mempool_t *bio_fallback_crypt_ctx_pool;
/*
* Allocating a crypto tfm during I/O can deadlock, so we have to preallocate
* all of a mode's tfms when that mode starts being used. Since each mode may
* need all the keyslots at some point, each mode needs its own tfm for each
* keyslot; thus, a keyslot may contain tfms for multiple modes. However, to
* match the behavior of real inline encryption hardware (which only supports a
* single encryption context per keyslot), we only allow one tfm per keyslot to
* be used at a time - the rest of the unused tfms have their keys cleared.
*/
static DEFINE_MUTEX(tfms_init_lock);
static bool tfms_inited[BLK_ENCRYPTION_MODE_MAX];
static struct blk_crypto_keyslot {
enum blk_crypto_mode_num crypto_mode;
struct crypto_skcipher *tfms[BLK_ENCRYPTION_MODE_MAX];
} *blk_crypto_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
static struct blk_keyslot_manager blk_crypto_ksm;
static struct workqueue_struct *blk_crypto_wq;
static mempool_t *blk_crypto_bounce_page_pool;
/*
* This is the key we set when evicting a keyslot. This *should* be the all 0's
* key, but AES-XTS rejects that key, so we use some random bytes instead.
*/
static u8 blank_key[BLK_CRYPTO_MAX_KEY_SIZE];
static void blk_crypto_evict_keyslot(unsigned int slot)
{
struct blk_crypto_keyslot *slotp = &blk_crypto_keyslots[slot];
enum blk_crypto_mode_num crypto_mode = slotp->crypto_mode;
int err;
WARN_ON(slotp->crypto_mode == BLK_ENCRYPTION_MODE_INVALID);
/* Clear the key in the skcipher */
err = crypto_skcipher_setkey(slotp->tfms[crypto_mode], blank_key,
blk_crypto_modes[crypto_mode].keysize);
WARN_ON(err);
slotp->crypto_mode = BLK_ENCRYPTION_MODE_INVALID;
}
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 int blk_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key,
unsigned int slot)
{
struct blk_crypto_keyslot *slotp = &blk_crypto_keyslots[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 enum blk_crypto_mode_num crypto_mode =
key->crypto_cfg.crypto_mode;
int err;
if (crypto_mode != slotp->crypto_mode &&
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
slotp->crypto_mode != BLK_ENCRYPTION_MODE_INVALID)
blk_crypto_evict_keyslot(slot);
slotp->crypto_mode = crypto_mode;
err = crypto_skcipher_setkey(slotp->tfms[crypto_mode], key->raw,
key->size);
if (err) {
blk_crypto_evict_keyslot(slot);
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
static int blk_crypto_keyslot_evict(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key,
unsigned int slot)
{
blk_crypto_evict_keyslot(slot);
return 0;
}
/*
* The crypto API fallback KSM ops - only used for a bio when it specifies a
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_crypto_key that was not supported by the device's 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
static const struct blk_ksm_ll_ops blk_crypto_ksm_ll_ops = {
.keyslot_program = blk_crypto_keyslot_program,
.keyslot_evict = blk_crypto_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
static void blk_crypto_fallback_encrypt_endio(struct bio *enc_bio)
{
struct bio *src_bio = enc_bio->bi_private;
int i;
for (i = 0; i < enc_bio->bi_vcnt; i++)
mempool_free(enc_bio->bi_io_vec[i].bv_page,
blk_crypto_bounce_page_pool);
src_bio->bi_status = enc_bio->bi_status;
bio_put(enc_bio);
bio_endio(src_bio);
}
static struct bio *blk_crypto_clone_bio(struct bio *bio_src)
{
struct bvec_iter iter;
struct bio_vec bv;
struct bio *bio;
bio = bio_alloc_bioset(GFP_NOIO, bio_segments(bio_src), NULL);
if (!bio)
return NULL;
bio->bi_disk = bio_src->bi_disk;
bio->bi_opf = bio_src->bi_opf;
bio->bi_ioprio = bio_src->bi_ioprio;
bio->bi_write_hint = bio_src->bi_write_hint;
bio->bi_iter.bi_sector = bio_src->bi_iter.bi_sector;
bio->bi_iter.bi_size = bio_src->bi_iter.bi_size;
bio_for_each_segment(bv, bio_src, iter)
bio->bi_io_vec[bio->bi_vcnt++] = bv;
bio_clone_blkg_association(bio, bio_src);
blkcg_bio_issue_init(bio);
ANDROID: dm: add dm-default-key target for metadata encryption Add a device-mapper target "dm-default-key" which assigns an encryption key to bios that aren't for the contents of an encrypted file. This ensures that all blocks on-disk will be encrypted with some key, without the performance hit of file contents being encrypted twice when fscrypt (File-Based Encryption) is used. It is only appropriate to use dm-default-key when key configuration is tightly controlled, like it is in Android, such that all fscrypt keys are at least as hard to compromise as the default key. Compared to the original version of dm-default-key, this has been modified to use the new vendor-independent inline encryption framework (which works even when no inline encryption hardware is present), the table syntax has been changed to match dm-crypt, and support for specifying Adiantum encryption has been added. These changes also mean that dm-default-key now always explicitly specifies the DUN (the IV). Also, to handle f2fs moving blocks of encrypted files around without the key, and to handle ext4 and f2fs filesystems mounted without '-o inlinecrypt', the mapping logic is no longer "set a key on the bio if it doesn't have one already", but rather "set a key on the bio unless the bio has the bi_skip_dm_default_key flag set". Filesystems set this flag on *all* bios for encrypted file contents, regardless of whether they are encrypting/decrypting the file using inline encryption or the traditional filesystem-layer encryption, or moving the raw data. For the bi_skip_dm_default_key flag, a new field in struct bio is used rather than a bit in bi_opf so that fscrypt_set_bio_crypt_ctx() can set the flag, minimizing the changes needed to filesystems. (bi_opf is usually overwritten after fscrypt_set_bio_crypt_ctx() is called.) Bug: 137270441 Bug: 147814592 Change-Id: I69c9cd1e968ccf990e4ad96e5115b662237f5095 Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-01-22 02:27:47 +09:00
bio_clone_skip_dm_default_key(bio, bio_src);
return bio;
}
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 bool blk_crypto_alloc_cipher_req(struct blk_ksm_keyslot *slot,
struct skcipher_request **ciph_req_ret,
struct crypto_wait *wait)
{
struct skcipher_request *ciph_req;
const struct blk_crypto_keyslot *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
int keyslot_idx = blk_ksm_get_slot_idx(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
slotp = &blk_crypto_keyslots[keyslot_idx];
ciph_req = skcipher_request_alloc(slotp->tfms[slotp->crypto_mode],
GFP_NOIO);
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 (!ciph_req)
return false;
skcipher_request_set_callback(ciph_req,
CRYPTO_TFM_REQ_MAY_BACKLOG |
CRYPTO_TFM_REQ_MAY_SLEEP,
crypto_req_done, wait);
*ciph_req_ret = ciph_req;
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: 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 bool blk_crypto_split_bio_if_needed(struct bio **bio_ptr)
{
struct bio *bio = *bio_ptr;
unsigned int i = 0;
unsigned int num_sectors = 0;
struct bio_vec bv;
struct bvec_iter iter;
bio_for_each_segment(bv, bio, iter) {
num_sectors += bv.bv_len >> SECTOR_SHIFT;
if (++i == BIO_MAX_PAGES)
break;
}
if (num_sectors < bio_sectors(bio)) {
struct bio *split_bio;
split_bio = bio_split(bio, num_sectors, GFP_NOIO, NULL);
if (!split_bio) {
bio->bi_status = BLK_STS_RESOURCE;
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 false;
}
bio_chain(split_bio, bio);
submit_bio_noacct(bio);
*bio_ptr = split_bio;
}
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;
}
union blk_crypto_iv {
__le64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
u8 bytes[BLK_CRYPTO_MAX_IV_SIZE];
};
static void blk_crypto_dun_to_iv(const u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE],
union blk_crypto_iv *iv)
{
int i;
for (i = 0; i < BLK_CRYPTO_DUN_ARRAY_SIZE; i++)
iv->dun[i] = cpu_to_le64(dun[i]);
}
/*
* The crypto API fallback's encryption routine.
* Allocate a bounce bio for encryption, encrypt the input bio using crypto API,
* and replace *bio_ptr with the bounce bio. May split input bio if it's too
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
* large. Returns true on success. Returns false and sets bio->bi_status 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
static bool blk_crypto_fallback_encrypt_bio(struct bio **bio_ptr)
{
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 bio *src_bio, *enc_bio;
struct bio_crypt_ctx *bc;
struct blk_ksm_keyslot *slot;
int data_unit_size;
struct skcipher_request *ciph_req = NULL;
DECLARE_CRYPTO_WAIT(wait);
u64 curr_dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
struct scatterlist src, dst;
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
union blk_crypto_iv iv;
unsigned int i, j;
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 ret = false;
blk_status_t blk_st;
/* Split the bio if it's too big for single page bvec */
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_crypto_split_bio_if_needed(bio_ptr))
return false;
src_bio = *bio_ptr;
bc = src_bio->bi_crypt_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
data_unit_size = bc->bc_key->crypto_cfg.data_unit_size;
/* Allocate bounce bio for encryption */
enc_bio = blk_crypto_clone_bio(src_bio);
if (!enc_bio) {
src_bio->bi_status = BLK_STS_RESOURCE;
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 false;
}
/*
* Use the crypto API fallback keyslot manager to get a crypto_skcipher
* for the algorithm and key specified for this bio.
*/
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_st = blk_ksm_get_slot_for_key(&blk_crypto_ksm, bc->bc_key, &slot);
if (blk_st != BLK_STS_OK) {
src_bio->bi_status = blk_st;
goto out_put_enc_bio;
}
/* and then allocate an skcipher_request for it */
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_crypto_alloc_cipher_req(slot, &ciph_req, &wait)) {
src_bio->bi_status = BLK_STS_RESOURCE;
goto out_release_keyslot;
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
}
memcpy(curr_dun, bc->bc_dun, sizeof(curr_dun));
sg_init_table(&src, 1);
sg_init_table(&dst, 1);
skcipher_request_set_crypt(ciph_req, &src, &dst, data_unit_size,
iv.bytes);
/* Encrypt each page in the bounce bio */
for (i = 0; i < enc_bio->bi_vcnt; i++) {
struct bio_vec *enc_bvec = &enc_bio->bi_io_vec[i];
struct page *plaintext_page = enc_bvec->bv_page;
struct page *ciphertext_page =
mempool_alloc(blk_crypto_bounce_page_pool, GFP_NOIO);
enc_bvec->bv_page = ciphertext_page;
if (!ciphertext_page) {
src_bio->bi_status = BLK_STS_RESOURCE;
goto out_free_bounce_pages;
}
sg_set_page(&src, plaintext_page, data_unit_size,
enc_bvec->bv_offset);
sg_set_page(&dst, ciphertext_page, data_unit_size,
enc_bvec->bv_offset);
/* Encrypt each data unit in this page */
for (j = 0; j < enc_bvec->bv_len; j += data_unit_size) {
blk_crypto_dun_to_iv(curr_dun, &iv);
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 (crypto_wait_req(crypto_skcipher_encrypt(ciph_req),
&wait)) {
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
src_bio->bi_status = BLK_STS_IOERR;
goto out_free_bounce_pages;
}
bio_crypt_dun_increment(curr_dun, 1);
src.offset += data_unit_size;
dst.offset += data_unit_size;
}
}
enc_bio->bi_private = src_bio;
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
enc_bio->bi_end_io = blk_crypto_fallback_encrypt_endio;
*bio_ptr = enc_bio;
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
ret = true;
enc_bio = NULL;
goto out_free_ciph_req;
out_free_bounce_pages:
while (i > 0)
mempool_free(enc_bio->bi_io_vec[--i].bv_page,
blk_crypto_bounce_page_pool);
out_free_ciph_req:
skcipher_request_free(ciph_req);
out_release_keyslot:
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(slot);
out_put_enc_bio:
if (enc_bio)
bio_put(enc_bio);
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 ret;
}
/*
* The crypto API fallback's main decryption routine.
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
* Decrypts input bio in place, and calls bio_endio on the bio.
*/
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_crypto_fallback_decrypt_bio(struct work_struct *work)
{
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 bio_fallback_crypt_ctx *f_ctx =
container_of(work, struct bio_fallback_crypt_ctx, work);
struct bio *bio = f_ctx->bio;
struct bio_crypt_ctx *bc = &f_ctx->crypt_ctx;
struct blk_ksm_keyslot *slot;
struct skcipher_request *ciph_req = NULL;
DECLARE_CRYPTO_WAIT(wait);
u64 curr_dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
union blk_crypto_iv iv;
struct scatterlist sg;
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 bio_vec bv;
struct bvec_iter iter;
const int data_unit_size = bc->bc_key->crypto_cfg.data_unit_size;
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
blk_status_t blk_st;
/*
* Use the crypto API fallback keyslot manager to get a crypto_skcipher
* for the algorithm and key specified for this bio.
*/
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_st = blk_ksm_get_slot_for_key(&blk_crypto_ksm, bc->bc_key, &slot);
if (blk_st != BLK_STS_OK) {
bio->bi_status = blk_st;
goto out_no_keyslot;
}
/* and then allocate an skcipher_request for it */
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_crypto_alloc_cipher_req(slot, &ciph_req, &wait)) {
bio->bi_status = BLK_STS_RESOURCE;
goto 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
}
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
memcpy(curr_dun, bc->bc_dun, sizeof(curr_dun));
sg_init_table(&sg, 1);
skcipher_request_set_crypt(ciph_req, &sg, &sg, data_unit_size,
iv.bytes);
/* Decrypt each segment in the bio */
__bio_for_each_segment(bv, bio, iter, f_ctx->crypt_iter) {
struct page *page = bv.bv_page;
sg_set_page(&sg, page, data_unit_size, bv.bv_offset);
/* Decrypt each data unit in the segment */
for (i = 0; i < bv.bv_len; i += data_unit_size) {
blk_crypto_dun_to_iv(curr_dun, &iv);
if (crypto_wait_req(crypto_skcipher_decrypt(ciph_req),
&wait)) {
bio->bi_status = BLK_STS_IOERR;
goto out;
}
bio_crypt_dun_increment(curr_dun, 1);
sg.offset += data_unit_size;
}
}
out:
skcipher_request_free(ciph_req);
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(slot);
out_no_keyslot:
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
mempool_free(f_ctx, bio_fallback_crypt_ctx_pool);
bio_endio(bio);
}
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_crypto_fallback_decrypt_endio - queue bio for fallback decryption
*
* @bio: the bio to queue
*
* Restore bi_private and bi_end_io, and queue the bio for decryption into a
* workqueue, since this function will be called from an atomic 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
static void blk_crypto_fallback_decrypt_endio(struct bio *bio)
{
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 bio_fallback_crypt_ctx *f_ctx = bio->bi_private;
bio->bi_private = f_ctx->bi_private_orig;
bio->bi_end_io = f_ctx->bi_end_io_orig;
/* If there was an IO error, don't queue for decrypt. */
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 (bio->bi_status) {
mempool_free(f_ctx, bio_fallback_crypt_ctx_pool);
bio_endio(bio);
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
INIT_WORK(&f_ctx->work, blk_crypto_fallback_decrypt_bio);
f_ctx->bio = bio;
queue_work(blk_crypto_wq, &f_ctx->work);
}
/**
* blk_crypto_fallback_bio_prep - Prepare a bio to use fallback en/decryption
*
* @bio_ptr: pointer to the bio to prepare
*
* If bio is doing a WRITE operation, this splits the bio into two parts if it's
* too big (see blk_crypto_split_bio_if_needed). It then allocates a bounce bio
* for the first part, encrypts it, and update bio_ptr to point to the bounce
* bio.
*
* For a READ operation, we mark the bio for decryption by using bi_private and
* bi_end_io.
*
* In either case, this function will make the bio look like a regular bio (i.e.
* as if no encryption context was ever specified) for the purposes of the rest
* of the stack except for blk-integrity (blk-integrity and blk-crypto are not
* currently supported together).
*
* Return: true on success. Sets bio->bi_status and returns false on error.
*/
bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr)
{
struct bio *bio = *bio_ptr;
struct bio_crypt_ctx *bc = bio->bi_crypt_context;
struct bio_fallback_crypt_ctx *f_ctx;
if (WARN_ON_ONCE(!tfms_inited[bc->bc_key->crypto_cfg.crypto_mode])) {
/* User didn't call blk_crypto_start_using_key() first */
bio->bi_status = BLK_STS_IOERR;
return false;
}
if (!blk_ksm_crypto_cfg_supported(&blk_crypto_ksm,
&bc->bc_key->crypto_cfg)) {
bio->bi_status = BLK_STS_NOTSUPP;
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 (bio_data_dir(bio) == WRITE)
return blk_crypto_fallback_encrypt_bio(bio_ptr);
/*
* bio READ case: Set up a f_ctx in the bio's bi_private and set the
* bi_end_io appropriately to trigger decryption when the bio is ended.
*/
f_ctx = mempool_alloc(bio_fallback_crypt_ctx_pool, GFP_NOIO);
f_ctx->crypt_ctx = *bc;
f_ctx->crypt_iter = bio->bi_iter;
f_ctx->bi_private_orig = bio->bi_private;
f_ctx->bi_end_io_orig = bio->bi_end_io;
bio->bi_private = (void *)f_ctx;
bio->bi_end_io = blk_crypto_fallback_decrypt_endio;
bio_crypt_free_ctx(bio);
return true;
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_crypto_fallback_evict_key(const struct blk_crypto_key *key)
{
return blk_ksm_evict_key(&blk_crypto_ksm, key);
}
static bool blk_crypto_fallback_inited;
static int blk_crypto_fallback_init(void)
{
int i;
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 (blk_crypto_fallback_inited)
return 0;
prandom_bytes(blank_key, BLK_CRYPTO_MAX_KEY_SIZE);
err = blk_ksm_init(&blk_crypto_ksm, blk_crypto_num_keyslots);
if (err)
goto out;
err = -ENOMEM;
blk_crypto_ksm.ksm_ll_ops = blk_crypto_ksm_ll_ops;
blk_crypto_ksm.max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE;
blk_crypto_ksm.features = BLK_CRYPTO_FEATURE_STANDARD_KEYS;
/* All blk-crypto modes have a crypto API fallback. */
for (i = 0; i < BLK_ENCRYPTION_MODE_MAX; i++)
blk_crypto_ksm.crypto_modes_supported[i] = 0xFFFFFFFF;
blk_crypto_ksm.crypto_modes_supported[BLK_ENCRYPTION_MODE_INVALID] = 0;
blk_crypto_wq = alloc_workqueue("blk_crypto_wq",
WQ_UNBOUND | WQ_HIGHPRI |
WQ_MEM_RECLAIM, num_online_cpus());
if (!blk_crypto_wq)
goto fail_free_ksm;
blk_crypto_keyslots = kcalloc(blk_crypto_num_keyslots,
sizeof(blk_crypto_keyslots[0]),
GFP_KERNEL);
if (!blk_crypto_keyslots)
goto fail_free_wq;
blk_crypto_bounce_page_pool =
mempool_create_page_pool(num_prealloc_bounce_pg, 0);
if (!blk_crypto_bounce_page_pool)
goto fail_free_keyslots;
bio_fallback_crypt_ctx_cache = KMEM_CACHE(bio_fallback_crypt_ctx, 0);
if (!bio_fallback_crypt_ctx_cache)
goto fail_free_bounce_page_pool;
bio_fallback_crypt_ctx_pool =
mempool_create_slab_pool(num_prealloc_fallback_crypt_ctxs,
bio_fallback_crypt_ctx_cache);
if (!bio_fallback_crypt_ctx_pool)
goto fail_free_crypt_ctx_cache;
blk_crypto_fallback_inited = true;
return 0;
fail_free_crypt_ctx_cache:
kmem_cache_destroy(bio_fallback_crypt_ctx_cache);
fail_free_bounce_page_pool:
mempool_destroy(blk_crypto_bounce_page_pool);
fail_free_keyslots:
kfree(blk_crypto_keyslots);
fail_free_wq:
destroy_workqueue(blk_crypto_wq);
fail_free_ksm:
blk_ksm_destroy(&blk_crypto_ksm);
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
return err;
}
/*
* Prepare blk-crypto-fallback for the specified crypto mode.
* Returns -ENOPKG if the needed crypto API support is missing.
*/
int blk_crypto_fallback_start_using_mode(enum blk_crypto_mode_num mode_num)
{
const char *cipher_str = blk_crypto_modes[mode_num].cipher_str;
struct blk_crypto_keyslot *slotp;
unsigned int i;
int err = 0;
/*
* Fast path
* Ensure that updates to blk_crypto_keyslots[i].tfms[mode_num]
* for each i are visible before we try to access them.
*/
if (likely(smp_load_acquire(&tfms_inited[mode_num])))
return 0;
mutex_lock(&tfms_init_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 (tfms_inited[mode_num])
goto out;
err = blk_crypto_fallback_init();
if (err)
goto out;
for (i = 0; i < blk_crypto_num_keyslots; i++) {
slotp = &blk_crypto_keyslots[i];
slotp->tfms[mode_num] = crypto_alloc_skcipher(cipher_str, 0, 0);
if (IS_ERR(slotp->tfms[mode_num])) {
err = PTR_ERR(slotp->tfms[mode_num]);
if (err == -ENOENT) {
pr_warn_once("Missing crypto API support for \"%s\"\n",
cipher_str);
err = -ENOPKG;
}
slotp->tfms[mode_num] = NULL;
goto out_free_tfms;
}
crypto_skcipher_set_flags(slotp->tfms[mode_num],
CRYPTO_TFM_REQ_FORBID_WEAK_KEYS);
}
/*
* Ensure that updates to blk_crypto_keyslots[i].tfms[mode_num]
* for each i are visible before we set tfms_inited[mode_num].
*/
smp_store_release(&tfms_inited[mode_num], true);
goto out;
out_free_tfms:
for (i = 0; i < blk_crypto_num_keyslots; i++) {
slotp = &blk_crypto_keyslots[i];
crypto_free_skcipher(slotp->tfms[mode_num]);
slotp->tfms[mode_num] = NULL;
}
out:
mutex_unlock(&tfms_init_lock);
return err;
}